Lesson 3 said your output is your organization’s, and that doing the work yourself has a leverage of about one. That argument is correct and it is not the whole story, because technical credibility is a real asset that decays on a clock. This lesson is about the clock, and about what an executive does instead.
Charity Majors’ argument is that the strongest technical leaders do not pick a lane. They swing between engineering and management across a career.
Her specific claim: the best frontline engineering managers are never more than two to three years removed from hands-on work. Past that window, technical credibility and context decay significantly. The CTO in the scenario is at four years and arguing about a system that has moved twice.
The reason you cannot solve this by doing both at once is about working conditions, not effort. Management requires being available for interruptions. Deep engineering requires blocking them out. Those are opposite settings on the same dial, so you can only really improve at one at a time. Splitting your week does not buy you half of each.
She has a second claim, and it is the same one lesson 1 made about the CTO title, one level down: management is not a promotion. It is a lateral profession change where you restart as a junior. The promotion myth traps people who dislike the work inside it, and it drains the pool of senior engineers available to mentor anyone.
Here is where the lesson has to be honest. Majors is writing for frontline managers and senior individual contributors, and for them the pendulum is directly actionable. Swing back. Take an IC role for two years. It works.
An executive cannot do that without leaving the job. And lesson 3 explains why the cheap version does not work either: your output is your organization’s output, so an afternoon of your own coding converts a large multiplier into one unit of work.
So the executive question is narrower than Majors’ question. Not how do I stay an engineer, but what is the smallest set of practices that keeps my model of the system accurate.
Larson gives a concrete list, framed as things to do while learning a new organization. They work just as well as an ongoing practice.
Ask where the tools steal time. Go to the people working in each technology stack and ask how well the tools serve their needs, and where the rough edges are. This is a question about their experience, which you cannot get wrong, rather than about the architecture, which you can.
Learn how high-impact technical decisions get made. Some companies have architecture groups or technology reviews. More rely on informal mechanisms. Study which one you actually have. This is usually more surprising than the technology.
Build a trivial change and deploy it. Shepherd something small all the way to production. The point is your mental model of how development works here, not the change.
Do an on-call rotation, carefully. Add yourself as an additional page target. Larson is explicit that you probably do not have the context to help in an incident, so the goal is to feel the experience, not to be the responder. That distinction is what keeps this from being a costly performance.
Attend incident reviews. These meetings and their reports are a uniquely valuable source of learning, and they are the one place an organization talks honestly about how its systems actually behave.
Record the technology history. Not a verdict on it. Larson’s line is that most bad decisions today were great decisions within a context that no longer exists. Write down what those contexts were, for yourself and for every future hire.
Document the implicit technology strategy. Surprisingly few companies have a written engineering strategy. Write down what you find, share it back, and ask whether this is the strategy the team wants. Lesson 8 turns this into a real technique.
Every item on that list shares two properties. None of them needs uninterrupted focus, so none of them collides with the management half of the dial. And none of them takes work away from someone whose job it was.
Larson names the biggest technology mistakes for a new executive as having too many opinions, and lacking genuine curiosity about the rationale behind existing decisions.
The first one has an asymmetry worth stating plainly. It is relatively low impact for an early career engineer to hold too many opinions, because people take them with a grain of salt. Nobody takes an executive’s opinion with a grain of salt. So the same habit, unchanged, becomes thrash, and Larson notes that executives from an engineering background often have not trained themselves out of it.
That is Grove’s negative leverage from lesson 3, arriving through a specific door. The CTO in the scenario was not being reckless. He was doing exactly what he did as a staff engineer, in a chair where that behaviour has a different multiplier.
Stay close enough to the system to know when you are wrong. Stay far enough from the work that your being wrong is cheap.
The practices above buy the first. The habit that buys the second is holding your opinions at the weight the room will actually receive them at, which is heavier than you think.
The next track starts on your first ninety days, where every one of these practices has a place, and where restraint stops being advice and becomes the deliverable.
Source: Charity Majors, 'The Engineer/Manager Pendulum', charity.wtf (2017)
Answer to reveal the explanation. Nothing is scored.
1A CTO blocks Friday afternoons to work on a real feature, and keeps her Slack open for her team throughout. Why does Majors say this fails?
Majors' claim is about working conditions rather than willpower or hours. You can only really improve at one of these at a time. Splitting the afternoon does not give you half of each; it gives you interrupted engineering and distracted management, and you get worse at both.
2What does Majors mean by saying management is not a promotion?
The myth that it is the next rung traps people who dislike the work in it, and drains the pool of senior engineers who would otherwise mentor. This is the same claim lesson 1 made about CTO not being the top of the technical ladder, one level down the org chart.
3Why does Larson suggest adding yourself as an additional page target rather than taking a real on-call shift?
The distinction matters. Taking a genuine shift you cannot serve makes you a liability during an outage and makes the exercise about you. Being an extra page target costs the team nothing and gives you the one thing you actually need, which is the felt experience of the rotation you are deciding budgets about.
4An executive from an engineering background gives quick opinions in design reviews across four teams. What is the cost?
Larson names this as the biggest technology antipattern for a new executive, alongside a lack of genuine curiosity about why past decisions were made. Early-career engineers can hold too many opinions cheaply because people discount them. Nobody discounts yours any more, so the same habit becomes Grove's negative leverage with a title attached.
5Which of Larson's practices is aimed specifically at making you slower to judge past decisions?
His line is that most bad decisions today were great decisions in a context that no longer exists. Writing down what those contexts were gives you, and every future hire, something better than a verdict. It also removes the main reason a new executive loses the room in month one.