A huge challenge as a leader in the technology industry is being able to communicate through the complexity in a way that helps the people in your team not only understand what you expect of them, but also what they can do to improve, what goals they might want to consider aiming for in the future, and what they might need to do to make those goals more achievable.
I've spent 21 years in technology and the past 15 of those leading large teams of developers in digital technology. One of the things I've always prided myself on has been my focus on being a leader of people, not a manager of people: I care about my team as people, and my focus is on helping them to develop and grow in their careers through opportunity, support, mentoring, training and setting clear expectations.
Answering questions like "what do I need to do to get better", "what is the difference between a solution architect and a technical lead" and "what is the difference between a mid and a senior developer" is an essential part of everyday life as a technology leader. Let's face it: if you can't answer these questions clearly and in a way that makes sense to your team members, then you're not really helping them at all—you're just ticking the boxes.
But it's not easy. The skillset of a developer, as we will see, is multifaceted and varied. Roles (particularly senior roles) demand a complex combination of hard (technical) and soft skills. Often, the definition of these roles and the KPIs associated focus on the technical as a priority, and this is fine up to a point.
Unfortunately, progressing as a senior developer and beyond is often more about the soft skills than anything else, and these can sometimes be perceived as vague and subjective, and therefore difficult to quantify. And depending on your skill as a leader in building trust in your team and communicating effectively, this perception can sometimes cause a feeling of inequity or unfairness to develop.
To conquer this challenge, at Merkle Australia we've developed a Career Progression Framework that provides a foundation for simplifying this complexity and helping to make the answers to these questions (and more) easier to find, and easier to understand.
All our crafts, from design to technology, project management to business analysis, use a framework very similar to this. And to be fair, I didn't invent this personally: that credit belongs to our Heads of Design, Dave Calleja and Miles Cox; all I did was use the framework they provided and create a customised version of it that was tailored to technology.
In this article, I'm going to share how the framework has been applied to technology in our team.
So if you're a team leader reading this, perhaps you should consider whether this is something you need to implement for your own team. And if you're a developer, maybe you should ask what your business is doing for you in this area? Do you really understand what's expected of you, and what opportunities your business provides for you, other than to just be more senior?
Or you could come and work for us!
Developers are the same—or are they?
In my team right now, I have 6 different types of developer. And I'm not talking about different levels of seniority. Seniority is there, too, but in itself it's relatively simple to think about. What I'm talking about here are completely different types of developer, each with a different set of skills, and each competent in a different set of tools and capable of delivering a product or providing a service that is unique to them and cannot be (easily) delivered by any of the other types of developers.
Some of these developers are back-end focused, some are front-end. Some are both. Some know ReactJS, some know VueJS, and some are more traditional front-end developers with skills in native Javascript, HTML and CSS. Some developers are specialist mobile developers, while others are focused on building websites using large platforms like Sitecore and Adobe AEM. Some like building custom solutions and don't really want to work on platforms at all.
This complex mix of skillsets I've just described is only a small fraction of what's required from a technology team to be able to deliver industry-leading digital experiences today, and it doesn't include supporting skillsets like quality engineering, devops and infrastructure, which are also each critical in their own right.
I'll freely admit that leading a team of this size and complexity is challenging. But if it's hard for me as a leader with 21 years' experience, imagine being a university graduate today. You believe you're setting out into the world on a path to become a "developer", yet you're confronted with what I just described—and that's only in one small part of the industry! It doesn't even start to talk about any of the other forms of "developer" that might be out there that aren't related to the industry I work in: traditional software, games, CRM, database, AI, etc.
Just in the one business, you need to understand the difference between a front-end developer, a React developer, a web developer, a Javascript developer and an experience developer. And at some point, you'd probably figure out the truth: that they're all really just variations of the same thing, with specialisations (or lack thereof) in slightly different areas of the same broad skillset.
Imagine now, as that graduate, trying to understand all of this and the way it plugs together, and then somehow figure out what's expected of you day-to-day, what tools and technologies you're expected to develop yourself in, where you should focus your energies to even get started, and what skills and key capabilities are going to take you places in future. How could you possibly know? After all, there are job titles and critical skills in technology today that didn't exist 5 years ago ("React Developer", "Chief Digital Officer"), and in 5 years' time will no doubt be job titles from today that are gone as well.
Using a framework to make the complex seem straightforward
This variation in skillsets has historically caused a great deal of complexity in how technology leaders help their teams grow and develop. The theory goes that a front-end developer has a vastly different set of skills, and therefore different expectations and areas of focus for growth, than a back-end developer. This complexity made the process of discussing skills, expectations and growth opportunities difficult, and many leaders tended towards generics and lack of detail in review conversations which ultimately aren't really all that helpful.
Ironically, though, if you break this complexity down, things get simpler to manage, and therefore simpler to communicate and explain.
Developers (or anyone else, for that matter) ultimately need to understand four key things:
- what is expected of them in their current role so they can perform;
- where they currently sit in terms of their experience and capability;
- what career path options are available to them in the future; and,
- what skills they need to develop in order to proceed down their chosen career paths
At Merkle, our Career Progression Framework is a framework for simplifying the complexities in the environment and providing a mechanism to communicate those four key things within our team.
We use it to clarify expectations, to set goals, to conduct performance reviews, to manage professional development, and to do career planning. At its core, it's quite simple, which is probably why it works. It uses the concepts of themes, skill areas and competency levels.
- Themes — these relate to the role of developers with in the business, in that they should contribute to the vision of the business, their ways of working are imperative in how they do what they do, their execution is deeply linked to quality, and their foundations represent their specific technological areas of expertise
- Skill areas — the types of things that a developer is expected to be good at in order to perform and excel in their role; through the use of themes, we've been able to differentiate between hard technical skills, which may vary with each type of developer and are included in the foundations theme, and softer, more transferable skills which apply regardless of the type of developer, represent the bulk of the other three themes, and which will more often vary significantly based on seniority, not skillset
- Competency levels — deliberately not referred to as "experience" level, this represents the level of competence (through specific, demonstrated actions) of a developer within each particular skill area, and usually varies depending on the skill area itself as most people have a mix strengths and weaknesses
In our case, we have 11 skill areas spread across 4 themes, with 6 competency levels. Our skill areas are sometimes also closely linked to some of our core organisation values, allowing us to ensure that our values shine through in the expectations we place on our team and therefore the work we deliver.
Our competency levels in particular are not referred to as "experience" levels, since experience is traditionally something most people mentally equate to "years of service", and this is not the same thing. Some developers can mature and develop much faster than others; some, much slower. It's important we recognise what they can do, not how long they've been around.
Having an awareness of a particular skillset and perhaps a basic understanding and familiarity with it is the entry point for most skill areas, and over time a developer's knowledge will progress through beginning and developing levels of competence. Once they have reached the modelling stage, we consider that they are able to work autonomously and with minimal oversight in that particular skill area, and from there they progress to advanced and, ultimately, to specialist.
The reality of the situation is we don't expect everybody to achieve the specialist level: this is reserved for people in our team who are respected leaders not only internally, but also in the industry and have a presence and gravitas in that particular skill area that completely sets them apart from their peers.
Competency in given skill areas are ultimately tied to seniority through the expectations of various roles, but more on that in a moment. First, we need to do something else.
While the competency levels you can see from the diagram have a generic word picture associated with them, from here what we also have done is create a matrix of mappings between different skill areas and the levels of competency. This matrix contains detailed word pictures and examples of what it means to be performing at the level of competence indicated in each given skill, so that at any given time a person in our team can refer to that word picture and the examples provided and see directly how it relates to their own attributes and the work they are doing on a day to day basis.
Importantly, this should not be confused with a skills matrix that you might hold as a leader, where you plot individual skillsets and capabilities on a matrix against what you require as a business to be able to deliver on your objectives and manage IP and key person risk. The purpose of this matrix is not to manage capability or risk, but to help with the development of the team and to help explain the differences between each level of competence, so that we can more accurately assess and talk about competency (and therefore seniority).
Drilling down into one particular example of these, the benefits of providing word pictures and examples can be seen.
Seniority isn't exactly straightforward, either
Seniority, as I mentioned earlier, is relatively simple to think about, but the key word there is relatively. Yes, at the lower end of the spectrum, you have a developer who starts out as a graduate and, over time and as their experience and capability grows, they are "promoted" through junior (or in our case, "associate"), mid and senior.
So your path looks something like this.
The path beyond this, though, becomes a little less clear. When someone eventually becomes a senior developer, they typically end up at some stage being faced with a choice that can go one of three ways (in terms of career path):
- They wish to lead other developers or teams of people. At Merkle, we refer to this as the leadership path.
- They wish to stay involved intimately with technology, but wish to work with higher-order challenges and move away from coding to solution design. We refer to this as the architecture path.
- They wish to stay "on the tools" and really like doing development work day-to-day, and they just want to be a really amazing developer. This is the practitioner path.
Historically, most developers have been forced to choose one of the first two. The path for someone to remain a practitioner has been somewhat less clear, particular since most roles in business have levels of seniority which are tied to salary ranges. Therefore, in order to remain a senior developer indefinitely, a person may find it harder and harder to secure any further pay increases, usually because the salary ranges are designed to cater to the majority.
While very few people will want to remain a developer forever, and most will eventually choose one of the other two paths, in the short- to medium-term what I've seen usually eventuate in these cases is that the person leaves their permanent role to become a contingent worker/contractor and is paid a high daily rate at the cost of personal development opportunities and job security.
This eventuality means we lose a great team member, and tends towards greater dependence on hiring in contractors across the industry (since all the great people who want to remain coding day-to-day will eventually go down this path if there are no alternatives available to them).
At Merkle, we've recognised this, and so we've created a new permanent role to recognise highly-skilled developers who just want to be kick-arse developers and not do anything else.
By implementing a Principal Developer role, we've been able to recognise our most senior and experienced people, keep them engaged with us as permanent employees, and give them a way to continue to grow, develop with us, and we've removed some of the challenges we face in regard to salary flexibility. Our clients also know that when they're working with a Principal Developer, that they're the cream of the crop and are worth more than the sum of their parts (so to speak), and so they're often happy to pay a premium for them because the difference is easily visible.
Put alongside our other paths, what this looks like is this:
Obviously there are further steps down each of these journeys, but that's not so relevant today. What is relevant is how we've opened up additional pathways for our team to grow, and for us to reward loyalty, and also how we've tied this to our career progression framework, which I'll cover next.
Taking the next step: mapping competency to roles to establish a base
What we've spoken about so far has given us the basis for conversations about skills and expectations, but what we haven't done is document what our expectations are of the various different roles that developers will perform in their lifetime.
This is really the critical step, because by doing this, we'll be tying everything together, and we'll be setting up a way to answer those key questions: "what do I need to do to get better", "what is the difference between a solution architect and a technical lead" and "what is the difference between a mid and a senior developer".
In order to do this, it's quite straightforward. All we do is assign each competency level with a number between 1 and 6. Using these numbers, we can then do two things:
- We can plot a person's current competency in each skill area on a radar chart.
- We can plot the expected level of competency for each skill area for any given role on that same chart.
So we end up with a "baseline example" radar chart of an associate developer, a mid-level developer, a senior developer, a technical lead, an architect, and so on. And we also end up with a person's individual radar chart.
In order to get to the point where our team members have their own individual skills mapped onto a chart, though, we first ask them to do a self-assessment. Self-assessment is a critical element in this process since it requires the person to thoroughly review their own performance and work achievements and to rank themselves honestly using a largely objective scale (the word pictures and examples).
To facilitate this and ensure it's done honestly, in the technology team the baseline examples for each role are both not usually freely shared with the team and largely belong to the leadership group. They are also only guide. This is deliberate: we don't want our team members to see these because it may anchor their thinking and make it harder for them to honestly assess themselves, and we also don't want our leaders fixating on them either, because assessing skill isn't just that black-and-white.
Having said that, it can be useful to share with the team what skill areas are considered particularly more relevant to certain roles, for example, a solution architect will have skills weighted more heavily in the fundamentals theme since they are more reliant on these skills in their everyday job, whereas a technical lead (which in our business is more closely aligned to leading a team to deliver day-to-day outcomes) may skew more heavily in the direction of leadership, facilitation and presentation, and other softer skills.
Comparing the person's individual radar chart with both their current and desired future role baselines allows measurement of the person's current expected level of competency in their current role, and the future expected level of competency based on their desired target career path. Using the word pictures and examples helps us (and our team members) determine the correct rankings, and also helps explain what it means to shift the needle in a particular skill area, to achieve a higher level of competence.
For example, looking at Facilitation & Presentation shown in the earlier images, in order to move someone from "Beginning" to "Developing", we would look at the word pictures and examples of the latter:
You regularly share your knowledge with the team and can develop presentations which gradually introduce knowledge and share complex topics in a structured way. You can facilitate sessions like a planning or refinement workshop and you can discuss higher-level or broader solution design in a workshop setting, but you might need to take items offline before being able to address them. You aren't so confident presenting to your peers or superiors and you find it hard to cover topics "on the fly" when you haven't rehearsed. Examples:
- Develop and share complex KB presentations that present complex knowledge in a simple way
- Facilitate a refinement or sprint planning session
- Present to your peers (persuasively)
- Run a solution gathering workshop with assistance
We would then look to try to set the person some objectives during the year, either through on-the-job learning, training, professional development activities, mentoring, and so on, and then to give them an opportunity to have some concrete experience doing this type of work in some form. This could be simple or complex, depending on the person's situation, but ultimately all experience is good experience.
Picking two or three things each year, normally targeted towards areas that both leaders and team members feel would be most beneficial to them, keeps it realistic and achievable and allows for meaningful focus to be applied in specific skill areas.
The key ingredient is flexibility
A career in technology in 2022 isn't anything like what it used to be. It's also nothing like what you'll find in most other industries, where career paths can be relatively self-explanatory and job titles relatively consistent no matter who you work for. And while softer skills might evolve slowly over time or remain fairly constant, technical skills change rapidly and this must be kept up-to-date in the detailed word pictures and examples associated to each skill area/competency level in the matrix. Therefore, all of this is just a starting point. It's a living document, designed to change over time as the system it documents also changes.
As I said earlier, we use this process at Merkle to help facilitate conversations between team leaders and their people, to help set goals and realistic and meaningful objectives for self-improvement, to help define the roles people play within our business, and to help communicate and plot career paths and opportunities for our team, both internally and externally.
They point here is that we're striving to put our people first, and this is the proof.
There's no excuse for generic performance reviews and developers who have no idea what they need to do in order to progress. Likewise, as we've shown here, rewarding loyalty is also achievable: talented people should not have to leave and get a job elsewhere to be able to do the things they want to do, whether that's move down a leadership or architecture career path, or stay on the tools and just do amazing work day in, day out.
I'm proud of our team, and I'm proud that our business has been able to put this process in place and make it succeed.
I'm sharing it because while it's still new, I genuinely believe it's going to give our people an edge when it comes to growth and personal development in technology (and other crafts, for that matter). The things we do here are going to set them up for success not only within our business, but also beyond, because they're going to have well-rounded, relevant skillsets and a concrete examples of work done to back it up.
That's going to set them apart from their peers; it's going to make them valuable, yes, but most people in this industry work for their manager, not for their business, and I genuinely believe that my loyalty to them will be repaid in kind.
Besides, I've always been passionate about helping people grow in their careers, not just while they work for me, and this is just a natural extension of that.
And finally...
Before I finish up, I'd like to again throw a special shout out to Dave Calleja and Miles Cox, our esteemed Heads of Design at Merkle. They were the ones who put in the hard work to develop this framework.
It's a testament to their work that something I'd been struggling with for years was suddenly solved in a single Eureka! moment when they shared it with me, so I piggy-backed off it to develop a technology-focused version.
So while I'm here telling the story, they deserve all the credit.
Christian Brenner is a technology leader with 21 years industry experience and is currently Head of Technology at Merkle Australia. The Career Progression Framework described here was originally created by Dave Calleja and Miles Cox for the design team; the technology version was launched in 2021 and is used to help drive personal growth and development planning. If you'd like to learn more, please do not hesitate to reach out.
