Split View: 매니저가 된다는 것의 진실 — 시니어 엔지니어에 회의가 더해지는 일이 아니다

매니저가 된다는 것의 진실 — 시니어 엔지니어에 회의가 더해지는 일이 아니다

들어가며 — 열네 가지 "진실"의 공통점
출력 함수가 바뀐다 — 그로브의 등식
개인 처리량이라는 지표가 작동을 멈추는 세 가지 이유
피드백 루프가 느려지고, 읽기 어려워진다
첫 6개월에 반복되는 실패 세 가지
숫자를 찾아보면 거의 없습니다
IC로 돌아가야 하는지 판단하는 법
마치며 — 잘하고 있는지 알 수 없는 상태를 기본값으로 받아들이는 일
참고 자료

들어가며 — 열네 가지 "진실"의 공통점

2026년 7월 29일, GeekNews에 "매니저가 된다는 것의 진실"이라는 항목이 올라와 41포인트를 받았습니다. 원문은 Sofia Kodar라는 개인 블로거가 6월 21일에 쓴 The truth about being a manager이고, 그보다 이틀 뒤인 6월 23일에 Hacker News에 올라가 113포인트에 64개 댓글을 모았습니다.

먼저 이 글의 성격을 분명히 해 둘 필요가 있습니다. 이건 연구가 아니라 개인 경험 에세이입니다. 통계도, 인용된 논문도, 표본도 없습니다. 저자가 스스로 밝힌 이력(약 11년의 매니저 경험)이 유일한 근거이고, 그 이력도 외부에서 검증할 방법이 없습니다. 그러니 "진실"이라는 제목은 저자의 진실이라는 뜻으로 읽는 게 맞습니다.

그런데 이런 글이 반복해서 상단에 올라간다는 사실 자체는 정보입니다. 열네 개 항목을 늘어놓고 보면 대부분이 한 가지를 다른 각도에서 말하고 있습니다 — 더 이상 팀의 일부가 아니다, 지나가듯 한 말이 지시로 해석된다, 외롭다, 말할 수 없는 정보를 안고 다닌다, 하루 단위로 진척이 보이지 않는다. 업무량이 늘었다는 이야기가 아닙니다. 일의 종류가 바뀌었다는 이야기입니다.

원문은 그 이유를 설명하지는 않습니다. 이 글은 그 구조를 설명합니다. 매니저가 된다는 것은 시니어 엔지니어 역할에 회의가 얹히는 일이 아니라, 출력 함수 자체가 교체되는 일입니다. 그리고 그 교체의 부작용은 대부분 하나의 원인에서 나옵니다 — 피드백 루프가 느려지고, 읽기 어려워집니다.

출력 함수가 바뀐다 — 그로브의 등식

앤디 그로브가 High Output Management의 관리 레버리지 장에서 제시한 정의는 간단합니다. 매니저의 출력은 자기 조직이 낸 출력에, 자신의 영향권 아래 있는 인접 조직들이 낸 출력을 더한 값입니다.

이 정의에서 실제로 중요한 부분은 등식의 오른쪽이 아니라, 그 앞에 있는 구분입니다. 그로브는 활동(activity)과 출력(output)을 분리합니다. 하루에 회의 여덟 개를 소화하고 결정 열두 개를 내린 것은 활동입니다. 출력은 그 팀이 그 분기에 내놓은 것입니다. 둘은 상관이 있지만 같지 않고, 상관관계의 방향조차 자명하지 않습니다.

IC일 때는 이 구분이 거의 필요 없습니다. 활동과 출력의 거리가 짧기 때문입니다. 코드를 쓰는 활동은 머지된 변경이라는 출력으로 몇 시간에서 며칠 안에 이어지고, 그 사이에 개입하는 다른 사람의 수도 적습니다. 매니저가 되는 순간 이 사이에 사람과 시간이 끼어듭니다. 오늘 한 1on1의 출력은 이번 분기가 아니라 다음 분기에, 그것도 다른 사람의 손을 거쳐 나타납니다.

여기서 첫 번째 실무적 결론이 나옵니다. 매니저 역할에서 잘하고 있는지를 판단하려면, IC 시절에 쓰던 지표를 버리는 게 아니라 그 지표가 왜 오작동하는지를 이해해야 합니다.

개인 처리량이라는 지표가 작동을 멈추는 세 가지 이유

IC 시절의 자기 평가 방식은 대체로 개인 처리량입니다. 이번 주에 무엇을 머지했는가, 인시던트를 몇 개 껐는가, 설계 문서를 몇 개 썼는가. 이 지표가 매니저에게는 세 가지 이유로 고장 납니다.

