When a release pipeline stalls or a sprint begins to drag, a new engineering manager faces a subtle but powerful reflex: open the editor, pull the ticket, and solve the problem directly. After years of building muscle memory around personal execution, stepping into code feels reassuringly tangible. The problem is clear, the fix is immediate, and the team gets an instant assist.
When a manager routinely takes over without diagnosing why delivery has stalled, the underlying problem can remain unresolved. Alongside any immediate technical help, the manager needs to understand the cause and equip the team to handle the next obstacle.
Diagnose Systemic Friction
Mushfiq Sarker, founder and M&A advisor at WebAcquisition, recognizes how tempting it is to step in when output falls short. Reflecting on his experience leading financial analysts, he notes that when a deliverable comes back flawed, the natural impulse is to take over and polish it personally. To resist that urge, Sarker relies on a clear diagnostic framework: “This is the frame that I use: When delivery is lagging, it's your job to determine whether it's a skill gap, process gap or capacity gap. Those three things require totally different fixes,” Sarker tells Dice.
While his background is in financial advisory, the framework maps directly onto software engineering teams. Is a delay caused by a skill gap that requires targeted mentorship or pair programming? Is it a process bottleneck stemming from vague technical specs or inefficient code reviews? Or is it simply a capacity issue where the roadmap overestimates team velocity?
Applying the wrong fix – or routinely pushing code yourself – masks these underlying issues and can leave the underlying problem unresolved.
Tom Barber, founder of Concept to Cloud, cautions that jumping in short-circuits the critical learning loops junior engineers need to grow. “Try as hard as possible to resist jumping in and fixing issues today. It means that someone more junior didn't have the opportunity to learn from either a mistake or something they could have optimised the first time around, and you end up becoming the bottleneck,” Barber tells Dice.
Navigating this requires pragmatic judgment. Before intervening, evaluate the blast radius and urgency of the problem. If a production-critical fire demands your direct intervention, treat your involvement as an explicit exception – and establish a clear path for returning ownership to the team once the incident resolves.
Riken Shah, CEO of OSP Labs, uses his own technical instincts as a metric for team health. “I regard the need to write code as a signal that something is off. Before I open the code editor, I ask myself, 'What is causing the team's slowdown?'” Shah tells Dice. While complex architectural crises may occasionally require a manager’s deep technical expertise, the vital distinction lies in intent: are you intervening to fix a systemic blocker, or simply seeking the familiar comfort of a closed ticket?
Shift Focus From Personal Output
One of the hardest psychological shifts in moving to management is letting go of visible, individual achievements. Sarker recalls spending hours coaching an analyst through a complex quality-of-earnings review, only for the final deliverable to carry the analyst’s name. His leadership was critical to the outcome, yet his contribution was invisible in the final product.
A similar adjustment can occur in engineering management. A successful day might involve unblocking cross-functional dependencies, refining team workflows, or coaching an engineer through a difficult design pattern – efforts that fuel team velocity without leaving your footprint in the commit log.
Shah highlights how stark this transition feels after years on the IC track. “As an individual contributor, each merge of a pull request, fix of a bug, or launch of a new feature was proof that I had done something meaningful during the day,” he says.
To build a healthy sense of impact, new managers must redefine progress. Value comes from enabling strategic alignment, shielding the team from external noise, and building problem-solving capabilities so engineers can execute without hand-holding. Inserting yourself into every technical decision is not effective leadership; it is micromanagement disguised as oversight. Real leverage comes from cultivating independent judgment across the team.
Navigate Shifting Peer Dynamics
Stepping up to lead former peers is an inherently delicate transition. Existing camaraderie must coexist with new responsibilities around performance assessment, compensation, and team accountability.
For Shah, managing this shift meant grounding his approach in transparency and consistency, not authority. “When I became a manager, my focus was shifted from exercising power to ensuring predictability,” he says.
Sarker advises addressing the structural change directly in one-on-one conversations early on. Establishing clear communication channels and asking engineers what support they need sets a constructive tone. “Trust is built with former peers the same way it was before. Be reliable, trustworthy and follow up. The title didn't change those rules,” he says.
Use these conversations to align on decision-making boundaries, feedback expectations, and priority management. Unblock their work, defend their focus time, and keep your commitments. When organizational constraints limit what you can deliver, communicate those realities candidly. Leading former peers does not require pretending nothing has changed. It requires establishing a professional environment built on mutual accountability, clear expectations, and active support.
Adopt Metrics That Measure Engineering Health
Barber cautions against using personal activity counts as a measure of impact in either role. “Lines of code and commit frequency are a terrible way of understanding impact from both a developer's perspective and an engineering manager's perspective,” he notes.
Barber suggests looking at outages, delivery time, team output, and fewer operational emergencies. Sarker adds that manager effectiveness can be judged by team growth and decision-making autonomy.
“If I have a ton of decisions waiting for me, that's a red flag, I'm not building the right judgment in my team,” Sarker says.
Shah looks at whether team members overcome obstacles, make decisions without his involvement, deliver consistently, identify obstacles early, and become more confident. Consider reviewing those signals alongside delivery outcomes over time to assess how your support is helping the team.
Ultimately, your success as a manager is measured by the resilience, velocity, and autonomy of the engineering team you build.
Choose Your Career Trajectory Intentionally
Moving into management should be a deliberate pivot, not a promotion path. Reflect deeply on where you want to focus your energy: developing people and optimizing organizational systems, or solving complex technical and architectural challenges?
Barber points out that Staff/Principal Engineer and Engineering Manager are parallel tracks of technical leadership, each serving distinct organizational needs. Sarker similarly emphasizes viewing management as a distinct career change that requires learning a new discipline.
Before accepting a management role, clarify the actual expectations with leadership. Clarify the balance between people management and technical ownership, budget authority, and performance evaluation criteria. Whenever possible, seek out opportunities to mentor junior developers or lead technical initiatives to test your appetite for leadership and mentorship.
Consider a simple gut check: If you spend an entire afternoon helping an engineer untangle a complex architectural problem, and they go on to author and ship the solution independently, do you feel genuine satisfaction and accomplishment? If so, a role where you’re leading growth for others might be right for you.
