Until recently, career development for technologists at GDS was relatively unstructured, and dependent on what opportunities came up. Over the last few months I’ve been leading on developing a more structured career path for developers and web operations engineers. This blog post describes what that involved.
Working out our values
First, we needed to be clear on what skills we expect someone to demonstrate at each level (e.g. junior, senior). Every organisation has implicit cultural values, and we wanted to draw these out as well as technical skills, so it’s clear what behaviours we want to reward at GDS.
It's really important in government that people are well rounded, for example having the skills to share externally the things we do at GDS, having an ability to coach and lead colleagues. Making these things explicit is an important part of the exercise, and is one reason why it’s hard to take a career path from another organisation – their values might not reflect yours.
To identify these skills and values we held a series of facilitated workshops with a group of people from our technology community. In order to involve more of our technologists, bob walker, Daniel Roseman and Tom Byers gathered feedback between the workshops from others in the web operations, backend development and frontend development communities.
We also decided at this point that there shouldn't be a frontend/backend distinction; many of the skills are the same, and we want to encourage people to work across the full stack.
Adding more technical skills
The workshops produced an outline of what skills were expected at each level. However, it was quite light on details of technical expertise. It's harder to work that out by committee.
Myself, Brad Wright and James Stewart – three technical architects who are also senior line managers – listed the technical competencies we expect at each level. We also talked to line managers to see how what we had come up with fitted in with how we were already working on developing people.
At this point we had an alpha version of the career paths document, definitely not formatted as we would like, but with the information we had learned in it. You can download the first version as a PDF: Developer:web op career paths v1.0.
Use of the career path
The main aim of the career path work is to help people clarify where they are in their careers and what to focus on when working out how to progress, so the way the document is meant to be used is in a conversation with your line manager to talk about where you want to get to, and what practical things to focus on to help you get there.
The conversation focuses on the four skill areas: technical expertise, delivery, digital evangelism and leadership. So for example, you might be a developer, with technical skills at a senior developer level, but weaker on evangelism and leadership. If your goal is to get to senior developer, we would work out some objectives that would help you develop in the evangelism skill area (for example, blogging, speaking at events) and leadership (for example being a tech lead, line management, or owning a non-technical project).
Too much information!
Once we had version 1.0 of the document, the next thing to do was use the tech line managers as guinea pigs. I pitched the work so far and the conversation template at a meeting of the tech line managers (there were about 18 at the time) and asked them to go through the process with their own line managers and let us know how it went.
This process of user-testing was very useful and we learned a lot.
For example, one thing I had tried to make very clear was that this is not meant to be a tick-box exercise. It should not be the case that if you can show one example of each skill at each level, you automatically progress to the next level. The examples are meant to be an indication of the sorts of things you can be expected to do.
However, including so much detail at each level made it very hard to not do it as a tick-box exercise. Contrary to what we had expected, we needed to include less detail, to make it clearer that they were examples.
It was a useful framework for working out specific areas of development
One important thing we discovered was that even though the document itself still needed further development, the conversations using it were some of the most constructive and useful line management conversations we’d had so far.
I line manage four people, and all four of them came out of our conversation with useful, practical development objectives that they were able to immediately start working on in order to develop their careers as a technologist within GDS.
It’s still a work in progress
We’ve made some changes based on the feedback from the tech line managers, and with input from James Holloway, then a writer at GDS, we produced the next version, which you can also download as a PDF: Career_pathing_for_technologists_v2.0. We’re now using it, and all technologists at GDS have had an opportunity to work out their career plan with their line managers. There are still many areas for improvement, and Alice Bartlett, Edd Sowden and others are currently working on the next iteration.
One interesting point is that we may have gone too far the other way on removing detail. I suspect the way to balance this will be around how we communicate the process, rather than reaching a genuinely “perfect” amount of detail (this is another reason this document may not, as it stands, work for your organisation).
There are also several areas we didn't touch on and will have to be addressed in future. For example, this is not currently related to salary. The career development conversation with your line manager is about where you sit at the moment, where you would like to get to and what steps to take to get there, purely from a skills and career development perspective.
In addition, at the moment this is separate to the annual review process, though the areas for development identified here are really useful for working out development objectives for the annual review process.
It’s definitely been worth doing
Working out our career paths has been a really useful process and we are now doing it for other roles, such as delivery managers and designers. One important thing we’ve learned is that while the finished artefact is useful, the process of how you create that artefact is more important. It has to reflect what you value as an organisation, and this process forces you to be clear about what that is.
GDS started in 2011 with a small team of 12 people, and then grew very rapidly until we numbered 600 in 2014. When your organisation is first getting established, things like structured career development are rarely the top priority. Now we are maturing and people are thinking about staying on for some time, it’s critical to make sure we put these things in place.
If this sounds like somewhere you'd like to work, we are currently hiring for developers and web operations engineers. We are always in search of talented people to join the team so take a look at Working for GDS.
You can follow Anna on Twitter, sign up now for email updates from this blog or subscribe to the feed.
6 comments
Comment by Paul Moffat posted on
very interesting article. I'm going to ensure that the various Partner Organisations across the BIS family take a look and see how thaey might adopt a similar approach.
I have a question thgugh; why produce PDFs and not html docs?
Comment by Anna Shipman posted on
Thanks!
And good point. The way we shared these documents internally was using Google Drive so a PDF seemed the best way to share them externally. They are still a work in progress but once we have a more stable version it is likely they'll be HTML docs instead rather than continuing to be shared in Google Drive.
Comment by Bob Cratchett posted on
You should really try writing documents in markdown. Use Github hooks to compile into HTML. It's really easy to add line-by-line comments and suggest changes using Github, and you avoid PDF which involves slow, buggy and generally proprietary software.
Comment by Anna Shipman posted on
Yes, we do use Markdown for some things. However, when collaborating on documents like this it's not the best tool; for example you can only comment per line, not per word, and not everyone who is working on this is technical so not everyone is familiar with GitHub workflow. It is very useful in other contexts though.
Thanks for your comment!
Comment by Atticus May posted on
Some key phrases appear to be missing in the role specs - "code golf l33t", "ruby rock-star" and "penchant for rewriting key components in obscure languages".
Comment by Anna Shipman posted on
Funnily enough, that's not quite what we're looking for 🙂