On April 21, Anthropic quietly pulled Claude Code from its $20 Pro plan. No prior announcement. They’ve just placed a red X on the pricing page and a rewritten support document — long story short, Claude Code temporarily ceased to be available on the Pro plan and became only available on the Max subscription.

When people noticed, Anthropic’s head of growth said it was a small test affecting about 2% of new signups. Maybe. I’m not interested in conspiracy theories. Whether it stays or is reverted is irrelevant. This still looks to me like them testing the waters for a policy change already underway.

And it’s not just Anthropic. One day earlier, on April 20, GitHub announced it was pausing new signups for Copilot Pro, Pro+, and Student plans, tightening usage limits, and removing Opus models from the Pro tier. Their stated rationale: “agentic workflows have fundamentally changed Copilot’s compute demands... it’s now common for a handful of requests to incur costs that exceed the plan price.”

The fact is, your $20 a month was never really $20. Ditto for the $200 Max version. For two years, AI labs have been selling flat-rate subscriptions at prices far below the actual compute they consume. As Ed Zitron wrote: “Anthropic’s subscription plans charge far less than the book value of tokens consumed, sometimes by a factor of ten or more.”

That means: you paid $20, but you really burned through compute that cost them $50, $100, sometimes more. The difference was financed by venture capital. The bet is: grab the market now, figure out margins later.

You could argue it’s a typical Silicon Valley playbook. We’ve seen it before with Amazon, we’ve seen it with Uber, and plenty of other companies. All with Peter Thiel's acolytes chanting in the background: Competition is for losers, monopoly is the goal.

And we have historical proof that it works.

Or does it?

The curve ahead

Even as labs subsidize subscriptions, the underlying cost of generating a token has been falling at an impressive rate.

GPT-4 launched in March 2023 at $30 per million input tokens and $60 per million output tokens. Today, GPT-5.4 delivers vastly better performance at $2.50 and $15, respectively. That's roughly a 12x reduction in input costs and 4x in output costs in three years at the flagship tier — and far more if you compare on fixed capability.

Claude Opus 4.6, priced at $5/$25, costs a third of what Claude 3 Opus did two years ago ($15/$75).

Gemini 2.0 Flash hit $0.10/$0.40 in late 2024 — prices that would have sounded absurd even eighteen months earlier. The curve bends everywhere you look (for comparison: GPT 3.5 — $0.50/$1.50 — being inferior to Gemini 2 Flash overall, even in pure text use cases).

The reductions aren’t just coming from better hardware, though. Andrej Karpathy recently retrained a GPT-2 grade model for $73 — the same model that cost OpenAI around $43,000 to train in 2019. That’s a 600x reduction in seven years, falling roughly 2.5x every single year. Part of it is hardware (H100s beat TPU v3s). Part of it is software (FlashAttention, fp8 training, better optimizers). But a huge part is just algorithmic progress — we’ve figured out how to do the same thing with far less compute.

“Past performance does not guarantee future results.” Got it.

This is nonetheless reminiscent of other historical price curves. Take the lithium-ion battery cost chart. The inflation-adjusted drop in the costs of lithium-ion batteries over the last 3 decades is mindblowing — ~99% over that period of time. A drop - mind you! - that enabled reinvention and mass production of electric vehicles and the growth of what is estimated to be a $1.6 trillion industry. (And I’ll completely ignore the far bigger impact it had on the consumer electronics industry at large.)

If this is not a textbook example of Jevons Paradox, I don’t know what is.

The unit economics

The Silicon Valley playbook mentioned earlier is not a clean parallel, though. Amazon was unprofitable for nine years and didn’t generate meaningful profits for closer to twenty. But Amazon sold books at roughly cost plus margin. Its losses came from warehouses, logistics, infrastructure — fixed costs that paid off once they were built. When Amazon got more popular, its unit economics improved.

What are the unit economics here?

Every token you generate costs the lab money, today, in electricity and GPU time. When more people use Claude, Anthropic bleeds faster. The subsidy isn’t a one-time investment that pays dividends later. It’s a tap. Actually, more of a firehose. Turning it off is the only way to stop the bleeding.

And the labs are starting to turn it off. Here are some examples:

• In February, Anthropic introduced Fast Mode — 2.5x faster inference at 6x the standard rate. Same model, same capabilities, you’re paying a premium to skip the queue.

• In March, they started throttling peak-hour usage across subscription tiers.

• OpenAI runs its own version with “flex processing” — cheaper if you’re willing to wait.

These are pricing tweaks, not new features. Compute is scarce, and subsidies end. The price you pay will depend on when you use it, how fast you need it, and how much leverage the lab still has.

Here’s the twist. Even as the price of a token keeps collapsing, the bill is going up. How so? Well, ask yourself - with all these token prices falling so rapidly — are you paying less for AI subscriptions today than 2 years ago?

Enterprise LLM spend doubled in six months last year while per-token costs plummeted (did I mention Jevons Paradox already?). Agentic workflows burn 5 to 30 times more tokens per task than a simple chatbot (tool calls, multi-step reasoning, orchestrations, and so on). That’s why unit cost falls while at the same time the total cost explodes.

What comes next

Eventually, the underlying cost of a token will drop to a level where no subsidy is necessary. Depending on the source, the token costs fall at a rate between 2.5x (Karpathy example) and 10x (Epoch AI) per year.

Nvidia’s near-monopoly will also erode as AMD, Google’s TPUs, and Amazon’s Trainium chips take share at the infrastructure layer. The margins that Nvidia has today are just too outrageous to ignore. Competition at every layer will push prices toward the real cost of electricity and silicon, not the VC-subsidized numbers we’re seeing today.

This is, not coincidentally, what Sam Altman told the US Senate in May 2025:
”Eventually the cost of intelligence, the cost of AI will converge to the cost of energy and it’ll be how much you can have. The abundance of it will be limited by the abundance of energy.”

But between now and then, there’s a bill to be paid. The labs spent hundreds of billions acquiring users at a loss. They have to make that back. And the people paying it — whether through removed features, peak surcharges, or tiered pricing — are you.

So what does this mean if you’re building on any of this?

The price you see today is not the real economic price. It is whatever the lab currently wants you to believe the product costs. It will change, probably not in your favor, probably sooner than you think. Per-token pricing, peak surcharges, and tiered inference are the future. Anyone betting on labs absorbing the difference between subscription prices and real compute costs might be heading toward a nasty wake-up call in the short-term future.

I am ultimately an optimist. And few things show such predictable and consistent price drops as technology entering the mass market. But first, it’s going to get worse before it gets better.

Brace yourself.

I’ve overheard it in a meeting. Two people disagreed on a strategic direction, you could feel the temperature creeping up, and one of them eventually responded to the disagreement with: “It’s just semantics.” As in — “this is not worth arguing about, let’s move on.”

I’ve been thinking about that phrase ever since. Not the first time, though. I’ve realized I’ve heard it repeatedly over the years. “It’s just semantics.”

I cannot help but think: what is there in a conversation besides semantics?

A lot, actually — tone, body language, emotion, context. But in organizations, especially when we discuss strategic matters, it is critical that we are all on the same page — everyone involved understands exactly and in the same way what we are discussing and what we are about to do.

Locally — in any given room — there are a lot of factors that matter. Outside of the room, as the mission and vision spread through the organization, the thing that survives the journey is the words. The meaning they carry. Semantics is the part that scales.

In that sense, semantics isn’t a distraction from strategy, nor a tangent to it. It IS the strategy. Every strategic decision is ultimately a question of “what do we mean when we say X?” What does “customer-first” mean when you have to choose between two customers? What does “quality” mean when the deadline is tomorrow? What does “aggressive” mean when half the room thinks it means pricing and the other half thinks it means litigation?

When someone says “we need to move fast,” what do they mean? Ship in two weeks? Hire three people by Friday? Skip the compliance review? Everyone in the room nods. Nobody is agreeing on the same thing. “Move fast.” “Be aggressive.” “Think long-term.” “Stay lean.” These are words that feel like decisions or directions but aren’t — because nobody defined them. The meeting ends with alignment that doesn’t exist.

So here’s how I think about this today. When we wave away the definitional question with “it’s just semantics,” it’s not really avoiding a pointless argument. Two people walk out of the room thinking they agreed. They didn’t. They agreed on a word. They never agreed on what it means.

We’re locking in a misunderstanding and voluntarily giving it time to compound. And compound it will.

Some understood this. Jeff Bezos banned PowerPoint at Amazon and required six-page narrative memos instead. Slides let people hide behind vague language. A bullet point like “improve customer experience” survives a meeting unchallenged. You can hide a lot behind hand gestures and a confident delivery while giving a presentation, too.

Try writing that as a full paragraph, and you're immediately forced to explain what you actually mean. And if you don't, whoever reads it will force you to. Bezos insisted on plain English because he understood how critical semantics is.

We can disagree on the meaning of the message. It’s OK to disagree. It’s OK to be confused. Nobody knows. But we can figure it out. As long, that is, as we all recognize we haven’t reached agreement — or at least understanding — yet.

Semantics is literally the study of meaning. Dismissing it is dismissing whether you mean what you say. And the meaning of what you say sounds like a damn important thing to me.

The best engineers might be today 40% more productive with AI coding tools. At least that’s what this study says. Given it was published in October 2025 — in today’s timeline, roughly a decade ago — it is already outdated. My assessment would be that it is more than that, at least for the best performers and a certain range of software products. (Now, how much of an individual productivity gain translates to the organization is an entirely different story!)

This creates an interesting dynamic for software service companies — companies that build custom software for their clients.

Right now, companies that adopt AI aggressively feel like they have an edge. And they do — today. But this is a transitory advantage. Whether it takes one, two, or five years, the market will eventually catch up. AI proficiency will become the new baseline, not a differentiator.

An opportunity and a threat

Software service companies are living through this transition in two very different ways.

Some see it as an existential threat — and not without reason. Customers can now create way more software themselves — software that they used to subcontract to vendors. The barrier to entry for building a functional application has collapsed. If your client’s PM with one engineering colleague can spin up a working prototype over a few days, they are starting to question whether they need an external partner at all.

Sure, doing a limited POC and a real, production project, with real load, security constraints, and ongoing maintenance, are two very, very different things. Many of these ad-hoc in-house products will eventually fail to deliver the promised value.

And yet, it would be dishonest not to notice that building relatively typical software has become way more accessible. And let’s be straight — not every custom-built product was a complex, multi-year endeavor. You can check it out, for instance, on Clutch by browsing the typical price ranges for past projects. There are plenty of companies living off $10-100k contracts.

Others see it as a tremendous opportunity. With outstanding productivity gains, they can harvest disproportionate margins — doing more with less, delivering faster, and capturing the spread between the old cost structure and the new one.

Here is the problem, though. Your client knows this. They don’t need to master AI or even use it effectively themselves. The mere existence of AI-augmented development gives them leverage to push for lower prices. A recent CIO analysis found that enterprise customers are already demanding their share of AI productivity gains. The logic is straightforward: if developers complete tasks 40% faster, someone is capturing that surplus. The client wants to know why it isn’t them. And the traditional saying goes: the customer is always right…

A question of price

Where does this put software service companies that typically operated in a time-and-materials manner? On the one hand, customers expect faster delivery (fewer man-days). On the other hand, the agency that truly masters AI-augmented software delivery cannot reap the efficiency benefits (as they charge per day).

The first instinct is to move to fixed pricing. You capture the efficiency, the client gets a predictable cost, everybody wins. Except the prices will fall down too - in the same way that expected man-days for a project would fall down (though arguably the price arbitrage will be there for a limited time, and companies that are ahead-of-the-curve should be able to capture part of it while it lasts).

The forward-looking companies are moving further along the spectrum — from time-and-materials through fixed price to value-based pricing.

What is value-based pricing? At its essence, you charge for what it’s worth to the buyer, not what it costs you to produce. It might be capturing a fraction of the savings that delivering specific software produces for the customer. Or it might be a price set based on new opportunities uncovered for the customer. There is also a closely related term of outcome-based pricing. Technically, outcome-based ≠ value-based — an outcome doesn’t have to translate to value. In practice, the two are close enough to treat as the same thing.

McKinsey already generates 25% of its global fees from outcomes-based arrangements. You may be skeptical about McKinsey. I am not surprised. One thing is certain, though - they know how to make money, whether we like it or not. And when they overhaul how they charge, it is at least prudent to pay attention.

To quote Business Insider: “The result is a renewed industry focus on implementation and value over mere activity.” Part of me shouts: At long fucking last!

Unfortunately, value-based pricing is an entirely different and complicated game. And on top of that, moving to value-based pricing for a general software vendor is going to be even harder. Except for very specific, narrow technical cases (e.g., cloud cost optimization), a lot of value is entangled in the customer’s business. It is going to be very difficult to move towards that pricing for software service companies that operate exclusively at the technology layer.

Whichever way you go, the same pressure applies — building general-purpose software has become more accessible, and software service companies will face pressure.

Where does the moat go?

Forbes predicts that within three to five years, a software development productivity boost will exceed 80%, meaning half the labor currently needed will suffice. Now, I am very much on the side of Jevons Paradox: a software Cambrian explosion will drive the cost down, which will in turn drive the demand up.

