The Truth About Becoming a Manager — It Is Not a Senior Engineer With Meetings Added

Introduction — What the Fourteen "Truths" Have in Common
The Output Function Changes — Grove's Equation
Three Reasons Personal Throughput Stops Working as a Metric
The Feedback Loop Gets Slower, and Harder to Read
Three Failures That Repeat in the First Six Months
Look for the Numbers and There Are Almost None
How to Judge Whether to Go Back to IC
Closing — Accepting "Not Knowing Whether You Are Doing Well" as the Default
References

Introduction — What the Fourteen "Truths" Have in Common

On July 29, 2026, an item titled "The truth about being a manager" went up on GeekNews and collected 41 points. The original is The truth about being a manager, written on June 21 by an individual blogger named Sofia Kodar, and two days after that, on June 23, it was posted to Hacker News, where it gathered 113 points and 64 comments.

It is worth being clear up front about what kind of piece this is. This is not research but a personal-experience essay. There are no statistics, no cited papers, no samples. The only evidence is the background the author states about herself (roughly eleven years of management experience), and there is no way to verify that background from the outside. So the word "truth" in the title is best read as meaning the author's truth.

Even so, the fact that pieces like this repeatedly climb to the top is itself information. Lay the fourteen items out side by side and most of them are saying one thing from different angles — you are no longer part of the team, an offhand remark gets read as an order, it is lonely, you carry information you cannot share, progress is no longer visible day to day. This is not a story about the workload going up. It is a story about the kind of work changing.

The original does not explain why that happens. This article explains the structure. Becoming a manager is not a matter of stacking meetings onto the senior engineer role; it is a matter of the output function itself being swapped out. And most of the side effects of that swap come from a single cause — the feedback loop gets slower, and harder to read.

The Output Function Changes — Grove's Equation

The definition Andy Grove sets out in the managerial leverage chapter of High Output Management is simple. A manager's output is the output of his own organization plus the output of the neighboring organizations under his influence.

What actually matters in this definition is not the right-hand side of the equation but the distinction that comes before it. Grove separates activity from output. Getting through eight meetings and making twelve decisions in a day is activity. Output is what that team put out that quarter. The two are correlated but not the same, and even the direction of the correlation is not self-evident.

As an IC you barely need this distinction, because the distance between activity and output is short. The activity of writing code leads to the output of a merged change within hours to days, and the number of other people who intervene in between is small. The moment you become a manager, people and time wedge themselves into that gap. The output of the 1:1 you held today shows up not this quarter but next, and by way of someone else's hands.

This gives us the first practical conclusion. To judge whether you are doing well in a manager role, you do not throw away the metrics you used as an IC — you have to understand why those metrics misfire.

Three Reasons Personal Throughput Stops Working as a Metric

The way you assessed yourself as an IC was mostly personal throughput. What did I merge this week, how many incidents did I close, how many design docs did I write. For a manager this metric breaks for three reasons.

First, it is in direct competition. Keeping personal throughput up means cutting into the time that goes toward producing the team's output. Push the 1:1s, hand off the hiring interviews, defer the coordination with the neighboring team, and this week's personal throughput holds. In Grove's equation, you are shaving the right-hand side in order to protect the left.

Second, the team's total learning goes down. The work a manager takes on directly is usually the hardest, the most interesting, and the highest in learning value. When a deadline closes in and the manager takes that work, they are a hero in the short run, but the person who should have learned from it does not learn. Camille Fournier pointing to holding on to technical decisions instead of delegating them as a common failure of new managers is the same point (though I was not able to verify the body of that piece directly, only the title and the gist).

Third, you become a bottleneck. A manager with high personal throughput creates paths that depend on their own approval, their own review, their own knowledge. Those paths reveal themselves the moment the manager goes on vacation.