첫째, 직접 경쟁 관계입니다. 개인 처리량을 유지하려면 팀의 출력을 만드는 데 쓸 시간을 깎아야 합니다. 1on1을 미루고, 채용 인터뷰를 넘기고, 인접 팀과의 조율을 뒤로 밀면 이번 주 개인 처리량은 유지됩니다. 그로브의 등식에서 왼쪽을 지키기 위해 오른쪽을 깎는 셈입니다.

둘째, 팀의 학습 총량이 줄어듭니다. 매니저가 직접 처리하는 일은 대개 가장 어렵고, 가장 재미있고, 학습 가치가 높은 일입니다. 마감이 다가올 때 매니저가 그 일을 가져가면 단기적으로는 영웅이 되지만, 그 일에서 배웠어야 할 사람은 배우지 못합니다. Camille Fournier가 신임 매니저의 흔한 실패로 기술적 결정을 위임하지 않고 쥐고 있는 패턴을 지적한 것도 같은 맥락입니다(다만 저는 이 글의 본문을 직접 확인하지 못했고 제목과 요지만 확인했습니다).

셋째, 병목이 됩니다. 개인 처리량이 높은 매니저는 자기 승인, 자기 리뷰, 자기 지식에 의존하는 경로를 만들어 냅니다. 그 경로는 매니저가 휴가를 가는 순간 드러납니다.

관리 범위 숫자를 여기에 겹쳐 보면 그림이 더 분명해집니다. Will Larson은 Sizing engineering teams(2018년 7월 14일)에서 매니저가 능동적으로 코칭하고 조율할 수 있는 상한을 6명에서 8명으로 봅니다. 그 위, 대략 8명에서 9명을 넘어가면 매니저의 역할은 코치가 아니라 "문제가 생겼을 때의 안전망"으로 축소된다고 적습니다. 반대로 4명 미만은 팀이라기보다 개인들의 집합에 가깝다고 봅니다. 이 숫자들이 말해 주는 건 조직도 모양이 아니라 시간 예산입니다. 6명에서 8명이라는 범위는 능동적 코칭에 필요한 시간을 근무 시간으로 나눈 결과에 가깝고, 개인 처리량은 바로 그 예산에서 나옵니다.

피드백 루프가 느려지고, 읽기 어려워진다

부작용들의 공통 원인은 여기 있습니다. 표로 정리하면 이렇습니다.

축	IC	매니저
출력 단위	머지된 변경, 복구된 장애	팀이 분기에 내놓은 결과
피드백 지연	분에서 일 단위(CI, 리뷰, 배포)	주에서 분기 단위(채용 결과는 반년, 조직 변경 효과는 1년)
판독 가능성	높음. 테스트가 빨간색이면 틀린 것	낮음. 팀이 잘 굴러가는 게 내 덕인지, 원래 좋은 사람들이 모여서인지 구분 불가
실패 신호	즉시, 자동으로 도착	지연되고, 대개 사람을 통해서만 도착
교정 비용	낮음. 되돌리면 됨	높음. 신뢰는 롤백되지 않음

이 표에서 가장 중요한 줄은 판독 가능성입니다. 지연만 문제라면 참으면 됩니다. 진짜 문제는 신호 대 잡음비입니다. 팀의 성과에는 매니저의 기여 외에 채용 시장, 제품 방향, 인접 팀의 상태, 그리고 그냥 운이 모두 섞여 들어갑니다. 그래서 좋은 분기가 자기 실력의 증거라는 보장이 없고, 나쁜 분기가 자기 잘못의 증거라는 보장도 없습니다.

학습은 피드백 루프의 함수입니다. 루프가 분기 단위이고 잡음이 크면, 사실상 지도 학습이 되지 않습니다. 여기서 두 번째 실무적 결론이 나옵니다. 매니저의 성장은 자연 발생하지 않습니다. 계측을 직접 만들어야 합니다. 구체적으로는 세 가지가 도움이 됩니다.

결정 로그. 어떤 결정을 언제, 어떤 근거로, 어떤 결과를 예상하고 내렸는지 한 줄로 남깁니다. 분기 말에 예측과 결과를 대조하면, 잡음 속에서 자기 판단의 편향만 따로 볼 수 있습니다.
선행 지표. 분기 결과는 늦게 오지만, 1on1에서 나쁜 소식이 얼마나 빨리 올라오는지, 온콜 인계가 얼마나 조용한지, 설계 리뷰에서 반대 의견이 나오는지 같은 것은 주 단위로 관찰됩니다.
외부 관찰자. 판독 가능성이 낮은 신호를 읽는 가장 싼 방법은, 같은 조직을 다른 각도에서 보는 사람(동료 매니저, 스태프 엔지니어)에게 정기적으로 묻는 것입니다.

첫 6개월에 반복되는 실패 세 가지