However, there is an intermediate problem. Most enterprise customers won’t be ready to absorb a radically higher volume of delivered software. They grew their processes in a reality where building software was the bottleneck. Now, the bottleneck has shifted, and many enterprises are just not ready for consuming software at a faster pace.

Whether the demand explodes or not (and when!), the immediate reality is the same. An industry built on billing for labor will feel every point of upcoming compression. The agencies that thrive won’t be the ones that just write the most code.

The work won’t disappear — but the margins for general software-service companies will. And who wants to end up on a commodity-price treadmill?

So what’s defensible? Three things, as far as I can tell.

First, go where the barriers are structural. Regulated industries — finance, healthcare, defence. Hardware integration. Environments where certification, compliance, and safety aren’t nice-to-haves but legal requirements. AI can write the code, but it can’t navigate a regulatory audit, own a liability, or sign off on a medical device. At least — not yet.

Second, go deep into a niche. Not necessarily a regulated one — but one where accumulated expertise takes years to build. Narrow but deep technology expertise. Real-time trading systems. Logistics optimization. Developer’s efficiency. The agency that has spent a decade understanding how a specific domain actually works will beat the one with better engineers every time. This was always a good bet. AI makes it even more relevant because when the code price tag collapses, the only thing left to charge for is knowing what the code should do better than your customer.

Third — and this is where I think the real shift happens — close the gap between software and business. The “code monkey” role — take a spec, produce code — is the one most directly displaced by AI. Outside of highly specialized areas like critical infrastructure or security, the direction is convergence. Software engineering stops being a separate discipline and becomes part of how business operates. The agency of the future doesn’t just build what you spec. It helps you figure out what to build. At an extreme, that’s not a software agency anymore. It’s a industry specific consulting firm that happens to ship code. Coincidentally, value-based pricing is way more achievable for vendors being closer to the business (or even better — closer to an actual P&L).

Tectonic industry shifts are uncomfortable by definition. But they also reshuffle the deck. The reshuffling threatens some, but it also creates disproportionate openings for others. One thing seems to be certain though - the days of straightforward selling of pure, general technical experience are gone.

The room was asked to place a dot where they actually are in their day-to-day coding. The dots clustered around the 25% mark from the left. Actually, the 25% might be a charitable interpretation. Take a look at it yourself.

This is a room full of software engineers. People who write code for a living. And when asked honestly where they stand on the AI continuum, the majority of answers were: still mostly doing it by hand. Truth be told, my suspicion is that the Rust community might be a little more biased toward organic coding — I’ll give you that.

Even so, that photo has been stuck in my head for days now, because it captures something the industry conversation keeps getting wrong.

In March 2025, Dario Amodei told the Council on Foreign Relations that AI would be writing 90% of code within three-to-six months. Essentially all of it within a year. Obviously, the internet did what the internet does — half the people called him delusional, the other half declared software engineering dead. And naturally, the further detached they are from software engineering, the louder they get.

So here we are, a year later. And the conclusion is… mixed.

On one hand, John Crickett ran his own informal survey and found that maybe 5% of developers are heavy AI users. Around 20% use agents, mostly for tests. Many are still on autocomplete or nothing at all. That maps almost perfectly onto the Rustikon whiteboard.

On the other hand, Linear reports that coding agents now operate in 75% of enterprise workspaces, with 25% of issues handled by agents. Not a rounding error anymore — more of a structural adoption.

Here is a funny thing, though — both of these are true at the same time, and that’s the part most commentary misses.

I can clearly see this firsthand. At VirtusLab, I work with some great, capable engineers who essentially don’t write any code by hand at all anymore. They direct AI, review its output, and focus on architecture and coordination. The same is true across many companies I talk with. At The-5 — a community of entrepreneurs founded by — we have a group exchanging AI practices. For many, the vibe is close to 100% automation. Move anywhere near Silicon Valley startups, and it's even more so.

And yet. None of these people has stopped doing software engineering. (Though it’s worth pointing out — some of the people making the boldest claims about its death never actually started in the first place.)

That’s the distinction most people miss when they quote Dario. “AI will write all the code” is not the same as “AI will do all the software-engineering.” These are completely different claims. The gap between them is enormous.

AI today is genuinely capable of typing the code. Give it a well-scoped task — a function, a test, a migration, or even a relatively well-defined feature — and it will produce working output faster than any human. That part of the prediction is largely correct, even if adoption is uneven.

However, leave it unsupervised, without any guardrails and engineering discipline, and over time, the castle in the sand starts to crumble.

This is already visible. The code that is being generated is already straining the system, and the quality is going down. Rob Zuber at CircleCI published data showing that PR sizes increase by more than 150% when teams adopt AI coding tools. Across 28 million workflows, main branch success rates fell to 70.8% this year — the lowest in five years. The industry has become very good at producing change and strikingly bad at absorbing it.

The bottom line is: software engineering isn’t about code generation. It’s figuring out what to build. It’s understanding constraints that live in people’s heads, not in the codebase. It’s navigating organizational politics, legacy systems, and tradeoffs that don’t show up in any spec. It’s directing the architecture. This might be many years away. Or it might be tomorrow. No one knows. It is clearly not here today.

The best evidence that writing code and engineering software are different things is the current tech job market. The number of software engineering openings in the US has been growing since the bottom of the dip in early 2025.

And last but not least: Anthropic — the company behind arguably the most capable AI coding tool available — is hiring over 100 software engineers. Boris Cherny, the creator of Claude Code, was asked why and that was his answer:

The company closest to making software engineers obsolete is hiring them as fast as it can. Because even when AI writes every line, someone still has to engineer the software.

Say what you want. Dario might have been wrong about AI writing all the code by now. But he was pretty much spot on about AI being able to write all the code. This does not change the fact that engineering is still needed. And it’s not going anywhere.

A friend recently recommended I re-read Neuromancer. I guess it’s fair then to close this with:

“The future is already here – it's just not evenly distributed.”

In 2024, Google ran an Olympics ad called “Dear Sydney”. A father uses Gemini to help his daughter write a fan letter to her favorite athlete.

The internet was… not exactly impressed.

Google pulled the ad. The backlash wasn’t about the quality of the letter — it was that a child’s genuine effort to express admiration had been outsourced to a machine.

The content might have been fine. The act was hollow.

Walk into any organization today, and you’ll find the same dynamic playing out on a smaller, quieter scale. Emails that are clearly AI-generated, sent to people who will clearly barely skim them. The lucky ones, that is. Most will have the title read and be instantly archived (and the rest will just die in the inbox).

And then we have Slack messages with that unmistakable ChatGPT cadence — slightly too polished, slightly too structured, slightly too long (and with way too many emojis).

Performance reviews that read like they were written by a thoughtful manager but feel like they were assembled by a machine. Which they were.

AI-polished documents that — and here is the thing - no one asked to be polished.

There’s an asymmetry here that bothers me. AI has made it trivially cheap to produce content — 30 seconds, and you have a polished update. But it hasn’t made it any cheaper to consume content. Reading a two-page document still takes the reader 15 minutes. Before AI, the effort of writing acted as a natural filter. If something was hard to write, you thought twice about whether it was worth the effort (first your effort, and second recipient’s effort). That filter is gone.

Unless your recipient also uses AI to summarise your messages! In which case, you’d have to be insane not to wonder what’s the point of this whole ceremony.

Who is all of this for?

This is all truly bizarre. Person A spends 30 seconds generating a polished two-page update. Person B spends 30 seconds asking an AI to extract the key points. The actual human-to-human information transfer? Three bullet points. But instead of just sending these three fucking bullet points, we’ve routed the conversation through two AI passes and wasted everyone’s attention in between (not mentioning the tokens, which are the cheapest in all of this grotesque performance).

Josh Bernoff wrote his seminal book “Writing Without Bullshit” before Gen AI was all the rage. His main point was that most business writing wastes the reader’s time — that every sentence should be useful or deleted. AI hasn’t fixed this. It’s made it dramatically worse by reducing the cost of producing bullshit to zero.

Going full circle to where we started, there’s a deeper issue here. Hywel Carver put it well at CTO Craft London this year. Here is the thing: some communication isn’t just about transferring information.

When your manager writes your annual feedback, part of the value is that they sat down and thought about your growth.

When a colleague sends a thank-you note, the effort is the message. If I told you “I generated your performance review with AI” or “I generated my thank-you message with ChatGPT” — would you feel recognised?

There are moments in organizational life where the effort is the point — where the act of sitting down to think about someone is what carries the meaning, not the words that come out.

The irony is that inside an organization, we don’t need polish. Externally, sure — clients, investors, and candidates expect a certain standard. With external audiences, we don't have shared context, so polish fills the gap. I can even understand - though I wish it wasn’t the case - that we generate a certain amount of marketing slop to pump up the volume.

But internally? An organization should value raw clarity over manufactured professionalism. Three bullet points in a Slack message beat a four-paragraph AI-crafted email every time. A rough sketch of an idea beats a polished deck no one reads.

“The present letter is a very long one, simply because I had no leisure to make it shorter.” Blaise Pascal’s famous quote is today, after 400 years, more relevant than ever.

We’ve confused the appearance of thoughtfulness with actual thought.

And AI has made that confusion penny cheap.

Recently, I sat down to record a Beyond the Commit episode with José Valim - creator of the Elixir programming language. We ended up talking for over 2 hours — about types, about AI, about where programming languages are headed.

It got me thinking. I've been picking up Elixir on and off for years — for personal projects, for POCs — then drifting back to whatever serious, enterprise language the day job demands. But I kept returning. And the reason is simpler than I expected.

I realized I genuinely enjoy reading Elixir code.

I've spent years reading code in various languages, and for most of them, "reading" is something I endure, not something I look forward to. It’s a means to an end.

What makes Elixir different is its simplicity. Pipe operators, pattern matching, protocols — each construct is just powerful enough to be flexible and useful, yet simple enough that the code stays readable.

Now, many other languages have achieved simplicity (Golang). But none that I know of has achieved this level of balance of simplicity and harmonious aesthetics (at least for me).

There's a narrow design corridor that Elixir walks remarkably well.

Contrast this with Scala, which I used to know well. Well-written Scala code is a joy to read. Poorly written Scala code is the ninth circle of hell.

Elixir gently constrains you toward clarity, and the result is that most Elixir code reads roughly the same way. Which is exactly what you want when your job is reviewing it.

This philosophy transcends the language itself and extends to its ecosystem. For my personal projects, I've been using Django for a few years now. I typically had to wire up hot reload, Stimulus, Tailwind, recurring jobs, and whatnot myself. It all ended up in a custom-made cookiecutter template eventually. In Phoenix, all of that comes built in as a single coherent package — powerful enough to be flexible, simple enough to pick up and start building immediately. Neat, elegant package.

Here’s the part I find counterintuitive. We’re living through a moment where people are debating whether hand-writing code even matters anymore. AI writes the code, you review and guide it. I think that actually makes the aesthetics of a language matter more, not less. If your main interaction with code is reading it, then how pleasant that experience is becomes a first-class concern. At least while we're still expected to understand the code we ship…

The conventional wisdom right now is that statically typed languages are better suited for AI-assisted development. Types give the model more context, catch errors earlier, and constrain the solution space. It makes intuitive sense, and maybe it is so. It certainly is a convincing argument for enterprise-grade software.

Meanwhile, we also have some interesting experiments like this one, testing the cost of generating (correct) pet projects. Yusuke Endoh tested Claude Code across 13 languages — Ruby came out on top. Fastest, cheapest, most reliable. Adding a type checker to Ruby made it 2-3x slower. Concise, expressive languages — the ones pleasant for humans to read — are also the ones where AI wastes the least tokens.

(There is also this interesting piece from José himself about the tension related to the impossibility of typing some trivial expressions correctly without type unsoundness, but that’s a completely different story)

In the meantime, OpenAI just built Symphony — their agent orchestration framework — in Elixir. A frontier AI lab reached for a language built on a 40-year-old virtual machine designed for telephone switches to orchestrate its agents.

There’s something poetic about that. In a world where AI handles more of the writing, what remains - at least for the time being - is taste, clarity, and the pleasure of working with something well-designed.

And Elixir has that in spades.

Anyone even casually following tech news (or ANY news, really) has heard how AI is making software development more efficient. Claims about 10x or 100x efficiency gains are not unheard of.

In fact, if you listen to AI Lab CEOs, they’re not just preaching improved developer efficiency - they’re talking about making software developers entirely obsolete, imminently. In short: AI will write all the software. According to Dario Amodei, AI might be able to write 90% of the software as soon as 3-6 months from now - which, given the prediction was made in March, puts it somewhere by the end of 2025. Sounds like your stereotypical Silicon Valley CEO’s or investor's wet dream - the former can’t wait to eliminate unreliable wetware from the equation; the latter realized that fortune to be made in selling shovels. So much so, in fact, that when I speak with senior engineering leaders, the challenge of dealing with CEO expecting 2x, 5x or 10x efficiency increase TODAY, becomes a recurring theme.

I remain sceptical about that. It’s one of those situations where everybody agrees on the direction; we only argue about the timing. The timing, though, is important. Go all-in too early, and you may drown in a deluge of AI-generated detritus. Do it too late, and you risk losing your competitive edge. And the truth is - no one really knows.