Lay the span-of-control numbers over this and the picture gets sharper. In Sizing engineering teams (July 14, 2018), Will Larson puts the ceiling on what a manager can actively coach and coordinate at six to eight people. Above that, past roughly eight or nine, he writes that the manager's role shrinks from coach to "a safety net for when something goes wrong." In the other direction, he sees fewer than four as closer to a collection of individuals than a team. What these numbers describe is not the shape of the org chart but a time budget. The range of six to eight is close to the result of dividing the time active coaching requires into the hours of a work week, and personal throughput comes straight out of that same budget.

The Feedback Loop Gets Slower, and Harder to Read

Here is where the common cause of all those side effects sits. Put in a table, it looks like this.

Axis	IC	Manager
Unit of output	A merged change, a recovered outage	What the team put out over the quarter
Feedback latency	Minutes to days (CI, review, deploy)	Weeks to quarters (the result of a hire takes half a year, the effect of a reorg takes a year)
Readability	High. If the test is red, you were wrong	Low. No way to tell whether the team runs well because of you or because good people happened to be gathered
Failure signal	Arrives immediately, automatically	Arrives late, and usually only through a person
Cost of correction	Low. Just revert	High. Trust does not roll back

The most important row in this table is readability. If latency were the only problem, you could wait it out. The real problem is the signal-to-noise ratio. Into a team's results go the hiring market, the product direction, the state of the neighboring teams, and plain luck, all mixed in alongside the manager's contribution. So there is no guarantee that a good quarter is evidence of your skill, and no guarantee that a bad quarter is evidence of your fault.

Learning is a function of the feedback loop. When the loop runs on quarters and the noise is large, supervised learning effectively does not happen. This gives the second practical conclusion. A manager's growth does not occur spontaneously. You have to build the instrumentation yourself. Concretely, three things help.

A decision log. Leave one line on what you decided, when, on what grounds, and what result you expected. Comparing predictions against outcomes at the end of the quarter lets you isolate the bias in your own judgment out of the noise.
Leading indicators. Quarterly results arrive late, but things like how fast bad news travels upward in 1:1s, how quiet the on-call handoffs are, and whether dissent shows up in design reviews are observable week to week.
An outside observer. The cheapest way to read a low-readability signal is to ask someone who sees the same organization from a different angle — a peer manager, a staff engineer — on a regular basis.

Three Failures That Repeat in the First Six Months

The failure modes that recur across the original's fourteen items, the HN comments, and the widely read management literature converge on roughly three.

You cannot let go of personal throughput. This is the most common. You write the code yourself to plug the gap late in the sprint, you handle the hard incident yourself. As the previous section showed, this is a trade of short-term gain against long-term loss, and the problem is that the loss side of the trade only becomes visible six months later. The very fact that the feedback loop is slow is what lets this failure survive so long.

You misjudge the weight of your words. This is the part of the original I think is most precisely right. As an IC, "isn't this a little odd?" was a question; the same sentence from a manager comes back as a two-week refactor. Not having intended it as an order is no defense at all, because this is not a question of the speaker's intent but of the listener's risk calculation. The practical fix is to label the intent — it is better to state every time that you are thinking out loud and this is not a decision, or that this is a decision.

You put off the hard conversations. If you do not name a performance problem in the first quarter, it gets harder to name in the next. The longer the silence, the more it lands on the other side as an abrupt notice, and at that point it becomes a problem of process regardless of whether the content was justified. The point Camille Fournier makes in I hate manager READMEs (November 23, 2018) applies here directly. Trust is not built by a document introducing yourself; it accumulates as predictable and ethical behavior repeats. Having the hard conversation on time is part of that repetition.

The HN comments also carried several counterarguments to the original, and three of them are genuinely worth keeping. One comment flatly opposes the original's claim that a manager has to "sell" bad decisions, pointing out that a transparent manager ends up earning more trust, and that the people on the receiving end of fake positivity can tell. Another holds that the boundary the original draws between IC and manager is sharper than it is in reality, since senior ICs carry nearly the same burden of meetings, stakeholder management, and leadership without authority. A third says that with experience it becomes possible to balance hands-on work and leadership, and points to the risk that the original scares good candidates away.

Look for the Numbers and There Are Almost None