원문의 열네 항목, HN 댓글, 그리고 널리 읽히는 관리 문헌에서 반복해서 나타나는 실패 모드는 대략 세 가지로 수렴합니다.

개인 처리량을 놓지 못합니다. 가장 흔합니다. 스프린트 후반에 직접 코드를 짜서 막고, 어려운 인시던트를 직접 처리합니다. 앞 절에서 본 대로 이건 단기 이득과 장기 손실을 맞바꾸는 거래인데, 문제는 이 거래의 손실 쪽이 6개월 뒤에야 보인다는 점입니다. 피드백 루프가 느리다는 사실이 바로 이 실패를 오래 살아남게 합니다.

말의 무게를 오판합니다. 원문에서 가장 정확한 지적이라고 생각하는 부분입니다. IC 시절의 "이거 좀 이상하지 않아요?"는 질문이었지만, 매니저의 같은 문장은 2주짜리 리팩터링으로 돌아옵니다. 지시할 의도가 없었다는 것은 아무 방어가 되지 않습니다. 이건 화자의 의도가 아니라 청자의 위험 계산 문제이기 때문입니다. 실무적인 해법은 의도를 라벨로 붙이는 것입니다 — 이건 생각을 소리 내어 하는 중이고 결정이 아니라는 것, 또는 이건 결정이라는 것을 매번 명시하는 편이 낫습니다.

어려운 대화를 미룹니다. 성과 문제를 첫 분기에 말하지 않으면 다음 분기에는 말하기가 더 어려워집니다. 침묵이 길수록 상대 입장에서는 갑작스러운 통보가 되고, 그때는 내용의 정당성과 무관하게 절차의 문제가 됩니다. Camille Fournier가 I hate manager READMEs(2018년 11월 23일)에서 한 지적이 여기에 그대로 적용됩니다. 신뢰는 자기소개 문서로 만들어지는 것이 아니라, 예측 가능하고 윤리적인 행동이 반복되면서 쌓인다는 것입니다. 어려운 대화를 제때 하는 것은 그 반복의 일부입니다.

HN 댓글에는 원문에 대한 반론도 여럿 있었고, 그중 셋은 실제로 새겨 둘 만합니다. 한 댓글은 매니저가 나쁜 결정을 "팔아야" 한다는 원문의 주장에 정면으로 반대하면서, 투명한 매니저가 결과적으로 더 신뢰를 얻고, 가짜 긍정을 받는 쪽은 그것을 알아본다고 지적합니다. 다른 댓글은 시니어 IC도 회의, 이해관계자 관리, 권한 없는 리더십이라는 거의 같은 부담을 진다는 점에서 원문이 그린 IC와 매니저의 경계가 실제보다 선명하다고 봅니다. 또 다른 댓글은 경험이 쌓이면 실무와 리더십의 균형이 가능해진다며, 원문이 좋은 후보자를 겁줘서 쫓아낼 위험을 지적합니다.

숫자를 찾아보면 거의 없습니다

이 주제에서 가장 자주 인용되는 숫자는 "신임 매니저의 60퍼센트가 24개월 안에 실패한다"입니다. 보통 CEB(현 Gartner) 출처로 붙습니다. 이 글을 쓰면서 원 보고서를 찾아봤는데, 연도도 표본도 방법론도 확인되지 않았습니다. 수십 개의 매체와 블로그가 인용하지만 모두 서로를 인용하고 있고, 원본으로 이어지는 링크가 없습니다. 좀비 통계로 취급하는 게 안전합니다. 근처에서 자주 함께 인용되는 Leadership IQ의 46퍼센트 수치는 실재하는 조사이긴 하지만, 신임 매니저가 아니라 신규 입사자 전반을 대상으로 한 것이라 이 맥락에 그대로 쓸 수 없습니다.

반대로 출처가 분명한 것도 있습니다. DDI의 Global Leadership Forecast 2025는 리더 10,796명과 HR 전문가 2,185명을 50개국 이상에서 조사한 11번째 판인데, 스트레스를 겪는 리더의 40퍼센트가 웰빙을 위해 리더 역할을 떠나는 것을 고려한 적이 있다고 답했습니다. 이건 실패율이 아니라 이탈 의향이지만, 적어도 표본과 방법론이 공개되어 있습니다.

정직하게 적어 두면, 엔지니어가 매니저가 되었다가 IC로 돌아가는 비율에 대한 신뢰할 만한 통계는 찾지 못했습니다. 널리 회자되는 이야기는 많지만 인용 가능한 조사는 없습니다. 이 사실 자체가 이 주제를 읽는 방법을 알려 줍니다 — IC에서 매니저로 가는 전환에 대한 조언은 거의 전부 경험담이고, 경험담으로서 읽어야 합니다. 그중 다수가 서로 모순되는 이유도 그래서입니다.

