It is 6:30 PM on a Tuesday. Your IDE is open, but you haven't written a line of code in three days. Instead, the week went to untangling a resource conflict between two squads, rewriting a product roadmap after a sudden shift in API strategy, and coaching a Senior Engineer through a performance dip.
For many high-performing individual contributors, this is not a temporary state — it is the start of a quiet identity crisis. You are standing at a fork. Your manager has probably suggested that your next natural step is Engineering Management. Your peers think you would be great at it. But every time you consider trading your terminal for a calendar full of syncs, you feel a visceral pull in the other direction.
The tension comes from a fundamental misunderstanding: the industry reads leadership as a promotion. It isn't. Engineering Management is a career change, not a level-up. If you approach it as "Senior Engineering with more meetings," you will fail your team, stall your own growth, and eventually burn out.
Below is a framework for checking where you actually want to go instead of guessing. It ends with my own trajectory in both directions, because this topic is easy to keep abstract.
Section 1: The trap of "common sense" progression
In most corporate structures the career ladder looks like a single line that eventually splits. Junior → Mid → Senior, and at the Senior or Staff level the split becomes mandatory: either further along the technical track (Staff, Principal, Distinguished), or into people management (EM, Director, VP).
The trap is that the EM role often looks more visible. It comes bundled with headcount, budget and organizational power. In legacy organizations the only way to get a seat at the "big table" was to manage people. That produced a generation of reluctant managers — strong engineers who were pushed into leadership to get a raise, or to finally have their architectural opinions heard.
The industry has been gradually fixing this. The dual-career ladder is now standard in mature engineering organizations: both tracks are treated as equally senior and equally consequential, though the specific level names and the terms behind them differ from company to company. One track influences through systems, the other through people.
Choosing the wrong path out of prestige or a sense of "natural progression" is a reliable route to regret. To choose deliberately, you have to drop the status anxiety and look at the actual nature of the work.
Section 2: The IC reality — architecture, influence and the burden of correctness
The move from Senior to Staff or Principal is a move from "building the thing" to "ensuring the right things are built correctly."
At Staff+, your primary output is no longer pull requests. It is clarity: you define technical standards, you spot cross-cutting risks, you preserve the conceptual integrity of a product. You are the last line of defense against technical debt.
The feedback loop. On the IC track it is relatively short. You design a system — it either survives the load or it crashes. You refactor a legacy module — deployment speed goes up. Your work has a tangible, objective truth you can be checked against.
The burden. Your burden is correctness. If the system fails at 3 AM because of an architectural flaw you approved, that is on you. You are expected to have a depth of knowledge others lack, and to keep it current deliberately. You cannot "manage from a distance" — you have to understand the trade-offs behind every database choice, every protocol, every abstraction.
For many people, the Staff+ role is the pinnacle of engineering work precisely because it lets you solve the hardest technical problems without the emotional weight of being responsible for someone's mortgage or mental health. But it can also be a lonely path: you are often an outlier, working across teams rather than inside a tight-knit group.
Section 3: The manager reality — people, systems and the burden of ambiguity
The moment you become an Engineering Manager, your tools change. You no longer use a compiler — you use communication, psychology and organizational design.
The feedback loop. This is the hardest part of the adjustment. A manager's feedback loop is long and extremely noisy. You can spend six months coaching an engineer, only for them to leave. You can introduce a new planning process whose results only show up a quarter later. There will be days when you feel you "did nothing" because the whole day was spent talking.
Success is no longer yours; it belongs to the team. If the team ships something strong, they did it. If the team fails, you did it.
The burden. Your burden is ambiguity. People are not deterministic. Unlike code, you cannot debug a human being with a stack trace. You have to deal with egos, personal crises and the messy overlap between product requirements and developer happiness. You are the shock absorber: you shield the team from chaos at the leadership level while keeping them accountable to the business.
The real job of an EM is system optimization where the "units" are people. You build a high-trust environment where the team's collective output exceeds the sum of what its members would achieve individually. If that sounds appealing to you, you are a manager. If it sounds like an annoying distraction from "real work," you are an IC.
Section 4: The 10-question calibration framework
Before you commit to a path, answer these ten questions honestly. Use a scale from 1 to 5 (1 = strongly disagree, 5 = strongly agree).
- I get more satisfaction from a clean system architecture than from a well-run team meeting.
- I would rather solve a hard technical bug than mediate a conflict between two developers.
- I prefer clear, objective "done" states (code passing tests) over subjective ones (team morale is high).
- I find "people problems" more draining than "technical debt."
- I want to remain the most technically proficient person in the room on specific domains.
- I enjoy the intellectual challenge of learning new frameworks more than the challenge of learning organizational politics.
- I find it difficult to delegate a task when I know I could do it faster and better myself.
- I value "deep work" (4+ hours of focus) over a "manager's schedule" (30-minute context switches).
- My primary career motivation is to build world-class technology, not to build world-class organizations.
- I feel a sense of loss when I don't write code for more than a week.
Scoring and directions
40–50 points: the IC track. You are a technical specialist at heart. Forcing yourself into management will most likely lead to resentment. Your value to the company is your deep expertise and technical vision, and the Staff/Principal track exists for exactly that. I covered that track separately: «From Senior Engineer to Principal: What Changes and What Does Not».
25–39 points: the hybrid. You are in the "danger zone" or the "opportunity zone" — and that is a normal state, not a defect. You see the value in both directions. The practical option at this stage is a Tech Lead role with a small team or a couple of people, where you steer the project and keep writing code. You will have to choose eventually, but looking for a role that exercises both muscles is a sound strategy.
10–24 points: the management track. You already care more about how the team works than about what the code says. You treat the organization as a system. Your technical background becomes your superpower, and your focus shifts to people. What that work looks like at scale is a separate piece: «What Leading a 30-Person Team Taught Me About Technical Clarity».
How to read the result
Two honest caveats, without which the instrument misleads.
It tests your current state, not your destiny. The same person scores differently in different seasons: during a burning release and in a calm quarter, as a strong IC and as someone who has already tried both management and hands-on engineering. Treat the score as a hypothesis to test, not a diagnosis.
Questions 4 and 7 pull in opposite directions. Question 4 is about your energy for working with people; question 7 is about how hard you find delegation to be. A 5 and a 1 there is not noise — it is signal: you like the people work but have not yet learned to let go. A middle score in the middle of the scale is not indecision about your character; it is a specific skill gap, and skill gaps are trained, not chosen around.
Section 5: My trajectory — the gravity of the choice
My career has gone in both directions, and this is not a rhetorical flourish: for the last six years I have combined the role of Principal Architect with running an international engineering organization — Head of Engineering at SEFE, from 16 to 32 people across three countries, with development and QA teams in different locations.
There is a certain purity to IC work. You fight the logic, and when you win, the win stays won. The satisfaction of designing a service that scales to millions of requests without a hiccup is a strong pull. It is a world of control: the system either works or it does not, and the verdict arrives immediately.
The move into leadership felt like stepping into a storm. Suddenly you were no longer controlling the variables — you were managing the people who controlled them. I valued the ability to shape culture and to unblock whole departments. The price was the loss of flow state. You trade the depth of a drill for the breadth of a floodlight. In practice it felt like moving from a world of "yes/no" to a world of "maybe/if." You have to get comfortable with not being the smartest person in the room — in fact, your job is to hire people smarter than you and then stay out of their way.
One more note on what people call "soft skills." In 2024–2025 I completed the year-long SEFE Activate Leadership Development Program (RHR Partners): Fundamentals of Leadership, Emotional Intelligence, Situational Leadership, Coaching, Resilience, Facilitation Skills. That year taught me more about managing people than any number of years of reading about it. The craft turns out to be trainable — not just a temperament you are born with.
Section 6: The long-term play — transitions and the pendulum
One of the great myths in tech is that the choice is permanent. It isn't. Charity Majors, author of the essay "The Engineer/Manager Pendulum" (2017), describes it as a pendulum: strong technologists move between the IC and EM tracks across a career, and swinging back is not a demotion but part of the trajectory.
A few years as a manager can make you a much better IC. You learn how the business actually works, how to talk to stakeholders, and how to design systems that living people can maintain. The reverse holds too: returning to the IC track after management gives you a technical groundedness that keeps you from becoming a "paper architect."
Charity Majors also names the wrong reasons to move — "I want more impact," "I'm tired of coding," "I want a promotion." On her framing, the decision is made on energy and fit with the work, not on those motives. In her second essay on the subject she treats the switch as a deliberate experiment.
If you are a Senior engineer, do not treat this choice as life or death. It is an experiment. Try management, discover it is not for you, and you can always go back — but go back with an understanding of what leading actually costs. With that understanding, the IC track after management usually gives more than it did before.
The healthiest organizations are the ones where the boundary between IC and EM is transparent and permeable. Your decision is not about who you want to be in twenty years; it is about which problems you want to wake up and solve tomorrow.
Conclusion
The "IC or manager" decision is not about following a script. It is about auditing your own energy. Does technical complexity give you energy, or does it drain you? Does a junior engineer's success give you energy, or does it feel like a chore?
Choose the path that matches your natural curiosity. The industry has enough mediocre managers who miss their IDEs, and enough frustrated Staff engineers who wish they could just "fix the culture." Be the person with the courage to pick the track where they can actually do their best work.
Related reading
- From Senior Engineer to Principal: What Changes and What Does Not — the IC track in depth
- What Leading a 30-Person Team Taught Me About Technical Clarity — what the management track looks like at 30+ people
- Where the Bottleneck Moved: Code Review After Coding Agents — a constraint you cannot hire your way out of
- Quiz: IC or Engineering Manager — 10 questions for calibration — the interactive version of the framework from Section 4: answer ten questions and get your result with a shareable link
Sources
- The Engineer/Manager Pendulum — Charity Majors
- Why Should You (Or Anyone) Become An Engineering Manager? — Charity Majors
- Camille Fournier, The Manager's Path — the canonical account of Tech Lead as the entry point into management and of hybrid roles
If you have worked on both the IC and the management side, tell me which track turned out to be yours — and what surprised you. Discuss a career track → techbuzzz.ru