The number cited most often on this topic is "60% of new managers fail within 24 months." It usually comes attached to CEB (now Gartner). While writing this I went looking for the original report, and neither the year nor the sample nor the methodology could be confirmed. Dozens of outlets and blogs cite it, but they are all citing each other, and there is no link that leads back to an original. It is safest to treat it as a zombie statistic. The Leadership IQ figure of 46% that often gets cited nearby is a real survey, but its subject is new hires in general, not new managers, so it cannot be carried into this context as is.

There are, on the other hand, things whose source is clear. DDI's Global Leadership Forecast 2025 is the eleventh edition, surveying 10,796 leaders and 2,185 HR professionals across more than 50 countries, and 40% of leaders experiencing stress answered that they had considered leaving their leadership role for the sake of their wellbeing. This is an intent to leave rather than a failure rate, but at least the sample and the methodology are published.

To put it honestly, I could not find a trustworthy statistic on the rate at which engineers become managers and then return to being ICs. There are plenty of widely repeated stories but no citable survey. That fact itself tells you how to read this topic — advice on the IC-to-manager transition is almost entirely anecdote, and it should be read as anecdote. It is also why so much of it contradicts itself.

How to Judge Whether to Go Back to IC

The standard reference point on this topic is Charity Majors' The Engineer/Manager Pendulum (May 11, 2017). There are three core claims. Management is not a promotion but a lateral move onto a parallel track; the best frontline engineering managers are never more than two to three years removed from hands-on work; and you only get better at one of engineering or management at a time.

This piece is a perspective too, not research. There are no cited grounds, and the source the author gives is a conversation with Sarah Mei at the time. What is interesting is that I could not find a serious rebuttal to it, which means less that a consensus has been reached and more that there is no falsifiable data in this area.

On top of that, if I add my own opinion, the criteria divide as follows.

Start with the things that do not count as reasons to go back. This quarter is hard is not a reason. As we saw above, the first six months is when you first experience a state in which the feedback loop is slow and hard to read, and that discomfort is not a signal of failure but the default of the role. I miss coding is not a reason on its own either. It is worth first checking whether it is the kind that a weekend project resolves.

I think there are three things that do count as reasons to go back.

Twelve to eighteen months have passed and the team's output is indistinguishable from before you arrived. But judging this requires that you set up the instrumentation from the previous section in advance. Made without instrumentation, this judgment is usually just that day's mood.
You still cannot picture what a "good day" in the manager job looks like. If you cannot define for yourself which day was a day well spent, then no direction of improvement is defined in that role.
The organization does not give the manager real levers. If you have no authority over hiring, compensation, or direction but carry responsibility for the results, Grove's equation does not hold. This is not a question of personal aptitude but of the seat, and changing seats is faster.

If you are planning to go back, look at the cost as well. Under the pendulum model the round trip is itself an asset, but there is one thing you actually lose — the time you would have spent on the senior IC track. Two years spent as a manager are not two years on the staff engineer track. This is the part the pendulum model does not handle well, and it is honest to put it into the calculation when deciding.

Closing — Accepting "Not Knowing Whether You Are Doing Well" as the Default

To summarize:

Becoming a manager is not the workload going up but the output function being swapped out. When output becomes the team's output, as in Grove's definition, people and time wedge themselves in between activity and output.
As a result the feedback loop stretches from minutes to quarters, and the signal-to-noise ratio gets worse. Most of the fourteen symptoms the original lists derive from here.
Personal throughput breaks as a manager's metric for three reasons. It competes directly with the time budget, it reduces the team's total learning, and it creates a bottleneck.
Advice on this transition is mostly unverified anecdote. The failure-rate statistic in wide circulation has no traceable original source.
Whether to go back to IC is better judged by instrumentation than by mood, and that instrumentation has to be built from day one of the transition to be usable.

Anyone who has operated a system with a slow loop already knows the feeling. In a system with large observation lag, immediate certainty is itself a warning sign. The manager role is the same. Feeling certain every week that you are doing well is not the normal state; not knowing whether you are doing well is the default, and the job is to lay instrumentation on top of it.