The realities of a typical software business are quite different from what internet influencers try to paint. Many leaders experience moderate efficiency gains from AI usage in software development. Now, assessing efficiency gains in software development is a tall order already. Various approaches have been tested over decades - starting from counting LOCs to DORA / SPACE metrics today. I am confident that a lot of consulting money was made on measuring development productivity along the way, too. The everyday practicalities of most software teams are that they just don’t measure productivity at all. If anything, they rely on loose, gut feeling as an indicator (“we seem to work on these longer than usual“ or “oh, we seem to introduce more bugs recently”).

Even with the gut-feeling approach, though, it seems that for most organizations, the typical AI-efficiency gains are in single-digit percentage numbers. This is slowly being backed by more and more research. In fact - and this is quite astounding as for the CEO of the company selling AI tooling - Sundar Pichai even cited “AI making Google engineers 10% more productive”. But it goes even further, recently the METR study made headlines online, with results showing an actual decrease in productivity with AI tooling.

Now, I find it very hard to believe that AI tools actually decrease productivity systematically. I do believe it can be the case in some specific, narrow cases, though. It might also be a case of a transition period - using a new tool and/or approach often leads to a temporary efficiency drop before people become fluent with the new ways of working. And besides, even a single-digit (or low two-digit) efficiency increase is worth billions of dollars in the industry. And that’s a conservative estimate!

However, the order-of-magnitude rift between online claims and the realities of software teams is stark.

Here are my thoughts on why I think that’s the case.

First of all, as with any gold rush, you can make shitloads of money by selling shovels. Most companies do that with exorbitant claims about the benefits they will bring. These claims, most of the time, either lack empirical substantiation or hold true only in narrowly defined contexts (e.g. synthetic benchmarks). We’ve seen this story before with public cloud, and especially with the alleged savings it was supposed to bring.

Second, at least as it is in mid-2025, most of these claims focus on the code-writing phase of the SDLC cycle. Typically, these are activities like code generation, debugging, code explanation, or brainstorming. The reality, however, is that for many organizations, writing code (or working with code in general) is only a part of the software engineering work. Depending on the source, it may be between 33% and 50% of the entire engineering time. And perhaps naturally, as the organization and/or seniority of the engineer grows, the pure code-writing phase shrinks. So even if the code writing phase has been improved by 2x, the end result might be that overall net productivity growth might be much less impressive 1.2x.

Third, many online claims come from small companies and startups - unsurprisingly, as they are typically the first ones to venture into uncharted territories. After all, agility is their key strategic advantage over larger incumbents. And at least partially because these companies are more relaxed about security or legal risks (in some cases, more relaxed is a euphemism for not giving a single fuck about these matters). Meanwhile, some of their larger competitors haven’t even managed to get Copilot approved by their legal or security teams (the opposite side of the spectrum).

Finally, and building on the previous point, startup codebases are typically neither large nor burdened by years of obscure changes driven by a tangled web of evolving requirements. Perhaps even more importantly, they are not being used by long-standing customers who depend on layers of osbscure logic up over years (often tailored to specific, idiosyncratic use cases). Customers, mind you, who will be very unpleased when the vibe-coded app starts to break.

Garry Tan said some time ago that for their recent batch AI is writing 95% of the code. It is quite jarring, but I tend to believe Garry.

Which leads us to the key difference I am seeing. Namely, AI tools are borderline absolutely fantastic for some specific cases. Some of these cases are:

• working on the greenfield projects, which are completely or nearly completely separated from the rest of the organization's codebase (at least up to a point when these projects become too complex)

• building throwaway POCs (even if they are not thrown away afterwards, which is the case more often than not)

• using technology (e.g. programming language, libraries, or services) that you are not intimately familiar with.

They are good at other cases, too (e.g. brainstorming or being faster Google), but they excel at the above in the context of software engineering.

Guess what - most of the Y-Combinator batch are pre-product-market-fit companies - all they do from software engineering is write POC / MVP, and the last thing they (should) care about at that stage is long-lasting code quality/readability.

But here’s the thing — most tech leaders don’t work in greenfield settings or build throwaway POCs. As surprising as it may be, a lot of devs don’t work at a hot SV startup or big tech - but rather in some utility provider, midwestern logistics company, or maybe some financial institution. More often than not, they’re knee-deep in brownfield legacy systems.

As it is in mid-2025, AI tools are not overly good with such codebases. One thing is that these codebases often have aged code, with many custom abstraction layers (in other words, out-of-distribution data), separating it from any open source libraries they might use (codebase that is likely in-distribution for the given LLM model). The other thing is that these codebases tend to be sizable. It is not uncommon for these projects to be in the range of hundreds of thousands to millions of LOCs. And while context windows are steadily growing — with models like Gemini 2.5 Pro hitting 1M tokens — that alone doesn’t solve the large codebase problem.

The unfortunate reality is that extending the context window (like in the case of analysing a big codebase) often leads to problems like reduced attention focus or even accidental context-poisoning. You may experience this while working in agentic-mode in Cursor, while trying to provide an increasing amount of information to LLM while debugging a nasty bug, and at some point, realizing that the model suggestions degrade over time.

If GenAI development follows S-curve - which is typical for many new inventions that become widespread - we may expect interesting things.

The classic example is smartphones, which experienced massive advancement and innovation in technology between 2010 and 2020. However, it is, hard to deny that the technology has stagnated recently, barely anyone is excited about new iPhone launches these days, and the technological improvements have become mostly incremental.

It is not outside the realm of possibility that it will take way longer for AI to work effectively with brownfield codebase than most people anticipate. @dhh had a great anecdote on his recent Lex podcast about that. (The presentation he mentions is “Web Design: The First Hundred Years with Maciej Ceglowski” from 2014; great presentation by the way).

In other words, it is difficult to say at which point of the S-curve we are currently at (A or B, above).

When it comes to software engineering specifically, I’d say we are starting to see incremental improvements already. Recent releases are definitely less exciting than the ones from 2023-2024. Some feel like almost backward steps 🤷. But it is worth being open-minded - for instance, GPT-5 is allegedly just around the corner.

So, where does it put us?

Real-world productivity gains are, as it is now, overhyped in real production code bases. If you are struggling with marrying LLMs with your messy legacy system, you are not behind. The whole industry is struggling with it.

It is not too late to experiment - and experiment you should because even if the gains present a sobering contrast to the prevailing hype narrative, they remain very much real!

And there are definitely levels to this game - the ability to work effectively with LLMs, even (or especially) with legacy codebases, is a skill that can be levelled up to unlock additional gains. For example, proper code compartmentalization seems to help (alas, it often is an elusive goal in legacy codebases). Heavier investment in company-wide cursor rules has also shown promising results, etc.

And as crazy predictions go: Who knows - maybe LLMs will suck with large legacy codebases for some more time, which will lead us to a situation where it is more practical to rebuild a system (with AI!), instead of refactoring/extending an existing codebase. In that case, everything will be greenfield until it isn’t, in which case it will cease to exist.

Until then, keep your shovel sharp.

The software engineering career path is fairly straightforward at the beginning of the career trajectory, from intern or junior up to senior engineer. It also tends to be similar across different organizations. It is in the post-senior engineering career that things start to get fuzzier. For many years, the unfortunate state of the industry was that the most viable long-term option was a foray into management. While this is an interesting and rewarding route, it is not for everyone. More than that, pushing everyone in that direction is detrimental both for the individual and organization as whole. The push toward management can either be direct (the only viable path in the organization) or indirect (for example, by not emphasizing the importance of the engineering path or by having an unreasonable pay gap between the engineering and management paths). Let's explore what the post-senior engineering path looks like and how you can prepare for what’s to come.

This article covers a few angles:

• Post-senior career trajectories

• Skills needed for post-senior career advancement and how they differ from pre-senior roles expectations

• A distinction between engineering and people management trajectories (with references to infamous tech skills vs soft skills debate that pops out every now and then).

I’ve previously covered bits & pieces of this topic, from an organizational perspective, in articles related to building an internal engineering career framework - part 1 and part 2. Here, I will focus on this phenomenon predominantly from the individual’s perspective.

Before I do that though, let's dissect the engineering career path at pre-senior stages so we can more clearly appreciate just how different a post-senior path is from what went on before.

Path up to senior level

In most companies there are few levels that precede senior roles. Typically these are: 

• Software Engineer Intern (aka Intern)

• Junior Software Engineer (aka Junior)

• Software Engineer (aka Mid)

These roles are usually followed by Senior, Staff (typically level above Senior) and Principal (depending on the organization it might be one or several levels above Staff).

Intern, Junior and Mid might be named differently like L2-L4 or E2-E4, but these are really just codenames for the same thing (big tech apparently likes codenames more than the rest of the industry). The actual sophistication or experience expectation at a given level differ from company to company but main underlying themes remain similar:

Scope, need for supervision and area of key focus undergoes an intuitive evolution as the seniority of engineer grows: scope and focus of daily activities expands and there is less supervision needed. 

An interesting aspect however is not captured explicitly above. This aspect is a matter of uncertainty that engineers need to deal with. Growing uncertainty is indeed the factor that many engineers struggle and feel uncomfortable with before they become fluent and capable with it. We can visualize it as below:

You typically expect Juniors to be given in-depth descriptions of problems, often coupled with decent descriptions of the desired solution. For instance there is usually some form of more or less detailed business expectation described (if my experience is any indication - usually less). 

If you work in the retail industry, the bug might contain the following description: "The generated invoice doesn't have the promoted line item with $0 value. Whenever we give a customer a gift due to promotion it should be the last item on the invoice with the price equal to $0". This actually forms a problem statement (missing line item) and a business solution (line item with $0 as the last position on the invoice). Usually what follows next is a conversation with a more senior engineer who might even tell the Junior which part of the system to look at and what is likely to be changed. This is part of the technical solution (where the change should be added). In short, the remaining work is the implementation, and even this is probably already roughly known by a more senior engineer.

The situation is a little more complex for mid-level engineers. They might get something similar to what’s above but, more frequently, the pointers to the actual implementation - where and how to modify code base - are less explicit or non-existent. After all, Mid-level engineers usually have the experience to use their own judgment and find the optimal implementation themselves.

Frequently, even a solution is not clearly given. What might happen is a problem statement such as: "This invoice doesn't seem right. Customer should have the promotion item highlighted somehow on it." Usually an engineer wouldn't have any idea what it should look like, but they'll extract some pointers to people who might know ("Talk with Mike from accounting, he might know"). In short, more communication outside of the direct engineering team area is needed and, to a significant extent, this communication is left in the hands of the engineer. This situation often becomes the ‘daily bread and butter’ for a senior engineer.

Beyond Senior engineers, the situation can become even more complex. The problem statement may be less clear, and it might even be expected that Staff (and higher-level) engineers help direct the organization toward the right problems to solve. While it may not typically be a business problem, it could certainly involve technical or organizational challenges, especially when these issues impact the effectiveness of the engineering part of the organization. Over time, problems often become a blend of business, financial, technological, and organizational factors. In larger organizations, many big problems exceed the boundaries of being purely technical.

One common example, highlighting the intersection of technical and business considerations, is deciding that some error conditions are too costly to prevent upfront, making occasional manual intervention more economically viable (e.g., Support contacting a customer to reverse an order). A notable anecdote from years ago is Amazon’s decision that it was more cost-effective to send an extra item in cases when a customer removed the item from their shopping cart just before finalizing the purchase (due to technical issue, the item was very rarely not correctly removed from the cart, even though customer didn’t pay for it), then actually technically preventing it happening.

And the further up the engineering ladder you go, the greater the uncertainty. Anyone who works successfully at Staff and Principal level eventually learns to live with it. As they say: it comes with the territory. Still, it takes time for most engineers to get used to it.

Post senior world

The traditional view is that engineers need to move into management after a certain number of years in industry. The tech world moves fast and, after a while, they cannot catch up and lose their edge. Or so the story goes. If my experience is any indication, some of the best engineers I've met are in their late forties, fifties or even sixties.

Sure, the way their work is performed usually changes. As the crowd wisdom goes - when you are young you have time but don't have money, and when you are older you have money (hopefully), but you value your time more. Similarly here: 20-year-old loose cannons can survive on coke and pizza in a 24h release crunch - which is still a necessity in certain areas of our industry or even a badge of honor for some. On the other hand, engineers in their fifties make it up with knowledge and experience (which might have even made the aforementioned crunch unnecessary in the first place 🤷).

Big tech got that right early on. In most of these companies, there are usually long career ladder branches for both management and technical disciplines. Here is part of the engineering career ladder from Google. It shows that engineering can be a lifetime career, spanning several decades.

This state of affairs is not evenly distributed across the industry. In many organisations, the engineering branch is significantly shorter than the management one. However, the situation is improving - perhaps due to the increased importance of technology in most companies these days - and the rest is also catching up.

When it comes to the management career path, a simple version might look like this:

At times, there might be a few steps in-between (Senior Engineering Manager, for example) or CTO might not be treated as a managerial role (CTO is a bit odd, some organizations treat it as the most-senior individual role, where the management aspect is handled by the VP of Engineering). It’s still pretty straightforward though.

Things aren’t that simple for the engineering roles. While building the Engineering Progression framework at VirtusLab, we realized that the engineering path up to Senior is intuitively simple. After that things become complicated as a variety of career trajectories emerge. 

Here are some of them:

