Confidence can turn into humility very quickly. On my first day as an engineering manager, I walked in with big plans, high energy, and the certainty that I’d crush it. I’d been a strong individual contributor for years — how hard could it be to lead a team? Set the vision, make the plan, motivate the people, and watch the work get done. Simple.
A couple of months later, realisation set in. It wasn’t simple at all.
Decisions were being challenged, deadlines were already slipping, and my calendar looked like a losing game of Tetris. Somewhere between reviewing code, answering “quick questions,” and juggling three “top priority” projects, I realised the job, wasn’t just about leading — it was about surviving long enough to lead.
These are the top level challenges I faced.
Getting the work done
New engineering managers, much like me, will probably reach there from an individual contributor role. Being good at hands on engineering leads to some personal systems that work, coding standards and other work ethics. Working with a larger team where the outcome is still attributed to you, but the ground work is done by the team, can be surprisingly challenging.
Expect everyone to have their own opinions (right or wrong), challenge decisions, question guidelines and not trust your word. The engineering manager needs to navigate this and get the work done, and done well.
Distractions
In most cases a new Engineering Manager will find themselves in the middle of what might seem like chaos. A primary high stakes project, other satellite projects, support issues, infrastructural challenges etc., all with their respective project managers trying to get their own issues bumped to P0.
There are so many distractions, it is easy to lose track of what is actually important, how the overall picture is getting painted and what the actual outcome is shaping up like.
Survive to steer
Not a lot of people like engineering management once they have tried, and I have personally met many who tasted it and went back to being a individual contributor. While there is no harm in trying and not liking it, I have a some insights into how to actually survive and then start steering, if you do like it.
In the beginning you may think is it really about survival? How hard can it be to implement doing things that we theoretically already know how to?
Be prepared to be surprised, it is hard. Especially because the expectations are high and time bound. If you are a little too late to learn the on ground challenges and how to fix them, things have already gone bad enough for you to struggle to get out of. Reputation and track record are very important for a leadership role. Fix it before burns!
Here is my summary of things that will help the survival as a new Engineering Manager. This is not a list of things that will make a "successful" engineering manager, rather these are things to be careful about, to emphasise and to add to your functioning, so that the transition into the new role is smooth and paves the way to success.
Getting the work done
To be able to motivate the team to deliver good quality code on time, the engineering manager must go beyond being a good engineer. I am taking the technical expertise for granted given, like mentioned before, the new EM probably has a very strong technical background already. Lets look at some of the items to carefully consider.
I. Knowledge is gold
While it may not look like the case, engineering managers must know most of the details of the associated code or technologies. Engineers will notice if you can’t follow or cannot give suggestions in technical conversations, and it becomes harder to steer architecture or resolve disagreements.
What to do:
Review code regularly — not to rewrite it, but to understand the team’s style, trade-offs, and pain points. Even a lightweight review gives you the pulse of the codebase.
Document as you learn — maintain a running "manager’s notebook" with architecture diagrams, key module responsibilities, and decision histories. It makes onboarding new team members easier and prevents knowledge silos.
Pair occasionally — sitting with an engineer for 30 minutes on a tricky problem shows you’re still in touch and builds respect.
Pitfall to avoid: Getting sucked into too much coding yourself. It can feel like the fastest way to understand the work, but it will choke your bandwidth for leadership responsibilities.
II. Build the mould, not the hammer
Contribution to code and process is critical for the health of the team and to build trust. The solutions being built by the engineering manager cannot be about direct implementations any more. They need to enable all the engineers to solve technical problems as well as better organise themselves with processes. As an EM, solving a problem means ensuring any engineer on your team could write that piece of code well — without you.
What to do:
Create reusable templates — design doc outlines, pull request checklists, and test coverage guidelines reduce friction and keep quality high.
Define "how we work" together — agree on branching strategies, CI/CD workflows, and definition-of-done criteria. These reduce debates and free up mental energy for actual problem-solving.
Be a facilitator of expertise — if you know the answer, don’t just give it; walk through the thinking so others can arrive there next time without you.
Example: Instead of personally optimizing a query, run a short workshop on profiling queries so that next time, anyone can identify the bottleneck.
III. The way with words
Communication is one of the most important aspects of management, and is more critical for an engineering team because individual contributes are now particularly known to be good at it. So it falls on the engineering manager to do it on the behalf of the team. For good communication to be built, and engineering manager must build the right processes to enable that.
What to do:
Establish formal communication touch-points — weekly design reviews, sprint kickoffs, and post-mortems ensure shared context.
Champion written documentation — decisions made in Slack are lost in a week; decisions in a shared doc can guide the team for years.
Be the translator — turn business goals into engineering terms for the team, and engineering constraints into business language for stakeholders.
Model openness — share updates, explain trade-offs, and give credit publicly.
Pitfall to avoid: Becoming the only channel of communication between engineers and stakeholders. Your goal is to enable good communication patterns, not bottleneck them through you.
Preventing distractions
I. The best laid plans
No plan is perfect, they will change. But still it needs to be done in a methodical manner. Changes should be expected, anticipated as much as possible and flexibility maintained.
What to do:
Create plans with flexibility baked in — avoid rigid Gantt-chart timelines for every subtask; instead, set milestone-based goals with buffers.
Identify “no-slip” dates — for launches tied to customer commitments or marketing events, make sure everyone knows these are immovable.
Communicate changes quickly — update the plan as soon as new information arrives; surprise changes erode trust.
Example: If a critical API dependency slips by two weeks, don’t just adjust your own team’s tasks — explicitly re-evaluate the roadmap, call out trade-offs, and realign stakeholders so expectations don’t drift.
II. If you must say no, say it without fear
This might be a bit of a cliche and it has been repeated way too many times, but let me do it one more time. It is very tempting to say yes to everything ultimately leading to over burdening the team and appearing inefficient with missed committed dates. All feature requests and technical items must be looked on with a certain degree of critique, to understand the readiness, priority and impact.
Why it matters:
Saying “yes” is easy in the moment but costly long-term.
Saying “no” — or “not now” — protects your team’s ability to deliver the work that truly matters.
What to do:
Evaluate every request against priorities — ask: Does this align with our current goals? Does it replace something else?
Offer alternatives — instead of a flat “no,” try “We can start this next sprint if X is deprioritised.”
Be data-backed — show capacity charts, velocity trends, or impact analysis to make “no” a shared business decision, not a personal refusal.
Example: A PM asks for a quick feature that would “only take 2 days.” You explain that those 2 days push a P0 security fix into the next release — and that the business impact of the delay is far greater than the upside of the new feature.
Pitfall to avoid: Making “no” sound like you’re protecting your own time. Always frame it as protecting the team’s ability to deliver.
III. The devil is (not?) in the details
The day to day activities like reviews, solving individual problems, meetings and other discussions can mislead an manager to believe good work is being done, while missing on the big picture of what the targets were and how they were planned to be executed.
Regularly, the EM must re-visit the goals, the projects and the overall direction of the team to keep oneself on track.
What to do:
Schedule regular “big picture” reviews — at least once a week, block time to step back and check if current work aligns with quarterly goals.
Track delivery at the project level, not just ticket level — shipping 90% of your tickets means little if the 10% undone blocks the release.
Watch for “busywork” creep — if an engineer spends all week fixing low-priority bugs, they’re not making progress on strategic goals.
Example: Halfway through the quarter, you notice 60% of the team’s time has gone into production support due to recurring errors. You decide to pause new feature work for a week to implement monitoring and auto-recovery, reducing future distractions.
Pitfall to avoid: Believing that a full calendar equals a productive week. Your job is to ensure impact, not just motion.
Final Thoughts
If you're a new engineering manager staring down a messy, urgent, high-impact project—welcome to the club. It won’t be perfect. It will be intense. But with the right focus, planning, and culture, you can turn it into a defining experience for both you and your team.
And you don't have to figure it all out yourself. Learn from others. Adapt. And then share back. I hope this article sets the tone for a successful journey ahead.
