What changes when you move from engineer to manager?

Your output becomes indirect. As an engineer, you produce the work; as a manager, you produce the team that produces the work. Feedback loops stretch from hours to months, your calendar replaces your compiler, and the skills that got you promoted — personal technical throughput — actively mislead you if you keep optimizing for them. The transition fails when people try to be the best engineer and a manager simultaneously.

Should engineering executives stay hands-on technically?

Depth, yes; production code, no. An executive on a delivery-critical path is an organizational bug — a single point of failure above the escalation chain. But executives who let technical understanding fully atrophy become unable to evaluate what they are told and drift into managing by slideware. Keep enough hands-on practice, off the critical path, to read design docs critically and follow an incident narrative unaided.

Is the move from engineering to management reversible?

Yes, and treating it as reversible produces better decisions than treating it as a one-way promotion. Moving back to senior IC work after a management tour is increasingly normal and often strategic — the management experience makes you a better senior engineer. What is genuinely hard to reverse is executive scope, where years away from the technology accumulate real distance.

What should engineers keep as they move into executive roles?

Three things: systems thinking, which transfers directly to organizational design; the debugging mindset, which turns political and delivery problems into diagnosable systems; and respect for ground truth — the instinct to check the logs rather than trust the summary. What must be dropped is the identity of being the smartest technical person in the room, because clinging to it suffocates the people you now lead.

Leadership

From engineer to executive: what changes, what to keep

The engineer to executive path through its real transitions — IC to lead to manager to executive — what each takes from you and what to refuse to give up.

By Pavel Glukhikh April 6, 2026 6 min read

Executive summary

The engineer-to-executive path is not one promotion but a series of identity transitions — IC to lead, lead to manager, manager to executive — and each one invalidates part of what made you successful at the previous level. The work changes from writing code, to directing work, to building teams, to setting direction for people you rarely meet. I have made each of these transitions, across DXC, my own companies, and an ITAR operations team, and I kept notes. This article maps what actually changes at each step, the traps engineers specifically fall into, what to deliberately keep from your technical past, and what you have to drop.

Four jobs wearing one career

The engineer-to-executive path looks like a ladder from the outside — same field, ascending titles. From the inside it is four different jobs, and each transition between them quietly invalidates skills you spent years building. I’ve made all of these moves: engineer, to lead, to managing 30+ people across two teams at DXC, to founding and running two companies, to owning technology strategy for enterprise accounts as a client technology leader, to my current enterprise-architecture work. The pattern repeated every time: the behaviors that earned the promotion are the ones the new job punishes.

Nobody tells you this at promotion time, so engineers keep discovering it the expensive way — by doing the old job harder while the new one fails around them. Here is the map I wish someone had handed me.

IC to lead: your opinion becomes load-bearing

The first transition looks the smallest and rewires the most. As a senior engineer, your strong opinions are contributions; the team debates them, some win, some lose, no harm done. The day you become lead, the same opinions become instructions whether you intend them or not. You think you’re brainstorming; the junior engineer hears a decision and quietly abandons a better idea.

What changes:

You speak last. State your position first and the discussion ends prematurely. The lead’s technical judgment is best spent framing the problem and probing options, then deciding — not anchoring.
You give away the interesting work. The lead who keeps the hard, fun problems for themselves — because they are, honestly, best equipped for them — caps the team’s growth at their own ceiling. The gnarly refactor is a development opportunity wearing a disguise.
Your code moves off the critical path. Not out of the codebase — off the critical path. A lead who owns the release-blocking component has guaranteed that every management interruption becomes a delivery slip.

The trap for engineers specifically: continuing to measure yourself by personal commits. Your metric changed the day the title did; nobody updated your dashboard. That’s your job now.

Lead to manager: output becomes indirect

The second transition is the famous one, and the pain is structural, not emotional. Engineering gives you feedback in minutes — it compiles, the test passes, the graph goes flat. Management feedback arrives in months: the hire you made, the feedback you gave, the process you changed all pay out next quarter or never. Engineers moving into management routinely describe the first year as “I can’t tell if I did anything today,” and they’re right — the day’s work was planting, and planting looks like nothing.

What I learned managing my first real teams, then two teams of 30+:

The calendar is the codebase now. Where your hours go is the only real statement of your priorities. I audit mine monthly the way I used to profile hot paths — and the results are just as embarrassing.
One-on-ones are the unit test suite. Skipping them saves time exactly the way skipping tests does, with the same deferred invoice. The mechanics I run — rhythm, skip-levels, delegation charters — are in managing engineering teams at scale.
People problems don’t ship like code. You can’t refactor a person. The debugging mindset transfers — observe, hypothesize, test, iterate — but the iteration loop is weeks long and the system has feelings about being debugged. Goleman’s finding that emotional intelligence dominates at senior levels stops being an HBR abstraction here; it’s Tuesday.
The pendulum is legitimate. Charity Majors’ engineer/manager pendulum essay says what the industry took too long to admit: going back to senior IC work after a management tour isn’t failure, it’s often the best career move available, and managers who’ve done it come back better. Treating management as a reversible experiment rather than a one-way promotion produces more honest decisions about whether you want this job at all.