• Tech lead - an engineer responsible for a particular area of software from a technology perspective (no people management as such). This might be either a service (or bunch of micro-services if this name still means anything) or a component. In many organizations Tech Lead might be mixed with Team Lead. Whereas this is certainly possible, it doesn’t have to be that way (I personally like to think of Team Lead as a first step in the Management career, rather than one of the steps on the Engineering ladder).

• Subject matter expert - an engineer having deep expertise in one of the areas important for the organization. This might be a technical area (e.g. streaming) or a particular crossing of technology and business domain (e.g. the Insurtech ecosystem). Depending on the organization, these areas can be as narrow or wide as needed (e.g. Insurtech is a field wide enough to have individual experts focused on a particular area within the field).

• Architect - the days of white bearded architects sitting for eons in their ivory towers, only to finally come back to enlighten pariah engineers with voluminous tomes of UML diagrams, are pretty much over. These days, design and architecture is a team sport and requires a hands on approach. Still, there are engineers who are better at big picture thinking and architecture than others, and they might gravitate towards the architect’s trajectory.

• Process engineer - most tech organizations require processes spanning multiple teams or even entire organization. These processes might be engineering recruitment, development lifecycle standardization or improving software quality across the board and many others. The VP of Engineering is usually accountable for this domain (or CTO, if the organization lacks a VP of Engineering), and they often have Staff or a Principal engineer responsible for specific initiatives. Engineers that thrive while building such processes (which involves system thinking, tactical approach and generating organization buy-in) might be called process engineers (or organizational engineers).

• Presales engineer - these are engineers who excel in customer facing situations, such as helping sales with new customers or existing customers with their problems or cross-sell opportunities. Engineers on this trajectory need to have solid engineering skills, knowledge of the product (or tech domain) and outstanding communication and presentation skills.

The list above is not exhaustive - there are certainly others. For instance, DevRel (or Dev Advocate) engineer is a role that’s emerged in the past decade. Ultimately, trajectories depend on the specifics and needs of each organization.

To wrap up, we have at least two typical career branches for post-senior engineers: Management and Engineering. Both present rich and rewarding career options. Whereas management is typically straightforward, the engineering path might expand into plenty of trajectories (I discuss some of them in one of previous articles, along with real world examples from other organizations).

Is moving up a necessity?

There is another option, the third one, which is rarely mentioned but is worth emphasizing. The third option is to stay at the senior level. This might come as a surprise, because the outside world often tries to convince us that we need to progress (or grow) at every stage of our professional career. I don’t think this is true and I specifically believe the option to pause is especially compelling at the Senior level.

Think of it. By the time engineers are senior, they usually make a decent salary. And, due to the time it typically takes to reach that level, many start having (or already have) families or other obligations. I think there is nothing wrong with choosing to put your career on the back burner while you focus on other things. Just go to the office (or just your desk at home), work for 8 hours, don’t think too much about it afterwards and maybe read a book or an article about new technology every now and then. In contrast, post-senior roles usually require more involvement than this. Often, it is difficult to squeeze them into a typical 8 hour day. Calls with other teams across the Atlantic during non-work hours, might be more frequent. Both responsibilities and stress rise and there is an expectation that you keep your edge. As a result, continuing to progress may actually make you less happy.

Additionally, the senior level in many organizations seems to be the last level where you spend a lot of time hands-on coding. Sure, you already have a lot of other responsibilities - you might need to coach juniors, participate in calls with people from other departments (like Sales or, speaking generically, business people 😱) or draft a design doc. Nonetheless, plenty of your work still has a focus on building software. This is the luxury that many post-senior engineers don’t have. In many organizations, between helping with organizational processes, preparing risk assessments for the board, reviewing docs, and participating in committees of various kinds, they don’t have much time left to do any actual coding. Oh, and you have to deal with the politics. If spending a bulk of time on coding is what you love to do, staying on the senior level might be a good option.

Staying at the same level might not have been an option earlier on. In many organizations, both intern and junior levels are considered an “investment”. This means, some organizations perceive engineers on this level costing more (in terms of salary but predominantly in the form of time spent by more senior engineers) than the value of work they deliver. As such these roles are often perceived to be “up-or-out”. Up-or-out is a term taken from typical partnership firms, such as legal, architecture (buildings, not software) or medical practices. Essentially, it means that there is a period of time during which an individual must progress to the next level, otherwise they will be pushed out of the organization. In many classic partnership firms these conditions are explicit, whereas in tech companies it tends to be implicit i.e. at some point there starts to be a problem on the performance review cycle if you stay on these roles for too long (imagine being Intern for 5 years).

Technically speaking, one can choose to stay on Mid level. It is certainly possible. However, Senior is usually a natural extension of Mid (as the job responsibilities and expectations follow a similar pattern) and it has a better pay grade. With that in mind, the senior engineering level seems to be a good balance - an inflection point before the type of work shifts away from predominantly hands-on coding.

Speaking of change, let's focus on pre-senior vs. post-senior in terms of expectations and factors that might help you cross the chasm and move forward.

In this section I want to focus on some of the key attributes or skills that will help you progress your career in the post-senior phase. Now, you may notice that I've left out technical skills completely. That doesn't mean they're no longer important - they very much are. The degree of importance and angle you need to take for further development of technical skills depends on the engineering trajectory you pick (that is to say that e.g. Process Engineer might need different skills than Presales Engineer). You surely cannot go wrong with levelling up competencies in area of software architecture (and generally designing software), understanding tech landscape or full software development lifecycle (SDLC) processes etc.

The thing however is that Engineers by the time they are Seniors, already got accustomed to expanding their technical skills. Yes, further development of technical skills is still important, but it alone won’t be enough anymore. 

Let's look at the less obvious characteristics of the post-senior career path and the skills you’ll need to hone along the way.

Necessary vs sufficient conditions

Progressing from Junior to Mid is relatively straightforward. There are certain conditions (typically specified in the company’s engineering progression) that you must fulfill. As soon as you have fulfilled them, you may get promoted (well, technically you might need to wait for the next performance review cycle, etc.). At least that used to be the norm. In the newer, post-ZIRP world, many organisations are struggling with budgets (budgets that were overly-inflated in the ZIRP world) and this is having an impact on promotions. In this situation, it is often a question of salary increases rather than levelling up. This means that while your level may have increased, your salary may have lagged behind 🤷‍♂️. This situation becomes more complex in the post-senior world where multiple angles must be taken into account.

First, an extreme example just to make a point: the promotion to CTO. Whereas it is straightforward to be promoted from Junior to Mid, the situation here is more complicated. Unless your organisation is growing rapidly and has roles for different CTOs (e.g. field CTOs or CTO of a region or technology or domain area), which is rare, it is highly unlikely that you will get the role if the CTO is already there in your organisation. The window of opportunity may open when the CTO leaves. Even then, there is likely to be only one vacancy and the next person in line will often have to wait several years before the window opens again.

The bottom line is this: on one end, promotions from junior to pre-senior positions depends on you meeting the expectations. On the other end, promotion to CTO additionally requires an open window of opportunity; a factor beyond your direct control. Everything in-between senior and CTO is shades of gray in this respect. Naturally there are more spots (even theoretically unlimited) for e.g. Staff Engineer than VP of Engineering, but constraints may exist. For instance, promotion process may involve more scrutiny, whereas the promotion from Junior to Mid might have been the sole decision of your manager. Or there may be a company-wide committee responsible for promotions to Principal (a sort of bar-raisers), or it could be vetoed by your manager's peers or their boss (more on this later).

Enablers

Roles below Senior are clearly individual contributor roles. Engineers participate in the larger scheme of things by contributing their efforts to the equation. We can visualize their work as a part of a sum (technically called a summand):

(Naturally, that’s an oversimplified model yet I hope it will help drive the point).

Managers, even if they contribute significantly to the overall work (they have a summand element) also have a bigger effect on the work of the entire team. That is, assuming they do their work well, they are an “enabling” element. Unfortunately, this means that they also can become blocking (or obstructive) to the whole team. This is intuitive to anyone who has spent a few years in the industry. Good managers can get a mediocre team to achieve great results, bad managers can get a great team to achieve mediocre results (or worse, get all their great players to quit).

Here are some ways managers may improve or hamper the team’s effectiveness:

• Good managers set clear goals and expectations for the team (e.g. by managing external stakeholders well). Bad managers allow priorities to change often without a single coherent vision. 

• Good managers ensure that required resources are allocated for the team (e.g. compute cluster time is available when needed). Bad managers don’t have sufficient organizational influence and are never able to provide resources the team needs. 

• Good managers foster a healthy team atmosphere where people can freely criticise ideas and problems in order to find better solutions. Bad managers emphasize individual achievements, where teamwork is always secondary and any root cause analysis turns quickly into a blame game.

In a way, a significant part of the managers work is to be a “multiplier” (or factor in mathematical terms) in our simplified equation:

In fact, this is true for all leadership roles - not only pure management. The more we go into leadership roles, the more impactful the “factor” element in the equation is (for better or worse, as mentioned earlier). 

There is an interesting point one may argue about here, namely the fact that “Not every Manager is a Leader, and not every Leader is a Manager” (you can read more about it here). I am not going to argue with the former part. Many organizations use the name Leadership as a synonym for Management (e.g. Leadership Career Path). We would most likely all agree that all Managers should at least aspire to be Leaders. I do believe that the second part - that “Not every Leader is a Manager” - is a crucial part in the context of this paragraph. Specifically I’d argue that Leadership becomes an increasingly important part of the role in the post-Senior stages of an engineering career. I made that point earlier in one of my previous articles. In fact, one could argue that the Leadership component of post-senior engineering roles is in a way even more demanding, than in Management roles. This is due to the fact that Engineering path usually doesn’t involve traditional direct reporting lines. For example, Staff Engineers working to improve the security of an organisation's software supply chain, or to improve the effectiveness of the technical recruitment process, may need to influence many teams across the organisation and generate buy-in without a direct reporting structure. Not to mention, they are often responsible for mentoring more junior engineers or setting an example in the organisation. In short, much of the work of the post-senior is an empowerment style of working. 

The bottom line is that post-engineering roles require the development (and use) of leadership skills. These include competencies such as communication, decision-making, strategic thinking, accountability, mentoring, conflict resolution, influencing and emotional intelligence. Each and every one of these is a learnable skill (up to a point) and engineers aspiring to post-senior roles will do well investing in developing them.

Communication

I mentioned communication earlier but, based on how important it is for post-senior engineers, I believe it deserves a dedicated section. By the time engineers become Staff-level, they’ve already likely authored or co-authored many design docs and other types of engineering documents. This is both useful (in terms of the function these docs serve) and educational (in terms of honing communication skills).

However, I am talking about communication more broadly, including:

• Written - design docs, guidelines, wiki pages, emails and Slack (or whatever communicator you are using) 

• Spoken - direct 1-1 or speaking within a group of people 

• Hybrid - usually presentations. 

Of these above, I believe that written communication is the most important. A few famous companies, amongst the many that rely heavily on outstanding written communication, are: Shopify, Hashicorp, 37signals or Stripe. In general, it is fair to say the written form represents the majority of communication within most modern day tech companies. Especially so, if we consider emails and instant messaging tools (Slack, Teams etc). And consider them we must, since they are the main communication media. When it comes to working with senior managers, directors and executives, the difference between a sloppy and well-written email may cause the initiative you are advocating being pushed through, entirely blocked or (most-common) not considered important enough to be granted sufficient budget. It is that serious.

I won’t dive into how to write well in the business context. Josh Bernoff already did it extensively in his book: Writing Without Bullshit. It is roughly 300 pages long and, since it will be relevant for anyone moving beyond Senior, I just recommend reading it instead.

One of the key concept covered by Josh is his ROAM framework which stands for:

• Readers - who is your audience (What is their understanding of the topic? What are their goals? How much time would they invest in reading your text? etc)

• Objective - what change in the reader do you expect your text to make? (Will they change their mind regarding the topic? Will they determine they got all the information regarding the decision to make?)

• Action - what action do you expect the reader to do after reading your text (What desired action should the reader do afterwards? What would you consider to be a success after the reader reads your text?)

• iMpression - what impression will your text instill in a reader? (in other words - how would they perceive you after reading the text? Would they think you are professional? Would they think you valued their time by presenting the information clearly and succinctly?)

Here is an example:

• After reading this email, my VP of Engineering, who is involved in many performance reviews at this time of the year [reader], will understand the risks involved with keeping the legacy payment component in place [objective] and agree with my proposal of spending 2 weeks of engineering effort in replacing it with a new version [action]. They would also value my thorough, unbiased and professional analysis of pros&cons, that helped them go through the proposal effectively [impression]. 

You can read an extract about this sole idea here. That’s one of the concepts that I found extremely useful on a daily basis. There are many more in the book. Do yourself a favor, and read it. 

Team Work

Nearly all technology organizations doing complex work rely on teams, instead of individuals. You might have great players, but in most growing companies, it is a team effort that counts. As work of engineers beyond seniors has a growing enabling component (which I covered earlier) its inevitable part is effective team work. 

Key skills in this area include: 

• communication - covered more extensively earlier, 

• adaptability / open-mindedness - ability of being flexible to changing circumstances, 

• empathy - ability to understand others’ feelings, 

• conflict resolution - ability of resolving conflicts (or even difference of opinions) peacefully and effectively, 

• conscientiousness - doing your work with responsibility and diligence, being reliable

• and agreeableness - ability of being compassionate, cooperative and friendly (which doesn’t mean you need to agree to everything).