IC로 돌아가야 하는지 판단하는 법

이 주제의 표준 참조점은 Charity Majors의 The Engineer/Manager Pendulum(2017년 5월 11일)입니다. 핵심은 셋입니다. 매니지먼트는 승진이 아니라 평행한 트랙으로의 수평 이동이라는 것, 가장 좋은 일선 엔지니어링 매니저는 실무에서 2년에서 3년 이상 떨어져 있지 않다는 것, 그리고 엔지니어링과 매니지먼트 중 한 번에 하나만 실력이 는다는 것입니다.

이 글도 연구가 아니라 관점입니다. 인용된 근거는 없고, 본인이 밝힌 출처는 당시 Sarah Mei와의 대화입니다. 흥미로운 건 이 글에 대한 본격적인 반론을 찾지 못했다는 점인데, 이건 합의가 이루어졌다는 뜻이라기보다 이 영역에 반증 가능한 데이터가 없다는 뜻에 가깝습니다.

그 위에서, 제 의견을 덧붙이자면 판단 기준은 이렇게 나뉩니다.

돌아갈 이유가 되지 못하는 것들부터 봅니다. 이번 분기가 힘들다는 것은 이유가 되지 않습니다. 앞에서 본 대로 첫 6개월은 피드백 루프가 느리고 판독이 어려운 상태를 처음 겪는 시기이고, 그 불쾌감은 실패의 신호가 아니라 역할의 기본값입니다. 코딩이 그립다는 것도 그 자체로는 이유가 되지 않습니다. 주말 프로젝트로 해소되는 종류인지 먼저 확인해 볼 만합니다.

돌아갈 이유가 되는 것은 세 가지라고 봅니다.

12개월에서 18개월이 지났는데 팀의 출력이 내가 오기 전과 구분되지 않을 때. 다만 이걸 판단하려면 앞 절의 계측을 미리 해 뒀어야 합니다. 계측 없이 하는 이 판단은 대개 그날의 기분입니다.
매니저 일의 "좋은 날"이 어떤 모양인지 여전히 그려지지 않을 때. 어떤 하루가 잘 보낸 하루였는지 스스로 정의하지 못한다면, 그 역할에서 개선의 방향이 정의되지 않습니다.
조직이 매니저에게 실제 레버를 주지 않을 때. 채용, 보상, 방향에 대한 권한이 없는데 결과에 대한 책임만 있다면 그로브의 등식이 성립하지 않습니다. 이건 개인의 적성 문제가 아니라 자리의 문제이고, 자리를 바꾸는 편이 빠릅니다.

돌아가는 것을 계획한다면 비용도 같이 봐야 합니다. 진자 모델을 따르면 왕복 자체는 자산이지만, 실제로 잃는 것이 하나 있습니다 — 시니어 IC 트랙에서 보냈을 시간입니다. 매니저로 보낸 2년은 스태프 엔지니어 트랙에서의 2년이 아닙니다. 이건 진자 모델이 잘 다루지 않는 부분이고, 결정할 때 계산에 넣는 게 정직합니다.

마치며 — 잘하고 있는지 알 수 없는 상태를 기본값으로 받아들이는 일

정리하면 이렇습니다.

매니저가 된다는 것은 업무량이 늘어나는 일이 아니라 출력 함수가 교체되는 일입니다. 그로브의 정의대로 출력이 팀의 출력으로 바뀌면, 활동과 출력 사이에 사람과 시간이 끼어듭니다.
그 결과로 피드백 루프가 분 단위에서 분기 단위로 늘어나고, 신호 대 잡음비가 나빠집니다. 원문이 나열한 열네 가지 증상 대부분이 여기서 파생됩니다.
개인 처리량은 매니저의 지표로 세 가지 이유에서 고장 납니다. 시간 예산과 직접 경쟁하고, 팀의 학습 총량을 줄이고, 병목을 만듭니다.
이 전환에 대한 조언은 대부분 검증되지 않은 경험담입니다. 널리 도는 실패율 통계는 원 출처를 찾을 수 없습니다.
IC로 돌아갈지는 기분이 아니라 계측으로 판단하는 편이 낫고, 그 계측은 전환 첫날부터 만들어 둬야 쓸 수 있습니다.

루프가 느린 시스템을 운영해 본 사람이라면 이미 아는 감각입니다. 관측 지연이 큰 시스템에서는 즉각적인 확신이 오히려 위험 신호입니다. 매니저 역할도 같습니다. 잘하고 있다는 확신이 매주 드는 상태가 정상이 아니라, 잘하고 있는지 알 수 없는 상태가 기본값이고 그 위에 계측을 얹는 것이 일입니다.

참고 자료

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.