Manager to executive: direction replaces teams

The third transition is the least documented, and it’s the one where “leader” stops meaning “person the team knows.” As a manager, you lead people you see daily. As an executive — running my own companies, and later carrying account-CTO accountability for clients’ technology — you set direction for outcomes delivered by people you mostly won’t meet, through leaders you must trust, against timelines measured in years.

What actually changes at this altitude:

Your words gain mass. A musing from an executive launches projects. I learned to label my output explicitly: “this is a decision,” “this is a question,” “this is me thinking out loud, do nothing.” It feels mechanical. It prevents organizations from executing your stray thoughts.
You manage systems, not work. The levers left to you are structure, staffing, incentives, and narrative. If you’re personally unblocking tickets at executive scope, something below you is broken and you’re hiding it from yourself by compensating.
Ambiguity stops being escalatable. Every level of the ladder, you could send the truly ambiguous calls upward. At the top of your scope, ambiguity is the job description. The decision discipline in technical decision making — reversibility sorting, named deciders, written reasoning — is what keeps judgment functional when there’s no one left to ask.
Loneliness is structural. Your peers are few, your reports filter, and your problems are confidential. Executives without outside peers or mentors drift; I hold this loneliness partly at bay with communities and speaking, where the conversations run peer-to-peer again.

What to keep, what to drop

The question engineers ask most about this path: do I have to stop being technical? My answer after making the full journey — no, but you have to change why you’re technical.

Keep, deliberately:

Asset	Why it still pays at executive level
Systems thinking	Org design is distributed-systems design: interfaces, coupling, failure domains, backpressure. Same discipline, softer components
The debugging mindset	Delivery messes and political knots yield to observe-hypothesize-test just like segfaults. Most executives guess; former engineers can diagnose
Respect for ground truth	The instinct to read the log instead of the summary becomes skip-levels, gemba visits, and reading the actual incident report. It’s the antidote to slideware reality
Hands-on practice, off the critical path	I keep a production-grade home lab precisely so my technical intuition decays slower than my distance from delivery grows. Rusty is fine; hollow is not

Drop, ruthlessly:

The smartest-in-the-room identity. At executive scope, needing to win technical arguments suffocates your best people and biases your hiring toward those who’ll let you win. The job is being the person in whose presence the best thinking happens — not the person doing it.
Personal throughput as self-worth. The days of clearing a satisfying queue are over. Executive value is a small number of high-consequence judgments per quarter, made well. Learn to feel productive on the days you made one decision, if it was the right one made cleanly.
The comfort of certainty. Engineering trained you to defer action until the answer was provable. Executive work is committing capital and people on 70% information, then updating in public without whiplash. This is disagree-and-commit applied to yourself.

The through-line of the whole path, and the reason I still call myself a servant leader at every altitude: your definition of “my work” has to keep expanding — from my code, to my team’s delivery, to my organization’s capability, to outcomes owned by people who will never know your name. Engineers who make that expansion without losing their respect for the ground truth make the best executives I know. The ones who can’t let go of the compiler stay brilliant — and stuck.

Frequently asked questions

What changes when you move from engineer to manager?: Your output becomes indirect. As an engineer, you produce the work; as a manager, you produce the team that produces the work. Feedback loops stretch from hours to months, your calendar replaces your compiler, and the skills that got you promoted — personal technical throughput — actively mislead you if you keep optimizing for them. The transition fails when people try to be the best engineer and a manager simultaneously.
Should engineering executives stay hands-on technically?: Depth, yes; production code, no. An executive on a delivery-critical path is an organizational bug — a single point of failure above the escalation chain. But executives who let technical understanding fully atrophy become unable to evaluate what they are told and drift into managing by slideware. Keep enough hands-on practice, off the critical path, to read design docs critically and follow an incident narrative unaided.
Is the move from engineering to management reversible?: Yes, and treating it as reversible produces better decisions than treating it as a one-way promotion. Moving back to senior IC work after a management tour is increasingly normal and often strategic — the management experience makes you a better senior engineer. What is genuinely hard to reverse is executive scope, where years away from the technology accumulate real distance.
What should engineers keep as they move into executive roles?: Three things: systems thinking, which transfers directly to organizational design; the debugging mindset, which turns political and delivery problems into diagnosable systems; and respect for ground truth — the instinct to check the logs rather than trust the summary. What must be dropped is the identity of being the smartest technical person in the room, because clinging to it suffocates the people you now lead.