Sure, some of them - like high levels of empathy - are given, you are born with them or you developed them in your early years. Still, all of them can be significantly improved with deliberate practice or even just self awareness. Bottom line is - as Steve Jobs famously said - “Great things in business are never done by one person, they are done by a team of people”. Investing in skills to increase effective team work is a sure bet that will pay off. 

Ownership and limits of your sphere of control

This phenomenon comes up in conversations so often, I thought it deserved its own section. As already discussed above, most larger initiatives require team effort. In the life of a post-senior engineer these teams might be informal, temporary and part-time (e.g. working groups assembled to improve tech recruitment process), but they are teams nonetheless.

Staff and Principal engineers might be put in charge of such teams. As such, their area of ownership (or as some call it - accountability) expands. An ownership is an important word here - because this ownership may expand beyond the areas you are directly responsible for. A particular area might be a responsibility of someone from the working group, but you are still accountable for it.

All this is pretty much daily bread and butter for engineers who have moved up the management career ladder. Yet, it seems to come as a surprise for many following the engineering career progression.

The first step is to accept and understand the phenomenon of ownership going beyond your direct work. The second step is to learn at least a little bit about management, and especially delegation. Yes, you are on an engineering career trajectory, but the management skills are still relevant, just to a lesser extent than on the management path. In this subject, you cannot go wrong with High Output Management - the seminal work about management, by legendary Intel CEO - Andy Grove. 

Business understanding 

I’ve used the phrase “business understanding” to emphasize that it goes way beyond “business domain”. The phrase encompasses areas like:

• Business domain 

• Organization priorities 

• The key stakeholders and influencers, together with their priorities. These may range from slightly different from the organization’s priorities to completely misaligned (sorry to break it to you, but the latter might happen more than anyone involved would like to admit!)

Creating business software is inextricably tied to achieving some business results. These results might range from increasing revenue, decreasing costs, increasing customer satisfaction, lowering the business risks and so on. The key is that there are some concrete business goals. Real world organizations are rarely as laser-focused as depicted in business books. Often the reality is that there’s more than one business priority that needs fulfilling. Five or more is not uncommon and the key stakeholders might not clearly articulate which are more important than others. It may sound sub-optimal, but its a situation you’ll need to deal with.

Understanding the goals and priorities of the software you are working on is paramount. In general, software architecture should be built around business needs and characteristics. It is difficult to build software or design organisational processes that support technology well without at least some understanding of it.

Likewise, understanding who is pulling the strings, what kind of influence particular stakeholders (individuals or organizations) have on the project, is also important. Being effective in any organization means generating buy-in from the right people or parties and it is very difficult to move the needle without understanding these matters.

This may sound like borderline being involved with organization politics, and that’s generally correct. However I do not suggest immersing yourself entirely in politics. People who do that to a large extent and (!) enjoy it, usually come with a package of additional questionable traits. What I do advise is to be aware of its existence and not ignoring it.

Network

Last but not least there is an interesting subject of building your work relationship and network.

First of all, as mentioned earlier, the post-senior promotion process is usually more involved than at the earlier levels. It may require acceptance from your manager or even an entire committee (usually your manager’s peers or more senior engineers - e.g. Staff or Principals). Sometimes, there is a strict budget or other limit for promotions in higher-level positions. As such a good rule of thumb is to build a good relationship, not only with your manager, but also their peers, their manager and most senior engineers in the organization. Generally, the higher up the chain the better. Usually, your reach has vertical limits and stretching it starts to seem dishonest (the work of the director 3 levels above your manager might be too detached from your area of work anyway). The rule of thumb above is a good tradeoff. If you want to improve your luck, try to ensure you have some exposure to these people. Sure, you might try to create a casual encounter in the kitchen and strike up a conversation about common interests —perhaps discovering that you both enjoy playing squash, pickleball, or whatever the next trendy activity might be. Some might see this as perfectly fine, while others could view it as bordering on "sucking up" - depending on the character and cultural environment. Also, social endeavors like this may just not be your thing. That’s actually fine as a far better and more reliable option is just to get involved in the practical, work initiatives with exposure to the right people. Perhaps there is an initiative looking for volunteers that you could apply for? This may be participating in an organization-wide initiative of unifying APIs, improving tech recruitment processes or helping to update engineering progression guidelines. Opportunities abound, if you look for them. Nothing helps people remember you (build your “internal brand”) better than showing professionally done work.

The second thing is building a network outside the organization. This comes from a simple fact of life: as you grow in your seniority, the number of people who could coach or mentor you quickly decreases. This could be intuitively visualized by juxtaposing junior engineer and CTO. Junior engineer, a role which is pretty much entry level, still has a lot to learn in their career and, more importantly, has many more senior engineers around them. At least, hopefully that’s the case. If they don’t then that’s a problem on its own. These senior engineers are not only capable, but also incentivized (again, hopefully!) to mentor more junior engineers. 

Now, let’s take the other extreme: CTO. As the most senior person in the engineering organization, they might not have anyone nearby with experience in the scope of their role, or generally, a more senior engineering leader. Moreover, engineers typically work with other peer engineers (on the same level, or more or less senior) and a CTO’s typical group of peers is composed of a CFO, COO or CMO. At best, they might have a peer CIO (Chief Information Officer) or one of the more modern roles like CDO (Chief Data Officer), though such settings are rare. I’m not saying that a CTO cannot learn from someone in their engineering organization (either direct or indirect reports). Sure, the organization probably has people more skilled and experienced in specific areas, but there is likely no one who wore the boots of CTO before.  

So, comparing a junior engineer (the most junior technical position) with a CTO (the most senior technical position) gives us an extreme example. The roles in between fall on a spectrum spanning these extremes. Staff engineers work less frequently and less directly with more experienced engineers than junior engineers. 

Ultimately, the solution is to mix internal mentors and coaches with external ones. This might be a group of peers that you know from previous companies. Or it might be a network group that you built yourself over your career. An external group has a lot of benefits such as being emotionally detached, having an unbiased perspective and a different set of experiences. 

If you don’t have such group, there are some paid options:

• Luca Rossi organizes a lightweight version via his Refactoring Community (a companion to his Refactoring newsletter). 

• CTO Craft organizes lightweight (Slack based) access to other industry tech leaders, as well as more structured (and priced higher) monthly round tables with a smaller, more intimate group. I’ve been part of it for 2 years, and I highly recommend it if you can afford it.

• I’ve heard some good opinions about Plato Community - including it’s 1-1 - but never have tried it myself.

Structured/facilitated options are in my opinion better for discussing concrete challenges. The problem is the price, which might easily go north of $1,000 a year, though some companies might reimburse the fee for more senior employees. 

There are likely many other options available, including ones local to where you live (face-to-face beats Zoom calls when it comes to support groups). 

Wrap up

We have covered a lot of ground in this article, depicting the characteristics of the engineering roles beyond senior level, potential career paths and the skills needed.

One additional thing that’s worth noting: choosing a path (e.g. Management) that eventually turns out not to be in line with your vocation, is not usually a grave mistake. Most organizations allow lateral movement between Engineering and Management paths (often with none or minimal negative effect on salary - depending on the depth of their engineering career track). 

My personal experience is that such a temporary foray into management might be beneficial for a post-senior engineering career. Charity Majors even wrote a whole article about the idea of switching back and forth between engineering and management - The Engineer/Manager Pendulum. There is nothing better than direct experience on the other side to cure some of the detachment that happens between Engineering & Management in some organization. The grass is always greener on the other side.  

As a closing note I am linking some great book resources that might help you in post-senior engineering roles:

• Writing Without Bullshit by Josh Bernoff - hands down best book about effective business writing.

• Staff Engineer: Leadership Beyond The Management Track by Will Larson - great book focusing on first beyond-senior role - Staff Engineer

• The Software Engineer’s Guidebook by Gergely Orosz - covers the role and skills for senior engineers, the foray into team leadership and into post-senior roles

• The Manager’s Path by Camille Fournier - isn’t related exactly to the career of post-senior engineer as it covers Engineering Management path - from Team Lead to CTO. However it might give you a good overview of how life on the management path looks like.

• High-Output Management by Andy Grove - absolute classic when it comes to management books. As mentioned earlier, some management skills are needed anyway on the engineering path and this book provides the basics, bundled with an interesting story.

As always, don’t hesitate to reach out to me if you are interested in any of the areas outlined in the article. You can find my contact details here.

Till next time 👊

This is the second of three parts of articles describing the journey we made at VirtusLab while creating an updated version of the engineering framework.

This time, there are two major sections here:

1. Analysis of most common structures of engineering progression framework in real-world organizations (starting from section Choose a structure for your progression)

2. Tips & Pitfalls to have in mind while building framework (starting from section Things to consider when detailing your engineering progression)

In the first installment, I covered the case for building engineering progression and the groundwork. In this article, we switch to the nitty-gritty details of creating an engineering progression and its release.

Wait. You skipped the first article? Here’s a quick reminder of what I mean when referring to an engineering progression framework:

An engineering progression is a career ladder for engineering roles within a given organization. From a high-level perspective, it is a roadmap for an engineering career designed to help both engineers and their managers navigate their career paths over the years. From a low-level perspective, it covers a set of required skills and expectations to be met at a given level of seniority. In addition, it more or less directly indicates the engineer's salary.

Choose a structure for your progression

Let's begin by picking a basic form for your engineering progression. But where to start? How about taking a look a progression.fyi, where you'll see many different progressions, each drawn from a real organization. If you are building an engineering progression for your organization, I strongly recommend you browse through the examples on that webpage.

Engineering progressions typically fall into a small handful of distinct forms. Different organizations, of course, emphasize different aspects of how engineers work or how their culture works (which I covered in the first part of this article series, in the section Things to be clear on before building your engineering progression). What's less obvious is that the most appropriate structure for you will be a function of several parameters related to your organization. Most likely, the key parameters will be:

• The size of your engineering organization 

• Role diversity of your engineering organization (number of various roles e.g. application engineer, data engineering, technical project manager, etc).

What does this look like in practice? Let’s look at a few typical approaches.

A simple approach

In a small, relatively homogeneous engineering organization with mostly one type of role, perhaps the simplest approach is the one Basecamp / 37signals used in 2017. 

It focuses on just one type of role - programmer. Each seniority-level description consists of just a few bullet points. When the junior role is dissected, it contains these basic elements:

• Scope of work: “Works primarily on tightly scoped, routine problems.”

• Skills/capabilities: “Basic language features are mastered, but some advanced structures may still be unfamiliar.”

• Length of experience: “Usually less than 2 years of experience being a professional programmer in the specific domain.” 

I've noticed that adding explicit years of experience is controversial for some people. Personally, I think it is a good idea, and will cover the pros and cons in the Years of experience vs. speed of climb section later in this article.

All in all, this structure is simple, and that is its greatest strength. In fact, I'd go so far as to say that, in my experience, this is the way to go for most companies that are:

• Relatively small (say up to even 50 people); especially if they have mostly similar roles

• Building their first engineering progression framework (because it is likely to provide the best bang for the buck).

It is also simple from the perspective of particular ladder levels. It is a straight path, with fairly obvious stages, without any branches. 

It is no coincidence that I used this approach when I was building an engineering progression framework, circa 2012. This was for a small consulting firm that I co-founded. We had about 10-15 engineers back then, and we needed something simple. We also used something very similar at VirtusLab between 2015-2020. In retrospect, I see the framework we built had a ton of problems, but we’ll get to that in a moment.

There are also other notable, well-structured examples of this approach - for instance, Monzo’s Engineering Progression Framework v3. This one has more levels - and now they aren’t universally as obvious as the previous example. This requires some additional Monzo context-specific information - which they do provide with the basic split into Impact, Technical Skills, and Behaviors categories.

It is clearly more complicated than the simpler approaches used above, but it seems very well justified - at the time of this writing, Monzo had likely more than 200-300 engineers on board. This leads to a full-blown competency-based approach, which will be discussed next. 

Competency-based approach

The competency-based approach is effective, although more complex. As long as you capture the characteristics and culture of your engineering organization accurately, it can work quite well. 

As an organization grows, the limitations of the simple approach become apparent. 

As an organization grows, it becomes more fragmented and siloed (unless leadership consciously and relentlessly counters this drift). This is a phenomenon that may be all too familiar to anyone working in a growing organization. 

At VirtusLab, noticing the lack of consistency in how engineers were being evaluated, we created a quick experiment.

1. I wrote a list of artificial engineer profiles. The role descriptions consisted of general characteristics, strong/weak points, some indication of recent accomplishments, and a general indication of previous work experience. 

2. I showed this list to 10 managers and team leaders and asked them to match these synthetic profiles to the seniority levels seen in our existing engineering progression framework.

3. The results left much to be desired. We had good alignment for some profiles. We also found that for others - about half of them - we had discrepancies for the same profile ranging from Junior+ (advanced Junior) to Staff- (early Staff). The experiment’s results made us realize it was time to raise our game and modernize the engineering progression framework.

At this point, we were clear we needed to bring in more fairness and consistency, and help managers and engineers with career guidance.

What we'd experienced is what often happens in organizations as they grow, briefly:

1. More managers/leaders appear in the organization. Direct lines of communication become less effective and the need for more concrete guidelines arises. 

2. The organization becomes more diverse in terms of its engineering roles. 

