We thought we’d try and explain the approach we’ve adopted to hiring and nurturing the right development skills. We realise it may not be clear to those not part of GDS why we solely advertise for full stack developers but then have separate frontend and backend communities. Our aim is to ensure we have the right developers on each project and provide them with strong communities and learning development opportunities.
Why we recruit full stack developers
All our developer job adverts are for full stack skills because we want people who can work on a full set of technology, including both frontend and backend systems. In the Service Manual, we talk about the general job role of ‘developers’ and don’t segregate skills into two camps.
We take this general approach to recruitment and service design because we want developers to feel they have a licence to do everything. We don’t want developers to feel they can only be associated with a single community.
Importantly we want all our developers to understand the full spectrum of development. They need to be able to understand the layer they’re working in very well but also have knowledge of the layers above and below, eg a frontend developer doesn’t need to know exactly how to implement a particular security component but they do need to know at what stage of the frontend process they should ask for help.
In alpha projects, knowledge of the full development stack is essential. Sometimes there will be just a single developer in the team and they’ll have to get things moving quickly. The idea of an alpha project is to prove a concept so the quality of the product only needs to be to a reasonable standard. It doesn’t need the polish that often comes with specialist skills.
The need for a frontend and backend community
When projects get bigger there is a real need for increased specialist development skills. Previously, it was common to expect developers to program across a full stack of technology for the entire length of the project, but that’s now virtually impossible. We’ve shifted to more complex technologies and this is leading to developers becoming increasingly focussed on one part of the stack.
We recognise these specialisms by having two defined communities at GDS: one for frontend developers and another for backend specialists. We assume all new recruits entering non-junior roles will have specialist skills, or a preference for one of the communities (or at least a preference for the server or client side), as well as the general full stack knowledge.
Our CV sifting and interview process reflects this. We ask everyone for evidence of security skills (more of a backend focus), but then we ask everyone a question about accessibility (a frontend focus). During the interview, the process diverges slightly in that there’s a code pairing test for backend developers and a web page markup exercise for frontend developers. Everyone we hire can choose their primary community, as well as a secondary community, eg a frontend developer may choose backend development as their secondary community but they could also choose design or user research.
If a developer is put on an alpha project to work on the full technology stack, they’ll later adopt the function of their primary community as the project becomes more mature. It’s important we don’t just have a select number of full stack developers moving around all the alpha projects at GDS. This wouldn’t work, as during an alpha development stage, developers learn what works and what doesn’t and we don’t want that knowledge wasted.
It’s also important that we keep thinking of all our developers as full stack. Too many specialisms mean it’s more difficult to be agile; you can’t just re-assign developers to different projects as the need arises. This kind of thinking allows many individuals to move back and forth between our communities, building out their skills.
Our mix of backend and frontend skills
Within GDS, we have around 80 backend developers and 20 focused on the frontend, a split that tends to be common in development.
Different people in different places will have their own ideas on what backend and frontend skills are. For some, backend development is database development and for others it’s JavaScript.
Our frontends are built using progressive enhancement and we try to find developers experienced in this methodology, while also skilled in understanding browser quirks and the performance implications of different clients. We recruit developers passionate about accessibility since this is one of the core requirements we have at GDS: to make our content accessible to all. In frontend work, small changes can have a big impact on people’s lives.
For our backend, we try and find developers who have specific expertise, such as experience in building large-scale distributed systems. We also look for understanding of how to set up database structures, search systems and analytics processes.
Sometimes we don’t find exactly the right skills but if a developer has a positive attitude, good presentation skills and can validate their opinions with colleagues, we’re more likely to ask them to become part of our communities. All our developers need an investigative mind; for frontend developers the environment is the big unknown but for backend developers it may be data and security.
Ensuring our tech communities work together
In addition to hiring full stack developers, we ensure our technology disciplines remain connected through our working practices and event workshops.
We hold a ‘Tech Away Day’ twice a year, which involves a series of lightning talks. This helps our developers understand what other GDS teams are doing and the different tools they’re using.
Meanwhile our working practices at GDS frequently involve backend developers being paired with frontend developers. Rather than a development team assigning work according to primary communities, they’ll tend to look at a developer’s skills and experience using particular tools instead.
There are other opportunities for our communities to learn from each other. GOV.UK is currently migrating to a new architecture and while many backend developers are needed to do the actual migration, there are frontend developers on the project generating requirements and making sure it’s suitable for their future needs.
And because we don’t pigeonhole developers, it means that like other DevOps organisations, our communities and job roles overlap a lot. Designers will design in code using CSS and sometimes JavaScript but they tend to differ from frontend developers in how robust they make applications. Frontend developers will do bits of design and backend work so will be familiar with tools like Ruby on Rails, as well as the GOV.UK Components Guide. Backend developers will understand the basics of frontend tools and the importance of user needs and accessibility. Their job roles often overlap with web operations specialists, who in turn often deploy applications to servers, while fulfilling their primary responsibilities of building, configuring and managing the server platforms.
The benefit of having such flexible communities is that it allows junior developers to move around. In fact at the junior level, we don’t have any distinction between frontend and backend responsibilities; they’re all recruited under the job title of ‘junior technologists’.
We feel we’re taking a pragmatic approach to development skills. Confining technology staff to their original job specification may be common practice but it just wouldn’t fit our agile way of working.
You can follow Richard and Robin on Twitter, sign up now for email updates from this blog or subscribe to the feed.
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.
