Tracks, and the Skill Ceiling

Overview

Two questions people conflate. One is which track to be on. The other is why progress stops — and the second has an answer that is unwelcome and useful.

The ceiling is a skill ceiling

The common framing is a glass ceiling: a limit imposed from outside, on title or compensation. Occasionally that is what it is. Far more often the limit is internal, and the diagnosis is specific:

Learning new technologies without changing the substance of your work is how people plateau.

The pattern is easy to recognise once named. An engineer learns a new language, then a new framework, then a cloud platform, then an orchestration tool — five years of genuine, effortful learning. At the end they are qualified to make exactly the same class of decisions as at the start, with a longer list of tools for making them.

That is horizontal motion presented as growth, and it is unusually hard to see from inside because it feels like work and the learning is real.

The diagnostic is the class of decision you are trusted with, not your title and not your salary. Two years ago, which decisions came to you? Which come now? If the answer is the same kind of decision with different technology attached, the ceiling is skill rather than circumstance — and more technologies will not lift it.

Vertical motion looks different: from “how should this be built” to “should this be built”, to “what should we build instead”, to “what are we accountable for”. Each step is a change in the kind of question, and in how much is unwritten.

graph TD
  A["<b>Horizontal</b><br/>new technologies,<br/>same class of decision"] --> C{"Has the class<br/>of decision<br/>changed?"}
  B["<b>Vertical</b><br/>how → should →<br/>what instead →<br/>accountable for"] --> C
  C -->|"No"| D["<b>A skill ceiling</b><br/>more tools<br/>will not lift it"]
  C -->|"Yes"| E["Growth"]

  classDef h fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef v fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef q fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef bad fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A h
  class B,E v
  class C q
  class D bad

One question separates five years of growth from five years of lateral movement.

The technical track

A rough progression: senior engineer, then tech lead or staff engineer, then solution architect, then — for some — a CTO or equivalent position. Will Larson’s Staff Engineer is the best map of the rungs below architect, and Hohpe’s Elevator of the one above.

Two things worth being precise about.

The steps are changes in scope of accountability, not in seniority of implementation. A staff engineer is not a better senior engineer; the job is different work. The transition that defeats people is the one where producing excellent technical output stops being the contribution and enabling other people’s output starts being it — and the feedback on the second is much slower and more ambiguous.

The architect position is where unwritten constraints dominate. Everything in Module 8 and the first half of this module was this: the decisions are shaped by capacity, politics, history and accountability rather than by technical merit. People who are excellent technically and unhappy in the role are usually reacting to that shift accurately — it is a real change in the nature of the work, not a failure to adapt.

The management track is underestimated

Not harder in some absolute sense. Harder than people expect, for reasons that are structural:

It is a different job, not a promotion. The skills that made someone an excellent engineer — deep focus, direct problem-solving, personal output — are largely not the skills of the new role, and some are actively counterproductive. Camille Fournier’s The Manager’s Path is the honest account of what the job actually involves.

You lose the thing you were good at. This is the under-discussed cost. Technical ability decays without practice, the decay is quick, and the path back narrows every year. Treating the move as reversible is usually a mistake.

The feedback loop is years long and confounded. Did the team do well because of your management? Partly, and partly not, and you will never isolate it. People who depend on clear feedback find this corrosive in a way they did not anticipate.

And the common reason for taking it is the wrong one. Moving to management because the technical track appeared to be out of room usually means the ceiling was a skill ceiling — in which case it travels with you.

The honest version of the choice: the technical track asks you to keep raising the class of decision you can own; the management track asks you to make other people’s output your output. Both are real careers. Neither is a promotion from the other.

Four weeks in, and the decisions that arrive

A trajectory check on the role in this guide, using the diagnostic rather than the title.

What the title would suggest. Solution architect for the AI initiative at a company of about 320 people, 140 of them engineers. On a career ladder that reads as a step up from senior engineer.

What the decisions actually were. Not one of the guide’s central decisions was technical in the sense a senior engineer would recognise. Whether the initiative’s target was achievable at all — a question about arithmetic and business constraints. Whether to delegate action-taking, which was a blast-radius and accountability question. Whether an evaluation threshold meant anything, which was statistics. How to sequence work when there is no capacity, which was organisational. Whether a dependency described as interim would last four years, which was division.

The technology choices — hosted inference, retrieval over fine-tuning, a vector store — were real and were the fastest decisions in the guide. They are the ones a catalogue answers.

So the class of decision changed, and that is the diagnostic passing. The questions arriving are should this be built, what are we accountable for when it is wrong, and what do we deliberately not do — a different kind of question from how should this be built, and the shift is visible in what the workbook exercises ask for.

Where the ceiling would show up instead. Suppose the same four weeks had produced a thorough evaluation of six vector databases, a benchmark of four embedding models, and a well-engineered orchestration layer — genuine work, real learning, and the same class of decision as a senior engineer makes. The initiative’s central problem, that the deflectable share is a property of the documentation corpus rather than of the technique, would have gone unexamined. That is the horizontal path: further along, no higher, and the question that mattered never asked.

And the thing this role cannot do. It carries accountability for an initiative without authority over the engineers who would build it, the security lead who can block it, or the principal engineer whose review it needs. That is not a defect to be fixed by a better title. It is the job, and the preceding four modules were about operating inside it.

Feeds the workbook

This frames your 12-month roadmap. A roadmap that lists technologies is horizontal by construction; one that names the class of decision you intend to be trusted with is not.

→ That is the shape of the work. Now the titles being advertised for it. — Emerging roles, and reading a title