These are challenges that the simple engineering progression can be adapted to meet:

1. Split the general expectations into separate, more quantifiable characteristics or competencies.

2. Add multiple parallel engineering progression ladders.

This typically leads us to what I’d call a competency matrix (sometimes called a rubric). My favorite example is the CircleCI progression. It is very well thought through.

The basic elements in this progression are:

• Seniority levels (e.g. “E3 Senior Engineer”)

• Scope of work (called “scaling of competencies” in the CircleCI progression)

• Competencies (e.g. “Debugging”).

In this progression, the competencies and seniority levels work together intuitively. The scope of work scales from an individual task (for a junior or associate engineer), to teamwork (for senior engineers), to the entire organization (for principal engineers).

The competencies are also grouped into categories. For CircleCI these are: 

• Technical skills

• Delivery

• Feedback/communication/collaboration

• Leadership

• Strategic impact.

Five in total. While these categories are specific to CircleCI, when you look at a number of organizations, patterns emerge. For example, in our second approach to engineering progress at VirtusLab, we developed three categories: Engineering, Delivery, and Teamwork. Another example is Dropbox, which uses: 🏆 Results (a variation of Delivery), 🌟 Direction, 🌈 Culture, 🌳 Talent (all closely related to Teamwork), and 🦉 Craft (a variation of Technical Skills).

The most surprising finding for some, however, is that hard technical skills typically represent only a small fraction of the total expected competencies. This is interesting in the context of recurring online debate about whether soft or hard skills are more important for software engineers. Here’s my take, based on my experience with hundreds of engineers I’ve managed over the course of my career:

• Hard skills are required and are key conditions for promotion in the first part of the engineering career. 

• Soft skills start to play an enabling role in the later stages, from senior engineer onward. They won't guarantee advancement on their own, but a lack of them will severely limit further development.

Don't get me wrong. Not paying attention to soft skills (collaboration, communication, etc.) will be detrimental to an engineering career at any level. However, you want to pay a significant amount of attention to this for the more senior engineers. On the one hand, your seniors, staff, and principal engineers set the tone for the entire organization (by orders of magnitude more than juniors). On the other hand, most senior positions require strong leadership skills (which in turn require good soft skills), even if they appear to be individual contributor roles. 

I covered this in the Leadership Management vs Engineering section of the first article in the series. It is almost impossible to perform well in Staff and above engineering roles without well-developed soft skills. 

Returning to the explicit split of competencies in the progression framework - even Basecamp (now 37signals) has begun to use separate competencies in their engineering progression circa 2018.

While it is definitely not the case that EVERY organization will eventually move in this direction, it is pretty typical for many growing organizations. I'd say when you have +100 engineers in your organization (and thus likely between 10 and 20 teams), the need for such a change will be apparent. 

In addition, most growing organizations dealing with complex technology products quickly build more diverse roles. While they may initially have front-end and back-end engineers, they will eventually introduce designers, cloud engineers, data analysts, or ops. Whereas you can probably handle a fair share of traditional engineering (e.g. backend/frontend) with a single engineering path, it might not be feasible anymore to do that for all types of engineering roles (e.g. designers, ops). 

Sure, you can create a very general progression, but I would argue that its usefulness quickly diminishes if it becomes too general. Since one of the purposes of an engineering progression is to establish consistency across the organization, it must, by definition, be tangible enough to be understood similarly by engineers and managers throughout the organization.

One thing to keep in mind is the increased effort required when moving from a simple progression to a more complex one, complete with explicit competencies and different career paths. The division into different specializations (career ladders) effectively multiplies the work you need to do to create and optimize the progression. In addition, explicit competencies require a deep understanding of the specifics of your organization and its evolutionary path.

While a simple engineering progression could be written almost overnight by a founder (well, the first draft, at least), a more complex version with a competency matrix and multiple career ladders will most likely require a working group active for many weeks. This is not easy work. There are several reasons why:

• You need to break the work down into discrete, concrete competencies/characteristics.

• You need to provide concrete descriptions of the competencies at different ladder levels.

• You need to cover multiple roles, some of which may be less familiar to you (most engineering leaders have experience with some parts of the engineering work; but how many have the work experience with all the roles in the organization?)

• By the time you are ready to build a complex engineering progression, your engineering organization will likely have many practice areas with their respective leaders or role models. It will be critical during the rollout phase to have their buy-in. Getting them (or someone from their sphere of influence) involved early on will definitely help.

Make sure you plan accordingly!

Optionality and trajectories

One of the problems that typically arises with competency matrices is that they assume that everyone within a given career ladder is the same. That is, there are specific requirements for each competency for an individual to be at that level. And it's worth noting that CircleCI relies on no less than 28 different competencies to define whether an individual is at a given level.

I have found this approach too prescriptive for larger, more diverse organizations. It's even unrealistic for smaller organizations, but not as obviously as in a larger organization. You are bound to end up with many engineers who not only meet certain requirements, but far exceed them while falling short in others.

A more liberating example is the progression used by Medium. They have done a great job of describing how it works in this series of articles. Basically, they have four different areas (Build, Execute, Support, Strengthen), each of which contains multiple competencies. You can see them here. Achieving milestones in these competencies gives you a specific number of points, and there is a specific threshold of points you must achieve to be promoted. How the engineer earns these points (which track they choose) is entirely up to them! 

This is an extreme example of codified choice, but it is far from unique. Another example is used by a company very close to me - and now part of VirtusLab - SoftwareMill. You can read more about their "badge-based engineering progression" here.

Above, you can see an extract from SoftwareMill’s engineering progression. Here’s a note on how to decode it:

• J1, J2, M1, S1, E1 - these are engineering levels (Junior, Mid, Senior, Expert)

• 7B, 9S, 2G - these represent specific badges. They fall into three types: Bronze (B), Silver (S), and Gold (G), each being more difficult to earn than the previous one.

Badges are related to achievements in specific competencies. For instance, knowledge sharing, architecture, production maintenance, etc.

Competencies are segregated into three groups: Technical (hard skills), People and Development (soft skills), and Organizational.

As you can see, the progression framework allows for considerable flexibility, but it also imposes some constraints. For example, to advance from S1 to S2, you must earn 9 silver badges, 5 of which must be in the technical category. 

In my opinion, some flexibility in the progression framework is desirable. This is especially true at higher levels. Staff+ is where most people's careers start to diverge according to their different strengths. But be aware of the trade-off - this is another level of complexity you bring to the table.

I think you want to allow some flexibility, but at some point, you have to split into separate career paths. In the case of Flatiron, Cat Miller says they eventually decided to split engineering after the E5-E6 level into two paths: the Principal Track and the Architect Track. I think this is a reasonable compromise.  

All right, we have covered the most typical structures used for engineering progression frameworks. Now let's discuss the key aspects to consider, tips from experience, and typical gotchas.

Things to consider when detailing your engineering progression

Now, let's move away from the high-level structure and zoom in on the details and key considerations to keep in mind when building the framework.

Picking competencies to add to your matrix

Whatever type of engineering framework you're working on, you need to think about competencies and attitudes - whether you show them implicitly (as with a simple approach) or explicitly (a competency matrix). Either way, you need to be clear about what set of skills and attitudes is required for a given role and level. 

For any non-trivial job like software engineering, we quickly conclude that there are many skills and attitudes to consider. I'd say it's worth spending some time identifying the most important ones. In my experience, it is difficult to narrow it down significantly below 10. On the other hand, more than 20 can be overwhelming. The CircleCI example used earlier contains 27 different competencies. In my opinion – even though it may work great for CircleCI – it might be too many.

Keep in mind that distilling them into the engineering progression framework is just step one - the easy part! Then you need to get all engineers and managers to understand them well and use them regularly for performance reviews and 1:1s. Depending on the nature of your organization, you’ll spend different amounts of time on these activities, but keep in mind that if it’s too complex or time-consuming, it’s likely that only a few people will do it well, and everyone else will just treat it as another company bullshit they need to get through. 

The obvious trick is to group them into some logical buckets. This is backed by science - grouping helps you remember more. In our context, it helps managers and engineers remember the competencies relevant to the organization and their careers. 

A balanced, manageable number, 10-20, will also help you be concrete when applying it to a variety of different roles. For example, at VirtusLab we've found that we can use the same skill set for backend application engineers and frontend engineers, even if they specialize in different technologies, from Scala to Java to Typescript. However, we concluded that Data Engineering would require a modified skills matrix. Designers would also get a different matrix.

Avoiding low-level concepts, such as knowledge of specific tools or frameworks, is the key to achieving broad applicability while still being tangible and useful. We concluded that, even if we wanted to separate frontend from backend paths, we wouldn’t focus on tools and frameworks because they change too often from project to project. Instead, we divided technology competencies into high-level skills: writing code, maintenance/production, technology landscape expertise, architecture, and DevOps. I’m sure the exact breakdown is pretty much specific to us, but it shows the level of granularity. 

The key here is that it doesn’t make sense to get too specific (e.g. talking about the particular programming language, framework or methodology) because it changes over time and from team to team. Also, it sounds a bit too dogmatic and counterproductive to focus your engineering culture on particular tools. On the other hand, being too general doesn’t make too much sense either - remember that the main goal is to build consistency across the organization. Being too general won’t help. Pick the competencies that are relevant to your organization. If observability or security is relevant to most engineers in your organization, it should be part of the rubric. Not every organization emphasizes these aspects for every engineering team - especially with a siloed dev vs. ops culture. For example, we chose "maintenance and production readiness," which includes security, observability, diagnostics, etc. 

We also found that for different engineering roles (Ops, data engineering, application development), even if we create separate career ladders and competency matrices, the competency matrix really only differs in terms of the hard skills. Delivery and teamwork remain largely the same. This is not unusual, as these categories are more tied to company culture and organization and, thus are likely to be more common across disciplines. One exception is purely management roles, but that’s a different story, probably a separate career ladder and perhaps a topic for another article.

The bottom line is:

• Do your homework: verify the competencies that are relevant to your organization (as opposed to copying them from other hot companies)

• Keep the number of competencies in check (< 20)

• Group competencies into logical buckets that help people keep track 

• Don’t be overly specific, especially with technologies, or too general either.

Track record vs. present capability

We put statements like these in our first engineering progression:

Is able to plan & design the architecture on a project-wide level. Can discuss requirements with customers / stakeholders. Is able to set up processes. Can drive interactions / integrations between multiple, technologically diverse components or products.

Capable of leading regular projects, with several engineers involved or is starting to be widely recognized for his/her expertise in their field of choice. Share knowledge with others (mentoring, conference talks, blog posts, workshops, meetups).

There are a number of problems with such statements. First of all, it is asking for trouble to use statements like: "is capable of...". What does that even mean? We've had many situations where engineers come to managers and say they can do X, but they don't have enough opportunities to prove it. It bit us many times, and countless hours were spent on such conversations during 1:1s.

The harsh truth is that no matter how you design your career ladder, there will be patches in the organization (a project or group of projects) where the local situation doesn't allow engineers to manifest or hone certain skills. For example, there may be a team that is effectively keeping the lights on for one of your legacy projects that will (hopefully!) be decommissioned next year, and they have limited potential to excel in architecture skills.

The same goes for the availability of leadership opportunities, such as taking the lead on initiatives that span multiple teams or stakeholders. While these opportunities may come up from time to time, there is still the issue of timing in the context of a given performance review cycle. There will be periods of time when some people may be technically ready for something, but they just haven't had the opportunity. 

In my opinion, the better way is to have an actual track record. We should at least have some tangible - even if imperfect - proof that engineers are actually doing the work to a given standard. It may be a bit unfair (again, opportunities are not evenly distributed), but it saves a lot of headaches that can ripple throughout the organization. 

The bottom line is to avoid phrases like "can do" or "is able to. It is much better to rely on "has a track record" or "has demonstrated the ability to do X more than once.

Frequency and intensity

There’s a similar kind of problem found in statements such as:

Shares knowledge with others (mentoring, conference talks, blog posts, workshops, meetups).

Is one internal workshop enough to qualify? How about one per year or one per quarter? I am against being too prescriptive, but there should at least be a guideline for what we expect. You definitely want to avoid the checkbox exercise where you're asking some people to do certain activities once to check the requirements for promotion. 

Sometimes it might be enough to clarify that we are talking about the pattern of repeated behavior (such as: "this person is known for sharing knowledge with others") rather than concrete numbers ("you must do some form of knowledge sharing 3 times" for example).

Years of experience vs. speed of climb

I am not a big fan of role prerequisites based on years of experience. First of all, not everyone is the same - some people grow and learn faster than others. Second, not all years of experience are the same. As the saying goes: "Some people have 10 years of experience. Others have 1 year of experience 10 times over.” At the same time, experience that comes from practice is important. And practice takes time. Most experienced engineers would (and should) be suspicious of someone with 2 years of experience claiming to be senior.

I don't think we should be too dogmatic about this. I favor descriptively stating typical years of experience for a given level of seniority. It shouldn't be a showstopper for someone who doesn't meet those values, but it should at least make you suspicious and ask the right questions. Having some benchmarks might also make it a little harder for managers to give in in times of intense hiring pressure from the CEO or otherwise (and thus tendencies to lower standards). 

