Engineering brief

The CTO path now runs through shipping code, not managing process

The Pragmatic Engineer3 min read · saves 113 min

At a glance

The brief is enough

Relevance
Practical value
Radar
Time horizon
Now
Warnings
None

The 2010s told managers never to make technical decisions. Will Larson says that era is over: middle managers who don't get back into the details are the new risk, and line managers with domain context may be the better future CTOs.

Management playbook from the zero-interest-rate era no longer works; leaders must reskill or lose relevance.

Watch if you are a middle manager or senior IC deciding whether to reskill into hands-on work.

Summary

The 2010s management ethos told engineering managers to never make a technical decision again. Will Larson says that era is over. At Stripe he told senior engineers asking for interesting work: "I only have suffering to offer," meaning business-critical problems, not glamorous projects. Back then that looked like bad management; now solving what the business needs is the default path to stability and promotion. The zero-interest-rate era rewarded retention, perks, and headcount growth, and managers became people-pleasers. That world ended.

The CTO mix. Larson describes the CTO role as two capabilities: a strong technologist and a bureaucrat who can run a function, even one they do not deeply know. The old career path through middle management selected for bureaucratic skill and let technical judgment decay. He argues line managers often have better instincts than middle managers because they live in the details. Larson acted on this: he left a 250-person Carta organization to join 25-person Imprint and wrote over 500 pull requests in eighteen months.

The reskill mandate. Middle managers face a hard choice: get back into technical detail or accept that their skills may lose value within a few years. Larson's blunt framing is "am I retiring or reskilling?" Tools for line management and writing software are improving; tools for headcount planning and performance reviews are not. He suggests lateral moves, even a step down, can be educational. The industry's rules changed after a stable decade, and people who came up in that stability feel betrayed.

The org design point. Durable high-ownership teams are the only way to scale, but they look wrong optically. The alternative is running people to the latest fire, which works until there is a crisis everywhere. At Stripe he shifted from a "defend the castle" model to pods that own areas, and stopped managing them until something broke. Slack shows this: its agents integration shipped because the owning team had domain context while competitors did not respond. Domain knowledge compounds when teams stay intact.

The ladder caveat. Career ladders still matter for fairness, but detailed rubrics get gamed. At Carta, cost pressure led him to impose a hard staff-engineer ratio, a constraint that forced more junior hiring and a real pipeline. At Imprint, the goal is velocity, so the ratio would not make sense. The staff-plus signal is still decision-making in ambiguous situations, not raw coding. Agents can make code easier, but they do not carry the implicit context and tradeoffs that live outside the context window.

My take

I think Larson is right that the rules changed, but I'd be careful turning 'managers should write code' into a new universal mandate. Managers who disappear into delivery can lose the team's trust and the organizational view. The useful version is selective reskilling: every EM should be able to read code, challenge architecture, and make technical tradeoffs, not necessarily ship 500 PRs a year. The stronger signal is his org design point. Durable ownership teams are unpopular because they look passive in a crisis, but they compound domain context. I'd put the middle manager advice in the same box. There is still room for people who run process well if they also own technical outcomes.

What to do with this

  1. Ask each engineering manager to name one business-critical problem they will personally work on with code this quarter.
  2. List staff and principal engineers and check whether they are assigned to company-critical problems or only interesting projects.
  3. Pick one team that keeps getting rotated to fires and define a durable ownership boundary for the next six months.

Watch the video

This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.

Related breakdowns

Get TL;DW

Too Long; Didn't Watch.

A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.

Free. Weekly. No hype.

Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.