When you think of great products and great software a lot of what you read focuses on the ‘how’ from an engineering point of view. And rightly so. Whether it’s a particular way a product is architected or how a new technology is used to gain performance improvements, these efforts can be critical to the success of a product. But it’s unusual for the focus to be on the team behind a product, and more importantly, their ethos and values. This got me thinking about the important qualities of the Guardian’s Content API team and how it works.
Leadership
Firstly, I firmly believe that strong leadership filters down throughout a team. I don’t mean leadership in the sense of a machiavellian ‘theory X’ approach to leadership but rather someone (or more than one) who is ingrained into the very fabric of the team with a strong sense of not only the intrinsic details of the product from the day-to-day, but also its part in the bigger picture of an organisation.
Since I have been at the Guardian, I cannot think of a time where I did not understand the long term vision for our product within our team, whether that be stabilising our API and maintaining 99.99% uptime or completely reworking our architecture to migrate our products off legacy systems and internal infrastructure. This vision is the responsibility of the individual in the leadership role. Whatever guise this leadership takes, it should be able to convey to the team the shared responsibility of meeting that vision as well as highlighting why the team’s efforts should be directed towards reaching that for the wider good of the business. It should infuse that passion from within. The long term vision for a team should trump all.
A further valued attribute of leadership is the ability to instil approaches and ways of working within a team. As I touched on earlier, something we care deeply about in the content API team is keeping our API both highly available and performant. In fact, it’s of such importance to us that the blanket objective of doing so is first on our objectives list every quarter. This importance is embedded into the team from the moment someone joins and feels the pain of their first mistake. And it’s easy to see why. The content API powers both the Guardian website and mobile apps, along with a plethora of internal and external applications. It is often a shock to new developers on the team to see just how wide reaching the impact of the subtlest defects or outages can have and how this affects your mindset as a developer.
Nevertheless, the team still moves extremely fast and is not afraid to break things in order to push things forward in the pursuit of our shared vision. In fact we break things regularly! But it’s the manner in which we break things that is important. Through being mindful of the potential impacts, the use of feature switches, getting fast feedback from monitoring tools or even putting code in place to circumvent a particular problem in time, we strive to push our products forward as quickly as possible whilst minimising the risk to downstream clients and users.
Pragmatism & Delivery
Another important factor of a team is its ability to get things done. Now I know this may sound obvious but at times, software development can be a place of pedantry and egotistical behaviour. Well, egos need to be shown the door! As a team it is important to be pragmatic about your approach to developing software. Our team endeavours to write the best code in all its glory, but above all, given environmental factors and organisational pressures, we strive to deliver. We are not pedantic about development approaches nor dictate solutions, we use our skill set as developers to provide value to the business.
A brilliant example of this is our approach to testing. We see testing as a professional responsibility of a developer and it’s up to them to decide when testing adds value. We do not monitor test coverage statistics for our projects or covet high unit test coverage as the sign of a strength of a product, but rather focus on system testing to provide a holistic view on the impact of code changes. We are aware that our code is living and that the code we write now is very unlikely to be the same code in a year’s time. Hence this warrants expending our effort where we can get the most value.
We are fully aware that when building a product or implementing significant new features into a product, what we know at the time of implementing will pale in comparison to what we know one year from now, or even one month from now!
We know that it is important to get our products into production fast and learn from their behaviours and shortcomings. All software breaks. We are fully expectant of this and know that we can’t do everything up front to prevent this from happening. You can’t know what you don’t know. That’s why, through following pragmatic approaches to writing our code, iterating on our product and being responsive to change, our products will evolve into the kind of maturity we have come to expect over time. All the while feeding the learning curve so it becomes easier the next time.
Ownership
As developers, we own our product. From building and deploying it, to maintaining it in production, it is our responsibility and we have ownership. This means that if it breaks in the middle of the night or on the weekend, we endeavour to fix/resolve it. No developer in their right mind wants to be woken up in the middle of the night to have to address a problem bleary-eyed. This, therefore, reinforces the idea of being personally responsible for adequate testing, monitoring and alarms for your application. It is your professional responsibility as a software developer.
Being an empowered member of the team and having a high level of ownership also has its perks. Developers love to build things; and we are certainly no different. If a member of the team has an idea or spots a use case where we believe something may be useful to the organisation, we can quickly knock something together to prove its worth, without having to seek approval to do so. It is this kind of mindset that helps developers think about how they may add value to the Guardian whilst also satisfying their own curiosity.
All in all, some of the points discussed are what I consider to be a part of what makes my experiences with working within my current team unique. At its very core, software development is a form of creativity and it’s important to have fun with it! That, coupled with a diverse mix of individuals from different backgrounds and of different experiences who are extremely passionate about what they do, are what make it a joy to come to work every day.