The same goes for the time it takes to progress from one level to the next. If someone is progressing too fast, it shouldn't be a showstopper, but it's probably worth investigating. In the worst case, an exceptional individual comes to your attention thanks to such investigation. At best, you discover a situation where the manager gives in to pressure from a very salary-conscious engineer who, for example, threatens to leave if they don’t get a raise. At the end of the day, you want to be fair (promotions based on merit, impact, attitude), and allowing pushy engineers to be promoted faster does not do that. This is also related to the point made in Frequency & Intensity above. If we are going to focus on a "pattern of repeated behavior", it is definitely going to take some time to establish that.

What are the right values here? It depends on the organization, but a good rule of thumb might be to wait at least one or even two years before promoting to higher levels. Again, that's a guideline, not a hard and fast rule. 

Is “up or out” effective?

The "up or out" scheme comes from some partnership systems, especially law and consulting firms. It generally says that you have a certain amount of time to reach a certain rank. If you fail to do so, you must leave the organization. 

I don't believe in the myth that everyone in IT needs to advance their career indefinitely. This may be fine for some people (achieving certain roles as a life goal), but I think it is beneficial also to be able to accommodate people who want to stabilize (or pause) their career advancement for a period of time (e.g. more family-focused time) or even indefinitely. 

Generally speaking, up or out doesn't make sense. However, I think it might make sense for entry-level positions - namely interns and juniors. If you subscribe to this line of thinking, it is worth making this expectation clear upfront.

Juniors require the mentorship and attention of mids and seniors and, as such, represent an investment. This investment is expected to provide a return on investment at some point. If that is the case, then there should be some pressure on junior engineers to get through those early stages in a reasonable amount of time. So, I think it makes sense to set benchmarks for how long we expect engineers to stay at the intern and junior level. Exactly how long depends on the specifics of your organization. After all, junior doesn't mean the same thing in every company. It is common for juniors in one company to be considered mid-level in another. I think the reasonable starting point is to expect interns to be promoted to juniors within at most 1 year and juniors to be promoted to mid-level within another 1.5-3 years. 

If you want to ensure this is adhered to, it is worth codifying it explicitly in engineering progression. 

Time to add more career tracks?

At some point you inevitably face the dilemma - is one of the roles sufficiently distinct to build a separate track for it? A separate track might have two manifestations: 

• It’s either a separate career ladder with distinct requirements and competencies (for instance, application developer vs UX designer paths). 

• Or it can be a branch from the existing career ladder (a typical example is software engineering branching into engineering management).

These examples are high-contrast. After all, the role of a UX designer is quite different from that of a typical software engineer. One might even ask whether UX design is really engineering at all. I will leave those philosophical questions aside. The bottom line is that UX designers are typically part of the engineering organization in most companies, so they deserve a career ladder just as much as anyone else in the engineering part of the organization.

What about data engineers versus application developers? I'd say it depends on the nature of the work in your organization. It's a lot of work to build separate career ladders, but fitting square pegs into round holes doesn't really serve the overarching goals of engineering development. If it is to add value, it has to be used, and that requires sufficient buy-in. 

My quick rule of thumb is to build a career ladder for any role that affects more than 20 people in the organization (and at least consider it for roles with more than 10). If you decide to use a typical breakdown of competencies (hard skills, communication/teamwork, and leadership/organizational) for most individual contributor roles, it is likely that most of the time only the hard skills will vary significantly. The rest will remain largely the same.

It is hard to miss the point at which a separate career ladder is potentially needed. If the role is truly distinct and doesn't fit well into the existing career ladder, it's almost certain that people in that role will come to you and complain about it (which is great!). They may even suggest that they create a separate ladder for themselves (which is even greater!). If you decide that a separate ladder is worth the effort at that point, it is good to have a basic framework and structure thought out so that they can do it themselves.

In both cases (separate ladders and branching), it is worth making sure that lateral movement is possible (people moving to other departments or between individual contributors and management positions). How to do this from an organizational perspective (training, salary, position, etc.) is beyond the scope of this article, but from an engineering progression perspective, they should at least "feel familiar" with the new technical ladder they will be using (structure, organizational/teamwork skills, etc.). 

There is also a more subtle area related to career branching. In some roles, there are several possible paths of development. These are often referred to as archetypes or trajectories and become apparent at higher levels of an engineer's career. At VirtusLab, we have defined the following archetypes:

• Team Leader: The first step in a leadership career that begins with managing a single team. This is typically still a very hands-on technical role.  

• Rock: It describes a well-rounded engineer who can basically perform almost any task on a given project. They know the domain very well and are well versed in the business environment of the project. They usually spend long periods of time (many years) on a single project and tend to be the bedrock of the project, knowing it inside and out.

• Subject matter expert: This trajectory describes an engineer with exceptional depth and/or breadth of knowledge, skills, and experience in a specific area. The area may be more technical (e.g., cloud platform engineering or stream processing) or domain-oriented (technology in InsurTech or manufacturing). The impact of these engineers comes from sharing knowledge/training others internally, supporting VirtusLab's outreach (articles, presentations, panel participation, community activity), helping with pre-sales efforts, and consulting with other teams. 

• Architect: Architects are often involved in pre-sales activities or the initiation of new projects. They must be able to understand the business environment, constraints, and customer requirements. Since customers often don't really know all of their requirements, engineers in this role need to have solid experience in figuring out what the real requirements are. Typically, they spend a limited amount of time on the project (6 to 12 months) or work on it part-time - while being involved in other initiatives (either continuously or from time to time in a more consultative manner). 

• Organization engineer: Organization Engineers thrive on building engineering organizations - they are often involved in key organizational tasks. They may play a leading role in areas such as engineering progression, building VirtusLab's ways of working, redesigning the hiring process, building training for new team leaders, etc. 

At VirtusLab we distinguish these archetypes from the Staff+ level on. In our case, they don't require completely separate branches in the career ladder. They do, however, allow us to emphasize certain competencies and help guide engineering careers at a certain point. They are also specific to VirtusLab, based on our retrospective identification of notable senior engineers with different skill sets.  I would be surprised if they could be applied "as is" to your organization. Here are examples from other organizations that may give you food for thought:

• Meta – as described by Gergely Orosz – uses the following archetypes: Generalist, Specialist, Coding Machine, Tech Lead, Fixer, Systems Thinker, and Product Hybrid. 

• Flatiron Health – Cat Miller describes their journey that involved separating the Principal Track from the Architect Track starting from E6 (E6 is roughly Staff Engineer).

When promotion requires more than just meeting requirements

There is a tendency to treat meeting the requirements for a given engineering level as a sufficient condition to warrant promotion. "I've done what was required, so I should be promoted soon after" - right? While this is certainly true for some levels and perhaps even desirable for all, I don't think it's always and everywhere the case.

It definitely makes sense for the first part of the career: interns, juniors, mids, and seniors. As soon as the engineer meets the requirements, they are eligible for promotion. Things get more complex in the second part of an engineer's career and definitely in management roles. 

Let's start with a simple example and assume that our management engineering career ladder looks like this:

Almost all steps in this career are based on available opportunities. You can't really move from team lead to engineering manager if there isn't a vacancy. Granted, opportunities abound as organizations grow, but of course, constant growth is not a given. In fact, it is almost guaranteed that your organization will plateau at some point. If attrition isn't perfectly aligned with the growth rate of your people, there will come a time when even people who meet all the requirements can't be effectively promoted.

The extreme case of this example would be the CTO position. Unless the current CTO of your organization leaves (by their own choice or otherwise), you are unlikely to promote anyone else into that role.

Going back to the pure engineering (non-management) roles, I think this also applies to the Staff+ engineering levels, although it depends on your organization’s stage (hypergrowth, stagnation, contraction, etc.) and the attrition rate. Would your organization be even able to utilize a new Principal Engineer every time there's a new person, who meets the requirements? It's worth thinking about. 

The thing that helps here is that Staff+ engineers are less common than less experienced engineers. And Principals are even rarer. So, it is unlikely that the supply of these very senior roles waiting in line for promotion would become a major problem. Still, I think it is worth clarifying that meeting the requirements is not sufficient for some roles. Addressing this issue openly and upfront may save you some headaches down the road.

Next steps

That's about it. I've tried to cover a lot of the ground needed to build a successful engineering progression. It is a lot of work. Or rather, doing it right is a lot of work.

The real fun, however, starts with the rollout, building in the change process, getting buy-in, and dealing with the various outliers in your organization. This will be the focus of the third and final part of this short series, which I plan to publish in the next few weeks. If you've found this information useful, I'd love for you to subscribe to this publication. 

Until next time.

Building a world-class engineering organization isn't always plain sailing. At VirtusLab, where I wear the CTO hat, we've learned a few things along the way. This is the first of a three-part series to share those lessons and help you build an engineering progression for your organization. In this first installment, I’ll cover the case for introducing a structured engineering progression and the basic groundwork to be done ahead of implementation. In subsequent articles, we’ll explore building blocks, structure, rollout, and maintenance processes.

The context

An important part of VirtusLab's business is the efficient delivery of custom solutions for clients in various industries. The majority of these projects involve building software, ranging from proof of concepts (POC) or small components that take a few weeks to develop, up to large-scale systems that may take years to build and maintain. 

As our business grew and the number of engineering teams increased, we realized we needed to have a clearer and more consistent approach to engineering career progression. Eventually - and this was around 2017 - we decided to build one. Back then, our entire engineering team consisted of less than 50 engineers and was mostly homogenous - mainly backend engineers and a few frontend devs, all of them working in application-level development. In the context of engineering progression, it was enough to introduce something simple. 

Our first engineering career progression implementation looked like this. It was inspired by the engineering progression used in Basecamp back then (now called 37signals). We introduced it pretty much “overnight” - I wrote the initial version over the course of 1 or 2 evenings, which was followed by 2-3 weeks of review. It did the job pretty well for several years until we noticed some big cracks starting to appear.

To be fair, we got a few things right. First, we looked at our company operating model to see what skills and attitudes would help us to grow. In hindsight, the operating model seems a little naïve, but at least we made an honest attempt at doing this part of the groundwork.

And yes, we made a lot of mistakes. We mixed engineering with management, we put too much emphasis on non-core activities (mixing core work with nice-to-have activities that are more related to the culture of the company), and we blindly adopted certain roles without checking whether they were really applicable to our business at the time (e.g. Principal Engineers). Finally, we added a lot of vague, broad statements that could easily be interpreted in different ways.

In 2023, we started rebuilding the engineering progression framework. By then, the company had grown from 50 to 400 employees and was way more diverse.

So, that’s the context. Let's move on to the main part.

The basics

What is an engineering progression framework? In essence, an engineering progression is a career ladder for engineering roles within a given organization. From a high-level perspective, it is a roadmap for an engineering career designed to help both engineers and their managers navigate their career paths over the years. From a low-level perspective, it covers a set of required skills and expectations to be met at a given level of seniority. In addition, it more or less directly indicates the engineer's salary.

Do all companies need an explicit engineering progression framework?

No. Not all companies have or need an engineering progression framework to function well. There are two kinds of organizations that typically don't need an engineering progression framework.

Small organizations tend not to have an explicit framework for engineering progression. They typically rely on salaries and responsibilities being discussed directly between the engineer and the employer (usually represented by the CEO or CTO). Typically, salaries and responsibilities are discussed directly between the engineer and the employer. This informality makes sense for small teams (a few dozen engineers) due to two factors:

1. Limited processes: Most small but growing organizations lack many of the processes and standardization that take shape as the company matures. This is usually due to working in a restricted environment (resources - including attention - are scarce). Growing companies have a lot to juggle, and whatever they can postpone in exchange for prioritizing product-market fit should usually take precedence. 

2. Direct communication: Due to their size, the best communication channels are direct and verbal. This is feasible and efficient in an organization of 20-40 engineers that can be run directly by top management, often the founders themselves.

The other example of organizations that get away without implementing a structured engineering career ladder are flat organizations. Flat here means that all engineers are treated the same (in terms of expectations & compensation) - they don't necessarily have to be flat from a management perspective (e.g. contrary to the Valve example - see page 4 of their employee handbook). Netflix is a notable example of a flat organization at the engineering level. But what does having a flat engineering structure mean in practice? If the level of expectations & compensation is roughly the same for everyone, it must mean that you need to hire very senior engineers. The alternative, i.e. hiring only junior engineers, doesn't seem to be a sustainable solution in the long run 😏. Few organizations, outside of the hottest Silicon Valley startups in ZIRP times, have the luxury of doing this. And, let's face it, a lot of the work in many technical organizations can be done by less experienced engineers, who, of course, cost less and are easier to hire than seasoned seniors.

Why most companies should eventually adopt an explicit engineering progression

Interestingly enough, even Netflix eventually ditched the flat engineering-level concept circa 2022 (which is covered neatly by Gergely Orosz in this post). It's pretty remarkable that Netflix, a huge tech company, managed to keep flat engineering for so long. By 2022, they'd been around for over 20 years and had grown to about 2,000 engineers. It seems that the reasons for the shift were similar to those that often drive companies to adopt an engineering career framework.

Those reasons are:

• Most organizations need to have a mix of seniority levels.
  Sometimes this is a conscious decision. The organization recognizes that not all types of work require top-level expertise, or it recognizes the benefits of mixed teams, which is well described here by Luca Rossi. Or it's forced on the organization by economic factors, cost constraints, or talent availability issues.

