A story of progression
One piece of feedback I regularly hear from engineers is the difficulty they have with their career growth. Although that is a relatively broad subject, the majority of those that raise it, acknowledge the same difficulties.
- A lack of clarity within their existing role
- Lack of transparency with what is required in roles in and around them
- Limited opportunities for growth
This is not anything new, when I was growing as an engineer, I had the same challenges and I looked to companies like Monzo, who open sourced their progression framework, to see how I could learn, grow and develop. Through my time at Vodafone, it became clear we needed something similar and a framework we could utilise for all our web engineers to see how they can observe gaps in their skills, close them and progress through their career.
This article aims to shed some light on what we did, why we did it, some improvements along the way and also what comes next.
First Draft
In 2019 we first observed we had a problem with career growth. At the time, we were experiencing relatively high churn and people were leaving for pastures new, where they could grow their role and their remit. It was a real tough time and something we acknowledged through exit interviews that career progression had taken a back seat to delivery. Our first mission to solve this problem was to start with why — what did we want a technical career path to be — what did we want it to achieve. Was it simply just for individuals to gain a promotion and ultimately more salary, or was there other growth opportunities we wanted people to acknowledge through this change.
We realised that this wouldn’t be made for one specific purpose — it could help in any number of ways for users to adopt new learnings, career growth and self reflection. In our initial discovery phase we identified 5 key areas we felt our engineers would care about -
💬 Communication
One of the key pillars to how engineers deliver and have work flow through their team(s) is how they communicate. In this pillar, it’s more than simply their ability to talk about technical problems and we discovered that an engineers communication skills were key to their ability to grow within their role.
🚀 Deliverables
What they do, was just as important as how they do it and their output and impact were key metrics for defining someones success within role and beyond. Deliverables was a key focus area for any developer — ensuring quality, for example, was being baked in to every facet of delivery.
💻 Core Mastery
In our world, this was JavaScript. How much of the core fundamentals did you know and could apply them to what you did. Understanding this was key to any foundation you had within your role and any further growth you could obtain.
⚒️ Tools
Helping growth within the discipline was something we want people to consider — and we factored this under tooling. Getting engineers to adopt Vodafone’s mantra of build over buy where possible and creating new tooling, that would grant shared capabilities across our squads.
⭐ Influence
Finally, one area that is much harder to quantify was influence — how effective is an engineer at swaying the hearts and minds of those around them. How can they bring people with them on the journey. Sometimes development is a hard graft and selling our dreams is even harder — having team members who can get people to be as enthusiastic as they are was something we believed key to our growth.
Now the hard part
Understanding what would be part of each of one of these pillars was something as an engineering leadership group we knew would be hard. We also had to consider how each one of them could be different at each varying level. To visualise this we began by creating Kanban style boards for each level/role we had within the discipline, in our case Junior Software Engineer, Software Engineer and so on. With a home now for each level and something to aim for we began brainstorming all the different types of expertise, knowledge and skills that someone of that level would require.
We started at entry level, we felt this would prove the best use case for acknowledging what someone should know a baseline for starting their career within development. The essential skills and know how that start an individual off — we looked at creating cards within out Kanban boards and within each filling them with examples of what it would mean to do this, what you should know and how to exhibit the behaviour.
For example, within Communication we had a card for PR Reviews — something essential for all developers to know about. We wanted to ensure all engineers started with the baseline for what constitutes a good PR, this includes:
- A description of the change, and justifications needed for certain technical or architectural decisions made
- A description of how to test it
- Potentially a screenshot of how it should look
We wanted individuals to use the board as a way to collect evidence and showcase their ability, so within the card they could add feedback, from peers that they have worked with or example PR’s they have been part of even submitted themselves. Our aim was to grow each specific use case as the levels grew also — in this example we would expect our seniors to be more heavily involved in constructive feedback within PR’s or raising them into shared utilities or libraries, rather than their own team or application.
Through a series of weeks and reviews we were able to develop the core roles we had into 3 individual boards. Each of them taking from the one before it and growing in expertise. Within each pillar, we had multiple areas of focus, so engineers could see a broad range of areas they could focus on and within, whilst also still being able to collect continuing evidence against areas they would be delivering against daily.
Did people use it?
So now we had a mechanism — how were people going to use it (and did they?). Firstly we walked our teams through and offered an opportunity to feedback — we found some areas too deep, or not aligned to a particular level — we found that some details were too verbose and over complicated — we wanted to ensure we had a tool that was aligned to the expectation of our teams and one that would be used. We laid out the why — this could be used in multiple ways but its primary focus was 2 fold:
- For people in role to acknowledge the expectation at their level (Solving our first challenge)
- For people to see what the role above them entails and the expectation there (Solving challenge number 2)
We believed that if someone had access to these 2 points — it would identify gaps — in which they could work with their engineering manager to look for opportunities. We had this exact use case, where many people identified Accessibility as an area of focus — from this we had a work-stream focusing on automating accessibility tests, fixing inherent AA issues and sharing auditor feedback from accessibility audits — it made a way for us to identify who needed that exposure — we simply then needed to make it happen.
Our expectation was for people to clone the master board and then use that as a base to make it their own. Some would colour code — knowing which areas to focus on. Some would set dates and align themselves to their quarterly goals and objectives so they could effectively set themselves targets to hit every 3 months. There was no right or wrong way to use the framework — it essentially became a way for individuals to tell a story, a “This is your life” of sorts. A way in which someones career path could be laid out, documented, worked on collaboratively and challenged to get the desired outcome — whatever that may be.
As engineers worked closely with their managers — we realised that we needed to set expectations. At what point would someone know they could be the next level? Through trial and error it became clear there was a sweet spot — somewhere in the region of 80% — once someone had got to that coverage across their board — where they were consistently performing at that level — we could kick off the process. Working with their line manager, they could build a case for promotion, that was almost bullet proof — the board had everything, top to bottom — including what they delivered, how they did it and with evidence.
What next?
Through this framework — we have so far promoted 7 people in 2 years in Web Engineering (that is ~ 17% of our headcount) and continue to use it, but there is still more to do.
The technology we selected was not fit for purpose — we need to look at a better way, likely through code. One of the issues with Microsoft Tasks, is that it is only accurate at time of writing. Users were copying the master planner and updating/managing their own. As soon as they cloned the board, they lost any connection to the master — meaning they would lose any updates made. That could be new skills or updates of existing. Ideally we wanted a living, breathing version of our progression framework that could sync updates as and when they are made.
We want to add more levels — we spent a lot of time making sure the Junior and Software Engineer roles were deeply detailed — but spent less time on our Seniors and Engineering Managers. We want to ensure no matter the role, you were able to see a roadmap of progression, this includes creating new boards for software apprentices, as an example.
The need to share this wider than web engineering is growing. When we started this journey we shared a close relationship with our platform teams to ensure this was something as useful to them as it was to us. We now want to broaden the horizons of this tool into wider facets of Vodafone’s engineering estate through a global programme, transforming our technical career path.
This is really, only scratching the surface of what we have done so far and what’s to come.
- How do you manage your career today?
- What other tooling have you used?
Really keen to share and grow this over time, so feel free to leave any comments you have or get in touch to help shape your own career.
