← Back to home

Life As A Lead Developer

In November 2018, I became one of two lead developers on GOV.UK. Coming from being a mid-level and then senior developer, the step up to becoming a lead is a large one where a lot of attributes of being a developer change and one suddenly has a lot more autonomy over many parts of the role.

So what does a lead developer working on GOV.UK actually do? This is a question that we have been asking ourselves lately as we attempt to codify the role and responsibilities.

Line management and performance management

As a lead developer, I conceptually sit alongside lead developers from other parts of GDS, below the head of software engineering, and look after all developers on GOV.UK. This is not to say that I line manage everyone – we use matrix line management on GOV.UK, and I have a couple of reports in this structure – but I am eventually responsible for this structure and the general performance of everyone in it.

As part of this, my role includes assigning line managers to new starters, moving people if their line manager leaves and validating end-of-year performance marks that line managers assign to their reports along with the head of software engineering and other lead developers.

Developer health

While a lot of people concentrate on the performance management of people in their organisation, as important (if not more) is the “health” of those people. For example, are they happy? Do they have the tools they need? Do they know enough about the systems they’re working on and the technologies they’re using? Imbalances in any of these can result in unhappiness, poor performance and restlessness in the job. My role includes thinking about these aspects and ensuring that any issues are spotted and corrected before they turn into a larger problem.

Knowledge sharing and cross-programme collaboration

GOV.UK is not a island. We rely on a lot of other parts of GDS for things like infrastructure support, APIs and the exchange of ideas and people. However, most people work in teams with set goals and are naturally concentrated on these goals. Without someone sitting above the team structure identifying points of potential collaboration, it’s easy to miss opportunities. This is part of my role.

On GOV.UK, we run a number of initiatives to promote knowledge sharing and collaboration, including a fortnightly meeting open to all GOV.UK developers where we have a series of presentation on different parts of the GOV.UK infrastructure and application architecture which runs on a rotating system. We also bring technical leads from all the teams together once a week for a joint stand-up where we each say what we’ve been working on for the last week and what we’re going to be working on in the coming week. These stand-ups commonly result in individual technical leads having a chat afterwards where they’ve identified something that could benefit both teams or may cause an issue for the other team if not scheduled carefully.

Team allocation

A bit like line management - we need to make sure each team has the correct number of developers to match its scope, as well as a good distribution of apprentice, junior, mid-level and senior positions and a mix of levels of experience of GOV.UK. And of course, all this is bounded by the number of developers we have in total, taking into account those who are leaving and new starters as well as those coming back from leave or moving to and from other parts of GDS.

Roadmap: knowing what’s feasible

GOV.UK, like other parts of GDS, has a forward-looking view of projects for the next year or so. This “roadmap” is normally built from a product point-of-view (here are the things we’d like to do) but needs input from a build point-of-view (here are the things we can realistically do based on the time, scope and number of people). Lead developers and technical architects provide this point-of-view.

Ensuring quality

There are a lot of things being worked on at any one time on GOV.UK, and like most organisations, we have a set of technical standards that we adhere to. These may be low-level (like preferred coding practices) or higher level (which languages and frameworks we use). Low level standards can usually be managed automatically (for example, we use code “linting” to let us know if code does not meet our standards) but high level standards need to be managed by people.

Part of the lead developer role is to keep track of what’s being built, and make sure it meets these standards. Some of this is done by having regular meetings with the technical leads of the various teams to ensure this is the case, as well as identifying cases where new standards (or changes to existing ones) are needed and where teams can share code or expertise.

Long term technical work

Like any software development organisation, we have “technical debt” - that is, code that we know is not up to scratch, or not built in the most sustainable way, or maybe it uses another piece of code or service that’s no longer being maintained. In these cases, we track this debt and aim to “pay it off” either within teams as they come to work on the relevant codebase, or as ad-hoc fixes if they are small enough. Lead developers and technical architects help track this debt and categorise its urgency.

Being a go-to person

A lot of time, people just need someone else to talk though their idea with to make sure it makes sense or to ask questions about weird edge cases or things to be aware of. In many cases, the lead developer becomes this go-to person since we’re meant to have a good overview of what’s happening, and enough experience of the various parts to be able to give meaningful answers. There are many good questions about alignment, direction and consistency that I enjoy discussing. However, we don’t want to become single points of knowledge or take away any of the autonomy of the teams to do what they think is the right thing. For this reason, decisions about products and features should be made within the team.

Helping tech leads

As already mentioned, lead developers work closely with the technical leads from each team to find common themes and help with with their own leadership.

Policy

As with all large organisations, we have processes and policies about things like how applications are deployed. The responsibility for devising and maintaining these falls to lead developers and technical architects.

Things off the critical path

If all we ever did was the work that happens in individual teams, then a lot of non-critical but still important things would be missed. For example, experimenting with new technologies, refactoring existing code or adding support for new standards like HTTP/2 are all things that an individual team would not work on because they are not critical and they will also not take an entire team for a quarter to implement. This doesn’t necessarily mean that lead developers will work on and build these things, but we track and prioritise them and will work on certain things. For other things, we may create a small ad-hoc team of people to work on it in addition to normal team backlog work.

For example, at the moment a small team is experimenting with Concourse for continuous integration.

So what’s the tl;dr?

There are a lot of things to think about! The lead developer responsibilities are many and varied and encompass a wide variety of seemingly unconnected things, but perhaps can be summed up as “be there for others and do what others don’t”. In that sense, the role is infinitely flexible and therefore also very rewarding. There’s also probably nothing quite like it anywhere else.

If this sounds like a good place to work, take a look at Working for GDS - we’re usually in search of talented people to come and join the team.