• Organizations grow beyond 40-50 engineers.
  This is typically the size at which direct communication stops working. It's no coincidence that this number roughly corresponds to Dunbar's circle of best & good friends. Beyond that point, not only does communication become more difficult, but decisions about promotions, compensation, and hiring become less centralized. In organizations that are growing rapidly and hiring is (for lack of a better word) hectic, the need to be explicit about expectations is all the more important.
  Finally, as the organization grows, hiring decisions are made by someone who may not even work directly with the founders, and the greater the distance between them, the more important it is to codify the career progression.

• Providing a sense of accomplishment or career progression.
  From a psychological point of view, many professionals need a sense of career development; a progression in other words. This is confirmed by many studies over the years (as well as popular science books such as Daniel Pink’s Drive), where financial motivation is only part of the equation. This is a challenge in organizations with a flat engineering structure. Some organizations try to get around this by offering some sort of progression based solely on the length of time someone has been with the company. However, this provides a financial increase in compensation and not necessarily a sense of career advancement. It also penalizes the experience of people who've had diverse careers prior to joining the company. In reality, as the company grows, it becomes increasingly important to leverage diverse experience backgrounds and outside perspectives. This is difficult to do if your advancement is based solely on years with the company.

• Organization becomes more organized.
  It is worth emphasizing that not every small organization (<50 engineers) is in a continuous growth mode. In fact, it's not necessary in every case, and there's no hard and fast rule that says it should be. I'd say that the perceived need for continuous growth has done as much harm as good over the past decade. Many companies can, in fact, run a solid business with a fixed number of employees (even if that is not what the media likes to tout). A company can mature in its processes even if it remains relatively small. In such cases, I’d argue that implementing a proper engineering progression is a useful thing in itself. Since an engineering progression usually has to start with a deeper understanding of the values and needs of the engineering organization, it is likely to force the organization to at least think about these issues. It can also lead to a non-trivial employer branding tool - allowing for a better employee-employer match but also improving how candidates pre-select themselves to apply to certain organizations (you can see good examples on progression.fyi ).

Given all this, let's think about how we can start putting together an engineering progression for your company.

Things to be clear on before building your engineering progression

First things first: You cannot design an effective engineering career framework without first thoroughly examining and understanding your organization. These are the key points you need to understand:

Values & culture of your organization
Every organization is different. Some keep the quality bar aspirationally high (they tend to focus on bugs first, for example). Others value getting things done quickly and iterating from there, while others emphasize business results, and still others focus on performance (either efficiency in resources or speed). With so many different types of companies and niches relying on software engineering, there are many approaches that can work. The tech department of a large European utility company will likely have a different culture and values than a mobile app startup or mid-sized consulting firm in the US fintech sector.
Whatever culture your organization has chosen (or rather, however, your organization has evolved over time - because you don’t always really choose culture), it’s absolutely essential that you take it into account and bake it into your engineering progression.

The nature of work
As with values & culture, here also, every organization is different. Much of the nature of your work comes from the organizational values & culture that have grown over the years. But there are also other factors to consider:

• Product or professional services focus. This is perhaps the starkest difference you’ll see between organizations. In professional services firms (including consulting firms), engineers tend to be much more involved in client interactions. They are typically client-facing, often work hand-in-hand with client teams, and typically place more emphasis on communicating, courting, and nurturing clients, especially at higher levels of employee seniority.

• Type of customer. One axis might be B2B vs. B2C. Another might be the type of customer segment (e.g. finance may leave a different footprint on daily work than the advertising industry).

• Regulations/mission-critical systems. Working on peripheral systems (e.g. side LLM/RAG search module for social media platform) will likely require a different approach than working on core/mission-critical systems (e.g. software to run a nuclear plant). One might favor bleeding-edge experimentation, move-fast-and-break-things, the other might require a cautious approach, relying on boring-but-proven technology, extensive testing and validation, and shitloads of documentation.

• Maturity of your business. The same company might value different things at different stages of its life (e.g. pre-market fit vs. post-market fit).

These are only a few contrasting examples. There are others to consider. The bottom line is that you need to understand the nature of your business and how it affects the engineering organization.
Most of these will move your organization toward different expectations of engineering work, so it is critical that you strike the right balance in your engineering progression. Ultimately, you want to have a progression that rewards (promotes) people who demonstrate attitudes that are aligned with the work your organization does. This leads us to the final point.

Existing issues & direction of the travel
Few organizations stand still, and even fewer stay relevant without constant evolution. As one wise Greek once said, "The only constant in life is change”. This is especially true in business. Change can be internal (the organization moves through its maturity stages) or external (the market shifts). The cause of the change doesn't matter - what matters is that your organization needs to adapt. This often means changing attitudes and behaviors. Even more disruptive is when existing attitudes aren’t the ones needed to move the needle in the future.
In extreme cases, this may mean letting go of some of the key people - yesterday's heroes. More typically, it means that a company-wide realignment is needed. And for any large organization, it is not enough for leaders to just talk about it. It has to be embedded in the organization in a systematic way (affecting 1-1s, promotions, and improvement plans). In other words, it has to be part of the engineering progression ladder.
Organizational debt is also a common cause of drift in engineering characteristics. A debt that an organization acquired, either by being casual about certain values (which may indicate poor leadership) or by growing significantly due to a rare market opportunity - an opportunity that had to be seized before it disappeared. In such cases, organizations may have deliberately relaxed their hiring standards or attention to some of their values. It is likely that the market opportunity will end at some point, and the organization is left with an organizational debt. Perhaps some people were green-lit to hire engineers who wouldn’t have been hired otherwise. Or maybe some people were promoted to certain levels of seniority who otherwise wouldn’t be. Or, worst of all, some people have been promoted to leadership positions who wouldn’t normally meet the criteria for such positions.
Eliminating debt in one or two quick moves is not something most organizations have the luxury of doing. Instead, they must readjust gradually and painfully. Again, engineering progression is your way of codifying such changes (e.g. modified or elevated expectations) for certain roles. This leaves the question of what to do with people who no longer meet the requirements for certain positions. There are a number of options, but I'll cover them in the article on implementing engineering progression in your organization.

Depending on how clearly these areas are defined in your organization, doing this groundwork may be as simple as summarizing what is already defined, or it may involve weeks or months of intense debate. The latter would probably be ineffective, but you need to at least cover some basics in these areas. It will not do you any good to skip this stage altogether.

Leadership Management vs Engineering

The topic of individual contributor and management pathways is so relevant and worthy of consideration that it must be thought through in advance. Especially since it requires thinking about how to design and incentivize your entire organization. 

Companies typically divide engineering career growth into at least two broad categories: leadership vs. individual contribution. Personally, I think this is a false dichotomy for most companies. For many organizations - perhaps with the exception of the most prestigious big tech companies - a pure individual contributor career without a leadership aspect is very shallow. It usually ends somewhere around the senior engineer level. What happens beyond that depends on the nature of the company. The name is usually Staff or Expert Engineer (apart from acronyms like E6 that some companies use). However, the nature of the role can vary between companies and even between individuals. Will Larson names the following archetypes for Staff Engineers: 

• Tech Lead - leads the execution of an engineering team.

• Architect - responsible for technical architectural direction.

• Right Hand - assists senior leadership in navigating particularly complex problems/organizations.

• Solver - expert in a particular domain or set of problems.

This is very close to some real-world examples. Meta is one such example. (Gergely Orosz covers this aspect of Meta extensively in his article "Inside Meta’s Engineering Culture"; it is behind a paywall, but it is definitely one of those rare online publications that are worth paying for). 

The thing here is that out of these archetypes (or trajectories), most include an element of leadership. This is obviously true for Tech Lead or Right Hand, and perhaps less obvious for Architects. However, the days of architects with long gray beards descending from the heights of their ebony towers with intricate UML scrolls are pretty much over in most organizations. Today, the role of the architect is much more hands-on and collaborative and requires significant social and leadership skills. The leadership aspect is probably the least required for the Solver archetype. However, it's worth noting that in many organizations, all Senior+ roles are expected to pay a lot of attention to developing and mentoring others around them, which is an important part of most definitions of leadership.

The bottom line is that leadership, in one form or another, is required in both engineering career paths. So, my personal preference is to talk about management (or maybe even people management) instead of leadership. Some companies also recognize it as Manager vs. Maker (echoing the vibes of PG's famous essay: Maker’s schedule, Manager’s schedule). I like this distinction, too.

While the above point may be perceived as more philosophical, there is another important point regarding the ladder structure. It's now well understood that the move into management should not be a "promotion" in the classical sense, but rather a lateral move from a pure individual contributor role. Clearly, setting up the system to make management more lucrative tends to encourage good engineers who have neither the inclination nor the talent for people management to move in that direction. Ultimately, this is detrimental to both the individual's career and the organization as a whole, so it is better to remove this incentive as much as possible.

The elephant in the room, however, is that in most organizations (again, with the exception of big tech), the individual contributor path is shallower than the management path. This seems to be a fact of life for many companies - both from the perspective of organizational impact as well as paygrades (in short, VPs have more impact and are paid more than Staff or Principals). I’d argue that this - to a degree - actually makes sense for most organizations. You can see the differences illustrated in the Exhibit A below:

The diagram on the left is marked as questionable. It isn’t healthy to have a completely separate path for engineering management. Ideally, new Team Leads or Engineering Managers have some hands-on experience. Whether that experience branches out at the level of Mid or Senior is probably up for debate, and the needs of each individual organization, but making it parallel from the Junior level is likely to be suboptimal to the entire organization. 

The diagram in the middle shows a workable scenario for most technical organizations: 

• It branches from a Senior individual contributor role (and therefore requires a solid understanding of the craft itself).

• It allows for parallel development over a significant period of time (although it clearly shows that the Management role can go further).

The diagram on the right shows an anti-pattern (at least for the organization that claims to be a technical organization) - where the individual contributor’s path is very short, and the organization strongly incentivizes the movement from individual contributor to management. This incentive will ultimately be detrimental to the organization.

So, we can see that there are some key guidelines:

• There should be a separation between pure engineering and management paths.

• Management (at least at some level) shouldn't be the only way to advance an engineering career beyond senior positions. 

• You want to make sure that individual contributor and management paths are at least reasonably balanced. 

That’s it, what’s next?

So, we’ve now explored both the organizational need and the groundwork to put in place before building your engineering career progression.

A quick recap. Keep the following in mind before you start working on your engineering progression:

• Review communication and size to determine if your organization really needs an engineering progression.

• Get clarity on your organization’s culture. You’ll want to bake this into the progression.

• Consider the types of activities and ways of working that are used. Identify the one you most want to instill.

• Assess the existing organizational issues (e.g. org debt) and the direction of the travel so you can build it in.

• Make sure you balance individual contributors and management paths.

Once you've laid the groundwork, it's time to move on. Part 2 explores the artifacts, materials, and approaches to use in building your progression. Part 3 covers the process of rolling it out and optimizing it within the organization.

I’ll follow up with the next installments in the series in the upcoming weeks. In the meantime, don’t hesitate to comment or get in touch. You can find contact details on my About Me.

My name is Pawel Dolega, and I am the CTO at VirtusLab, a consulting and software development company that works with both small and large (FTSE100 & Fortune 500) companies. I've been in various technology leadership roles since 2012. You can read more about me in my bio.

In a post-ZIRP world, software organizations are changing, and with them, the entire software technology industry is maturing. Having been in the industry for roughly 20 years, I can see the shifts happening with my own eyes. I've experienced both highs and lows. I have successfully led some projects and teams, and failed with others. Both have taught me lessons and I have the scar tissue to prove it.

In this corner of the internet, I will cover topics ranging from organizational design to the technology landscape to leadership reflections - including comments about current trends in the tech world - as they relate to tech leaders.

My purpose here is threefold.

First, I see we already have a lot of material on technology leadership. However, a large chunk of it comes from lessons learned in Big Tech or hot Silicon Valley startups. While these lessons are undoubtedly valuable, there is a non-negligible difference between a hyper-growth payment scaleup based in Silicon Valley and a larger group of companies that might include: a 1000-engineer utility tech division or a mid-sized insurance company with a tech department or a self-funded European tech consultancy. Some lessons are transferable, others less so. Interestingly enough, the latter group is much larger than the former. I believe the insights I can contribute in this area will be valuable.

The second reason, and a more selfish one, is my personal learning. Past activities - both successes, failures, and all the things in the middle - are great teaching moments. However, when we talk about challenges we encounter in leadership, they are rarely related to just learning new factual information. We struggle mostly with perceptual discrimination or rebuilding mental models. To learn to deal with such problems, it is not enough to only do something. Sure - it is crucial to have practical experience (necessary condition), but to grasp and internalize the lessons fully - there needs to be a synthesis phase. A reflection. To quote John Dewey: “We don’t learn from experience. We learn from reflecting on experience.” For me, the best way to do this is to structure my thoughts in written form. Then the next step is to confront different perspectives. I hope this publication will help me with both of these steps.

Finally, I am eager to connect with other tech leaders facing similar challenges. Throughout my career, I've come to understand that while the solutions may be different and specific to each organization, the underlying challenges are often similar. Whether it's managing rapid growth, navigating complex technology landscapes, or fostering a culture of innovation, many of us can relate to these common experiences. So let’s talk. Feel free to reach out to me here, on LinkedIn, or on Twitter/X.

Stay tuned!