All kinds of awesome: upgrading your tech career path

So, how was your last appraisal? Is it even possible to answer that question without a sigh and raised eyebrows? Aren’t career paths and ratings just the sort of corporate blunt instrument that many coders and designers join start-ups to escape?

I’d like to argue that a formal career framework can be a force for good, even in smaller organisations. If you’ve ever felt overlooked or taken for granted; if you left a job you liked because it wasn’t going anywhere; if performance management admin has driven you to despair; this blog post is for you.

Earlier this year the business where I work, MPB, introduced a career framework for software engineers and product owners. I’d like to share how it came about and what we’ve learned.

But first some background. We’re not a large enterprise but we are now expanding well beyond our start-up roots. Like many organisations in the same position, there are challenges to address.

Management becomes more complex . As we ramp up hiring, we need clearer concepts of seniority (and pay scales to match). Equally, our people don’t want to lose the small-team ethos they value. And anyway, in the modern workplace, where does the idea of career progression sit alongside flat management structures and T-shaped all-rounders?

Believe it or not, the answer to all these potential obstacles begins with the word “happy”.

In an earlier post, I mentioned our take on Jonathan Smart’s ideas (see Sooner, Safer, Happier). We were clear that our main goal was to create a more engaged and motivated team whose members know exactly what awesome looks like.

But what does that look like? Can you measure awesome? Well yes, it turns out you can.

The breakdown

Inspired by Monzo’s open-source product and engineering framework, we produced a list of competencies and behaviours based on MPB’s business needs and values.

Yours will look different but for us, this started with five main section headings. We chose communication, impact, leadership, influence and mastery — because the ‘how’ matters every bit as much as the ‘what’. We’ve always valued technical and domain acumen but there’s much more to building a team that’s greater than the sum of its parts.

For each role, the sections are broken down into a set of competencies, both general and role-specific, each rated at one of five levels, increasing in seniority from level 1 to level 5.

So for software engineers, communication at level 1 might mean active participation in code reviews while at level 5 we’d look at effective communication with non-technical stakeholders. And so on.

Nobody said this was going to be a quick fix! But fortunately/unfortunately, at that time everyone had pretty much the same job title so there weren’t too many roles to analyse in this way.

Reaching consensus

It’s all very well writing these ideas down but without buy-in from the team it’s just theatre. After all, having happier team members is sort of the point.

We spent a lot of time listening. We launched a consultation exercise, being careful to include public and private feedback channels so all voices could be heard. And most people did contribute their views, positive and negative.

There genuinely are cons as well as pros, of course. There’s a lot to be said for a very flat structure. But the majority of views were along the lines that people understood why a growing team needed to move towards this kind of structure.

They had clear views, too, about avoiding control behaviours, keeping their autonomy in decision-making and seeing senior colleagues as ‘servant-leaders’, helpers and mentors — exactly the sort of behaviours we all value.

We also needed to talk about what to call people. Should we go for Level 1, 2, 3 etc? In which case, is level 1 high or low? In the end we settled on (for example) Associate Software Engineer at the junior level, rising to Software Engineer, Senior Software Engineer, Lead Software Engineer and Staff Engineer. Similar terminology applies to Site Reliability Engineers, Product Owners and UX/UI professionals.

We felt strongly that seniority shouldn’t have to mean ‘people management’. We recognise the idea of Individual Contributors, who influence, mentor and certainly lead with a small ‘L’ but don’t have direct reports. Being promoted doesn’t automatically mean you stop coding.

So each role has people leadership and non-people-leadership tracks. Where the most senior management level might be ‘Head of UX Design’, the non-people leadership equivalent would be ‘Staff Site Reliability Engineer’. We don’t have all these roles (yet) but our career framework is future-proof and encourages ambition.

Cultural evolution

Modernising our ways of working requires more than just retitling everyone. We’ve talked a lot about people becoming more ‘T-shaped’ (ie contributing across disciplines) because it supports better systems of collaboration. In future we’ll look to hire people who are explicitly full-stack, and cross-disciplinary expertise is something we value highly.

At the same time, we recognised there could be some emotional responses. Someone who feels they’re a front-end engineer on a fundamental level might be concerned and we needed to acknowledge that.

We’ve asked people to voice these concerns with their team leader because we have a wide range of disciplines. We certainly aren’t asking everyone to become expert in test automation or write Python. That concerned front-end specialist might take responsibility for a product design flow — not necessarily coding but it still helps the team deliver. The more people can pitch in as needed, the faster the team can deliver.

There’s no doubt this has been a cultural change but the vast majority have come along with it.

A human machine

We’ve rolled out our career framework and are learning as we grow. After a year of talking over all these themes, and documenting everything to a high level of detail, there shouldn’t be any surprises.

I’m sometimes asked whether some aspect or other is optional. I’ve generally replied that investing in your career is always optional. That’s a serious point.

Depending on your stage of life, you might want to devote more or less energy to your career. For example if you have a new baby it’s probably reasonable to deliver but not over-deliver. Two years later you might feel it’s time to ‘opt in’ and aim for seniority.

All we can do is encourage people’s ambition, be clear what awesome looks like and reward accordingly. The only mandatory thing is to read the framework and understand what’s expected.

Come the (hopefully not-so-dreaded) appraisal you have a chance to demonstrate where you’re already killing it and where you see opportunities to improve. Those might involve learning on the job, R&D time, formal training or looking for ways to work across teams.

Closing thoughts

So. Is this all going to make for a happier, more engaged team in the real world? Isn’t there a risk of losing anyone who doesn’t like this way of working? Yes and yes, of course, though I’d rather we be clear about what awesome looks like and have people buy in, rather than sweep things under the carpet or give out weasel words.

In reality, at our last round of appraisals people told us they now understood better what was being asked of them, and what they needed to do to succeed.

At the end of the day this is about career progression, which at its most basic involves getting paid more for your work. It’s normal to pay more to those who make more impact. To do that fairly and transparently, we need to make sure we’re comparing apples with apples.

Having our framework document means that how well you do at work doesn’t come down to how long you’ve been here, whether we get on outside work or how much you say in meetings. It might seem mechanistic to some but without a framework like this, how can people possibly feel we’re being fair?

And when it comes to new hires, we need to bring people in at the appropriate scale. We’ve benchmarked rewards against industry standards, and someone who comes in at a particular level will know exactly what’s expected of them from the outset. That’s being fair to them and to existing colleagues, too.

Sophie Davies-Patrick is Chief Technology Officer at MPB, the UK’s leading reseller of photographic equipment with operations in Britain, Europe and North America. https://www.mpb.com