Career Growth Frameworks in Software Engineering: A Review
Performance reviews and career growth opportunities are inextricably linked to the culture of a company. Understanding they have changed and evolved over time will help guide our choices when implementing or modifying a growth framework
Why are we talking about this?
Performance reviews weren’t ever something I paid much attention to when I was on the receiving end. To be honest, they were a pain.
I spent the formative years of my career in the belly of a vast, international, professional services firm. HR was a massive, well-oiled machine. Everything was formalised, templated, standardised, polished and streamlined.
Professional services firms don’t typically develop much software, so they were not set up to support or differentiate our software engineering roles in any way. We filled out standardised SMART performance reviews once a year. It wasn’t fun. It felt like it wasted enormous amounts of my time and most of the questions were not relevant. Or at least we received no guidance on how to make them relevant. A line from “Evolutionary Architecture” by Neal Ford, Rebecca Parsons and Patrick Kua comes to mind, “The more reusable something is, the less usable it is.” As with software, so too with performance reviews.
We just did our best with the paperwork. Then our boss would go to his boss and tell them his team was doing great, and we’d get pay rises. Or not. It was all very opaque. So far as I was aware, performance reviews were just part of the vast corporate engine that sucked in opinions and spat out either happiness or disappointment, based on the whims of the machinery.
From there I travelled, via a circuitous route, to a young start-up, where I was astonished to be handed a link to a small spreadsheet with a few boxes and told, “This is our performance review framework.”
This was not what I was used to! My previous experience had let me to expect there should be more pomp and circumstance. As a newly minted, self-motivated, enterprising, engineering manager, I felt it was well within my purview to Make It Better. I set out to do some research and put together a modest proposal for the next stage of evolution for our Career Growth Framework.
This essay initially began life as a memo to management. It was never delivered. My research led me to talk myself out of delivering it. What we had was fine.
I had been conditioned to expect performance and growth to be part of a rumbling apparatus that made a lot of noise but accomplished very little. In retrospect, I believe our humble spreadsheet (which we are still currently using!), is doing a much better job at fairness, transparency and setting career expectations than any of the well-oiled pipes and tubes at my previous employer ever did.
For so much our post-industrial history, career growth was synonymous with the term “career ladder.” In this article I would like to explore where that idea came from, why it is no longer relevant today, and then offer some practical advice for anyone currently needing to build or tweak a career framework.
Background and Context
There is an apocryphal story of a company that hired a consultant to help identify and improve their culture. The consultant asked, “what do you have to do to get promoted around here?” Upon hearing and recording all the responses, the consultant handed that back to the company and said, “There’s your culture.”
A career framework is inextricable from your company’s culture and should be put in place very carefully. It can take a substantial amount of time to ‘get it right’ and it adds a large amount of planning and process. It’s tempting to simply copy what other people have done, or what you have seen done at previous employers. However, we must be aware that there is a vast amount of social and historical context bound up in the Way Things Are.
Career Ladders — Historical Context
Prior to the industrial revolution, middle-management wasn’t really a thing. Usually no one other than the owner of an enterprise had much to do with running it. There were not many large organisations outside of the Church and Military. Those that did exist were sadly mostly based on slave labor.
Post industrial revolution, the concepts of division of labor and management came into their own as ways of optimising mass-production and exploitation of resources. Workers were seen as cogs in the industrial wheel and control structures were put in place to optimise production.
A well known example is Taylorism, also known as ‘scientific management’, named after Frederick Winslow Taylor (1856–1915). Taylor sought to break down the manufacturing process into repeatable, well-understood tasks that could be measured and optimised¹. In his vision, engineers would identify and break down the processes which the workers would then perform.
While Taylor had hoped his methodologies would reduce friction between workers and management, his methods focused on the separation of planning from execution and direct from indirect work. This had the effect of turning workers into mindless, replaceable cogs in the machine.
Following Taylorism was Fordism, pioneered by Henry Ford in his manufacturing plants. In contrast to Taylorism, which sought to optimise workers, tasks, and machines, Ford’s contribution was to introduce the assembly line to bring the work to the workers. It also included a focus on minimising costs rather than optimising profits.
Worker turnover was high. Supposedly, he had to hire 52,000 people in 1913 to fill a workforce of 14,000, but Ford sought to offset that by increasing pay. While heavily criticised, the efficiency gains that Taylorism and Fordism brought to American manufacturing arguably contributed to America winning the second world war and allowed them to dominate the industrial world for some time after.
In post-WWII America, rigid corporate structures were dominant. Technological and social progress was slow (as compared to today), leading to a general expectation of stability and an unwritten promise that employees would be loyal and employers would provide lifelong employment. Although, if you were a worker in a Ford plant, that meant subjecting your household to regular inspections to make sure you were behaving in the American way².
The corporate structures that were emerging at this time grew out of the success of ‘scientific management’ and were by and large a transcription of this process. The management layer were Taylor’s engineers, defining and breaking down the process, which was then doled out to the unskilled workers for execution. In this context, a successful career in the corporate world would be marked by a rise from unskilled worker into skilled management.
Following on from this, in the late 1970s, economic boom-bust cycles started to shatter the illusion of stable, permanent employment, just before globalisation destroyed it entirely. The workforce was now multi-generational, shifting and unstable. With manufacturing being moved off-shore, there was also an employment shift towards knowledge workers. Innovation and creativity gained greater emphasis.
Software engineering as a profession was coming into its own around this time and was shoehorned into the traditional corporate model even as that model was losing relevance. Not only was the traditional corporate model losing relevance, but the role of the programmer within it drastically changed over a short period of time.
Computer was, after all, originally a job title. It referred to a person who computed and tabulated information such as navigational data or interest rate tables. This usage of computer dates back to the 17th century and was not regarded as a creative profession. As mechanical and electronic computers started to take over the actual work of computation ,the role of the programmer emerged, but still in the shadow of a world-view that treated computing as part of the production line.
As an example, see the seminal text “The Mythical Man Month,” written by Frederick Brooks in 1975, which provides a fascinating glimpse into the dawn of software development as a profession. Much of the book is still relevant, but some was outdated within years of publication, such as his description of the surgical team, in which one “rock star” programmer (the surgeon) writes all the code while a team around him take on the mundane work of desk-checking the code and punching it in.
The rapid evolution of computing and of programmers into product developers or software engineers, against the backdrop of a corporate world rooted in Taylorism, is clearly going to be a fertile ground for misalignment and misunderstandings.
Problems with the traditional career ladder
Perhaps the most well-known criticism of career ladders is the ‘Peter Principle,’ which dates back to the late 1960’s. If an employee does well they are promoted. Promotions cease when they are promoted to a level at which they do not do well. As a result, over time, every position tends to be occupied by an employee who is incompetent to carry it out.
In contrast to the Peter principle, which assumed promotions were granted out of a genuine desire to recognise and reward performance, we have the Dilbert Principle. Coined in the mid 90’s, it supposes that promoting the incompetent into management is the most effective way to get them out of the way of the people who do the ‘real work’. I.e — the developers and software engineers.
In software engineering, and other knowledge-based disciplines, it is a common complaint that there needs to be a way to reward and compensate skilled employees that does not require a move into management. The most typical reaction to this complaint has been to introduce a dual track career ladder. The idea is to provide an alternative set of titles which pay as much as (or more than!) management while allowing an employee to remain an individual contributor.
This is fine in theory. However outside of a few outliers like Google (where ‘Google Fellow’ is a technical role equivalent to a VP) it is often implemented inside the framework of a traditional, hierarchical corporation with all the Taylorist baggage that comes with it. The result is that technical roles are still seen as workers, and hence inferior to management roles, or that the hierarchy and bureaucracy that exist in spite of the dual-track path are not conducive to an environment where engineers feel valued.
So what can we do to make engineers feel valued?
Intrinsic vs. Extrinsic rewards
Intuitively we understand that we want a satisfying career and enough money to support our desired lifestyle and, if applicable, dependents. As an employer, we may also wonder if part of the deal is to motivate employees to work harder and do better, if there is a reward to be gained.
This was certainly a key facet of Taylorism: The idea of the ‘carrot and the stick.’ The theory that workers can be motivated by a combination of rewards and punishments. Whether this can work for repetitive factory work is debatable. But even if it does, software developers are not factory workers. Once the basic requirements of adequacy and fairness have been met, external rewards cease to be a strong motivating factor. In fact, in some cases they can even diminish motivation.
Daniel Pink speaks of this in his book, “Drive,” which is often named by technical leaders as one of their most influential reads. It can be intrinsically rewarding to perform a task you enjoy, like crafting well-architected micro-services or finding a particularly elegant solution to a design problem. But once the external reward becomes the reason to perform the task, it can start to take over and kill the intrinsic enjoyment.
Another problem with purely external motivation is that it can cap performance if implemented poorly. For example, if you will receive a bonus for achieving a 10% improvement in some business metric, why would you aim for 15%? If you’ll get a bonus for being ‘on time’, according to some arbitrarily set date, why would you try and get it done any faster? There can also be temptation to game the system to achieve the rewards, encouraging short-term thinking, loss of creativity and, in the extreme, cheating and unethical behaviour.
The purported solution is to ensure intrinsic motivational factors are acknowledged and included. A growth framework cannot be solely about deciding how much someone is paid and what their title is. It must also expose and elevate internal motivational factors.
The three prime factors, as described by Pink, are Mastery, Autonomy and Purpose, which are relatively self-describing.
A career ladder — or other framework — can help us assign compensation, which takes care of extrinsic motivation. But can they help us with intrinsic motivation?
Traditional career ladders, and the top-down hierarchy they imply, are seen as anathema by many who share the progressive ideals of Kaizen [continuous improvement], collaboration, autonomy, and organisational agility. See, for example, this post by Graham Lea, who argues among other points that assigning skill levels is a regression problem, not classification, so titles and levels don’t make sense. Netflix has a similar structure (or lack thereof).
Others argue that ladders or grades are necessary to provide a framework for encouraging growth, motivating staff and providing an objective framework for assessing performance. The criticisms levelled at hierarchies are somewhat mitigated by proposing alternative terms like ‘career paths’ and ‘career lattices’.
The problem is compounded when we expand the scope of the debate to specialism vs generalism. There is a growing resistance from some quarters to the idea of having a ‘architect’ or ‘tech lead’ dictating technical choices from the top-down. This contradicts autonomy, which reduces intrinsic motivation. Rather, with autonomous teams and micro-services, we can try to create an environment where good architecture and decision making is everyone’s responsibility.
But if something is everyone’s responsibility, then it often becomes no-one’s responsibility. Pat Kua argued that even an autonomous, self-sufficient team needs a tech lead. The anti-title camp provided a counter-argument, which was then rebutted by Pat Kua. After the dust had settled others weighed in with their thoughts on the debate — making it clear that the issue is complicated and divisive.
The idea of having any sort of ladder or lattice at all also raises another question. How are we going to place engineers onto our ladder? On which rung do they stand? Perhaps we need to measure their performance?
Measuring developer performance
Tell me how you measure me, and I will tell you how I will behave.
— Eliyahu M. Goldratt
You can’t. It doesn’t work. We know that, now.
The assumption that developer performance can be measured comes from a flawed analogy with the manufacturing world. But personally, I can relate more closely to a construction metaphor. The speed at which a brick wall can be constructed is directly correlated with the speed at which you can lay bricks. So the speed at which a program can be built correlates with the speed at which you can add lines of code, right?
History has taught us that we categorically have to say no, this is wrong. Like most incorrect but popular theories, there is a naive oversimplification followed by an extrapolation which provides a compelling grain of irresistible logic but ignores other pertinent facts. Nobody ever just builds a wall for the sheer pleasure of it. The construction serves a purpose. The wall would be part of a bigger construction project with a noble goal like housing the downtrodden or reducing congestion on our roads.
Construction projects rarely run on time. Often the larger the project the bigger the overruns and the longer everything takes. But why? Surely it’s a simple calculation based on the productivity of your brick layers?
Oh… did we forget the planning committee and the government paperwork and the architects and the site surveyors and the community consultation and the blind spiders and the ground works and the brick layers and the tilers and the waterproofing and wet weather and … well, I can probably stop now.
In our construction analogy, what role do software engineers play? The brick-layers or the architects? The ground-works team or the surveyors? The water-proofers or the community consultation committee?
The answer is most of them. Especially with the recent push towards cross-functional teams and T-shaped employees. A software engineer’s goal is not to write code, it’s to build product.
This is the fundamental reason why all attempts to objectively measure individual developer productivity ultimately fail. Intuitively we understand that the role of a UX designer is not to draw wireframes and mock-ups, but to design experiences. Wireframes are a means to an end, but we would never think to count ‘number of wireframes’ as a performance metric for a designer. Yet — with software engineering , the myth persists — as evidenced by the number of metrics that have been explored over the years, such as:
- Working hours
- Source lines of code
- Defect rate
- Function points
- Story points
- Code “impact”
Many of the metrics above actually can be useful if applied at the team or project level. At a minimum they help build a picture of business as usual, so you can understand if changes you are making are having an impact. Such data driven decision making is in vogue at the moment, but is outside the scope of this essay. However, as a tool for assigning a software engineer a rank within a career framework, we must conclude that defining and measuring metrics is not what we are looking for.
What is everyone else doing?
Netflix retains a flat structure for engineers. Its culture deck is famous. The company followed it to the notable extent of ‘firing’ the woman who co-created it, Patty McCord, once her work was complete. Interestingly, for other start-ups, Patty suggests new companies need not worry too much about setting pay-scales.
Spotify delayed implementing a technical career framework for eight years. The delay was was primarily because they felt the overhead of a formal framework was counter-productive during the early stages of a company’s life, where roles and responsibilities were expected to be fluid. By their own admission, they may have waited a little too long. During that time, the flat hierarchy became a part of the company culture, although not intentionally and not universally. The details of their journey are now public.
Medium follows a similar model to Spotify. With the benefit of hindsight, their model feels more refined and better executed than Spotify. (Although for a company so tightly entwined with the written word, I would expect a great write-up.)
Google and Microsoft have a dual track career ladder. Google attempted at one point to adopt a flat structure but it failed spectacularly. Rather than autonomous teams making their own decisions, everything funnelled up to the one remaining leader, Larry Page.
Other companies that vocally promote engineering best-practice like ‘Fog Creek’, have a more traditional career progression. However, they base their progression criteria on a matrix of skills with an emphasis on increasing scope of responsibility.
The founder of Fog Creek is Joel Spolsky, also behind Stack Overflow and Trello. He is vocally critical of traditional ‘command and control’ management styles in the workplace, claiming they stifle the creativity and engagement of employees. Similar arguments were levelled against Taylorism and Fordism and their effects on alienating and deskilling factory workers.
Valve and GitHub are experimenting with very flat structures and holacracies. Holacracy was made famous by Zappos and is known for being a management free organisational structure. The argument behind holacracy is that it removes the dilution of purpose that often occurs between the leaders of a company, who have the vision but cannot execute without reliance on workers, and the workers, who can execute and may have ideas, but may not be able to feed them up the hierarchy. Since Purpose is one of the key three intrinsic motivators, the idea is compelling.
Holacracy is a fascinating experiment and deserves more than a paragraph. But to summarise, lessons from early adopters suggest it can work but requires more commitment and counter-intuitively more process than traditional structures. In a traditional company structure the leaders make the rules. In a Holacracy the system is the rules. Think of Monarchy vs. Democracy.
In a monarchy you do what the monarch tells you to do. In a democracy, to change the rules you have to change the system. This needs to be managed competently and fairly. Before adopting their current framework, Medium experimented with Holacracy but abandoned it primarily because the added overhead did not scale and hampered their decision-making.
Buffer has tried a bit of everything before settling on a traditional dual-track ladder with a matrix of skills. Notably different about Buffer is their distributed team and their commitment to open salaries. Taking open salaries to the extreme is “iwantmyname”, who have maintained a single salary for the entire company.
A more standard approach to open salaries is to use a skill matrix to produce a weighted score that assigns employees into a band. The band will have a salary associated it. Depending on a company’s comfort with open salaries and level of transparency an employee’s band may be public but the salaries hidden, the salaries public but the bands hidden, or both salaries and bands public.
- The “Career Ladder” is dead. Long live the ‘career path’ or ‘lattice’. The idea that a career path should not lead straight up the ladder into management is widespread and non-controversial.
- Skill matrices are common. Although the implementation detail can vary widely, almost all progressive engineering companies assess performance along some sort of matrix. Almost always this includes soft skills and business acumen along with purely technical skills.
- Growth frameworks are inseparable from culture. Titles (or lack thereof), promotion criteria, and company structure are a visible expression of a company’s culture and values.
- Growth frameworks are separate from titles. It is possible to separate the concern of external-facing titles from skill and growth. The most important question to answer is “How do I grow?”
- Autonomy, mastery and purpose are crucial. The three work in concert to produce a workplace where people feel valued, want to contribute and are able to contribute.
- Your level should reflect your abilities, not define them. However it is measured, it is important that employees understand there are no artificial limits placed on their growth. Their position and salaries will fairly reflect their growth and the work they do, not vice-versa. No-one should feel they are ignored or undervalued because they have a more junior title. Conversely, no-one should feel they can ignore issues in the organisation because it’s someone else’s problem.
- Deep hierarchy or flat-hierarchy? This is a sliding scale. Proponents of flat(-ish) hierarchies claim they improve autonomy and engagement and reduce needless bureaucracy and process. Few people are arguing in favour of maintaining deep hierarchy but it is the dominant, incumbent company structure. Removing all hierarchy can be counterproductive if employees/teams are not already equipped to make decisions autonomously, as in Google’s case.
- Roles or titles? While there are multiple competing organisational structures such as holacracy and flat hierarchies, none of them remove the need for work to be done. Holacracy has a reputation as being a ‘no management’ movement. That is not true. Management is still required but is embedded in roles, not titles, that can be fulfilled by any employee who feels qualified and can perform the duties. The true trade-off is whether you assign a title to a person who will perform a certain type of work, or the work is associated with a role that can be worn like a hat by different employees at different times.
- Centralised or decentralised decision making? Traditional corporate structures, and also job titles like architect, are associated with top-down decision making that is often distanced from the reality of the situation. Alternative approaches allow for the delegation or distribution of decision making. Holacracy represents the extreme of distributed decision making. Delegation boards claim provide a middle-ground approach to self-organisation.
- Titles or no-titles? This debate is inter-related with hierarchy, structure and roles. In a traditional structure the debate focuses around whether having titles or ‘bands’, (e.g. Engineer I, Engineer II) discourages autonomy and self-organisation while also creating an hierarchy. Alternatively, there may be no titles at all and job responsibility is associated with a role, as in holacracies. Proponents of having no-titles or flat-titles claim they do not accurately reflect skills developing along a gradient and can be artificially limiting. Proponents of having titles talk about the need for structure, difficulties comparing salaries and role expectations externally, and help off-set the prejudice that may be faced by experienced employees in a non-diverse workforce who do not look like a senior developer.
- Sooner or Later? Spotify and Patty McCord (from Netflix) advocate delaying the implementation of a formal framework for career growth and pay-grades. The argument is that creating, maintaining and applying a framework is time-consuming and adds overhead. While the company is smaller and roles more fluid, it can be good enough to work off intuition and common-understanding. By their own admission, Spotify probably waited too long (eight years), which made the journey harder and hampered adoption.
- Open salaries or closed salaries? Closed salaries are the industry default, with proponents fearing that pay transparency may incite jealousy between colleagues, be taken out of context, make it harder to hire on a restricted budget or make it easier for other employers to poach employees. Another reason cited is that it’s hard for an employer to explain salary differences between individuals in the same role. This would suggest there was not an objective way of assessing performance. However with average salaries easily accessible through sites like glassdoor.com as well as market data, these reasons increasingly start to sound like excuses. On the other side of the coin, pay transparency can help close the pay gap for women and minorities and may improve happiness and morale.
- Conventional or unconventional? A meta-trade-off! Titles are conventional. Hierarchies are conventional. Closed salaries are conventional. Many ideas in business organisation and career growth are currently under contention. Trying something new or following a more progressive path can be a gamble and make it harder to hire from a pool of candidates conditioned to expect a conventional approach. On the other hand, progress only happens where people are willing to take a gamble on the unconventional. Moreover, it can create a point of differentiation so that while your pool may be smaller, the employees you end up with are committed to the cause and have chosen your company deliberately for its culture and ways of working.
Practical advice for creating career frameworks
Career growth frameworks exists at a nexus of multiple trade-offs and concerns along different dimensions. I’m certain someone more imaginative than myself could arrange them all neatly into categories and assign them to Harry Potter characters or a Dungeons and Dragons Alignment Chart. Clearly the next innovation in career growth would be to make the choice easy by working out if your company is Chaotic Evil, Lawful Neutral or True Good.
Until that day the challenge for anyone wishing to implement or improve a growth framework is two-fold. Firstly, to decide what sort of company you wish to be and make the trade-offs accordingly. Secondly, to help employees achieve purpose, mastery and autonomy by answering the question, “How do I grow?”
Where do we start? My recommendations, distilled from the research in this essay and conversations with other technical leaders are:
- Work out what your values are. Culture is what you do, not what you say. Your organization’s values should be embodied in and promoted by the way you assess and reward your staff. If you are going to borrow or modify a framework published by someone else you need to know what’s important for you so you can tweak accordingly. If you’re going to create something from scratch, you need to know where to start building. Either way it’s important.
- Make some decisions up-front. Opening salaries after they were initially closed salaries is probably the hardest trade-off to retrofit and should probably be decided up-front. After that, it’s probably titles or no-titles. Other aspects of organisational structure are more likely to be emergent properties of your growth. Know where you’d like to steer things, but they’re probably not as important to try and pin down up-front.
- Ensure managers have regular one-on-one meetings with their reports. It is deeply unfair to miss out on a pay rise or promotion because feedback was only provided once a year, when it was already too late. Regular catch-ups help address this. There is an enormous amount of information available about effective one-on-one meetings, which does not need repeating here. But the purpose of the catch-up is to prove a regular, semi-formal forum to receive feedback. It’s also a place to discuss goals and motivation. Nothing in a performance review should ever be a surprise. Using ‘autonomy’, ‘purpose’ and ‘mastery’ as themes for these discussions can also work really well.
- Have a fair an objective way of assessing (not measuring!) performance. Build or borrow a competency matrix. It should describe tasks and behaviours at each level. It probably should not include metrics and measurements. Apply it fairly to all levels within the same role.
- Have a defined approach for reassessing renumeration. It probably doesn’t matter so much what the actual process is, so long as it’s known and accepted. Ideally performance is assessed continuously rather than annually. You couldn’t expect to raise a child if you only gave them feedback once a year about their behaviour and progress — so why should we expect it to work for our employees?
That’s about it. You don’t need a whole lot of process — and for a young startup, less is more! But if you can assure regular feedback and attempt fairness as best as you can, it goes a very long way to providing mastery, autonomy and purpose.
 Sounds like Agile! Taylorism by any other name would still smell like motor-oil.
 Come to think of it — is that any different to people getting fired for what they post on public media these days?