Managing an engineering team is one of the most rewarding and most demanding roles in technology. On any given week you might be coaching an underperforming engineer through a growth plan, mediating a disagreement between two senior developers, pushing back on a stakeholder's unrealistic timeline, and figuring out why your team's velocity has dropped three sprints in a row. There is no single playbook that covers every situation, but there are proven patterns, frameworks, and conversation techniques that consistently help.
This guide covers the eight most common management scenarios engineering managers face, with practical, actionable advice for each one. Whether you are a first-time manager still finding your footing or a seasoned leader looking for a fresh perspective, you will find specific techniques you can apply in your next 1:1, team meeting, or stakeholder conversation.
Underperforming Engineers
How to diagnose root causes, set clear expectations, and support struggling team members.
Team Conflict
Techniques for mediating disagreements between engineers and restoring healthy collaboration.
Difficult Stakeholders
Managing unrealistic demands, misaligned priorities, and building productive partnerships.
Missed Deadlines
Preventing deadline slips, communicating delays early, and rebuilding trust after misses.
Engineer Burnout
Spotting early warning signs, redistributing load, and creating sustainable work patterns.
Low Team Morale
Rebuilding motivation after setbacks, re-org fatigue, and creating a sense of purpose.
Giving Tough Feedback
Delivering critical feedback clearly, kindly, and in a way that drives real behaviour change.
Remote Team Management
Building trust, maintaining visibility, and staying connected in distributed teams.
Underperforming Engineers
Diagnosing the Root Cause
Before you can address underperformance, you need to understand what is driving it. The most common mistake managers make is assuming the engineer is lazy or does not care. In reality, underperformance almost always stems from one of four root causes: unclear expectations (the engineer does not know what good looks like), a skills gap (they lack a specific technical or soft skill), personal circumstances (health, family, or life events affecting focus), or a role mismatch (they are in the wrong position for their strengths and interests).
Start by reviewing what you have actually communicated. Do they have a clear set of expectations for their level? Have you given them specific, recent feedback on where they are falling short? Many managers discover that the "underperformance" they are frustrated by was never clearly articulated to the engineer. Your 1:1 meetings are the best place to explore root causes through open, non-judgmental questions.
Setting Expectations and Supporting Growth
Once you understand the cause, set concrete, measurable expectations with a clear timeline. Avoid vague feedback like "you need to be more proactive" and instead say "I need you to identify and flag blockers in standup within 24 hours of encountering them, and to propose at least one solution before escalating." Pair the expectation with genuine support: pairing sessions, mentoring from a senior engineer, reduced scope to focus on skill development, or a temporary reduction in interrupt-driven work.
Check in weekly. Document progress and setbacks factually. If the engineer improves, celebrate it explicitly - positive reinforcement matters. If they do not improve after four to six weeks of clear expectations and genuine support, it may be time for a formal performance improvement plan. This is not a punishment; it is a structured last attempt to help them succeed, with clear consequences if they cannot.
Team Conflict
Recognising Healthy vs Unhealthy Conflict
Not all conflict is bad. Healthy technical debate - disagreements about architecture, trade-offs, or implementation approaches - is a sign of a team that cares about quality. The problems start when conflict becomes personal, when people stop listening to each other, or when disagreements go underground and manifest as passive-aggressive behaviour, withholding information, or refusing to collaborate. Your job is not to eliminate conflict but to keep it constructive.
Mediation Techniques
When conflict crosses into unhealthy territory, act quickly. Start with individual conversations to understand each person's perspective. Ask open questions: "What happened from your point of view?" and "What would a good resolution look like for you?" Often, people in conflict are arguing about different things without realising it - one person cares about code quality while the other cares about shipping speed, and neither has named the underlying tension.
Bring both parties together once you understand the positions. Set ground rules: focus on behaviour and impact, not intent or character. "When you dismiss my suggestions in code review without explanation, I feel like my input is not valued" is productive. "You are arrogant and never listen" is not. Your role is to facilitate, not to take sides. Help them find specific, actionable agreements - not vague promises to "communicate better" but concrete commitments like "we will discuss architectural decisions in a 30-minute sync before either of us starts coding."
Follow up in subsequent 1:1s with both individuals. Conflict resolution is not a single conversation; it is a sustained effort to rebuild trust. If the conflict involves bullying, harassment, or discrimination, skip mediation entirely and escalate to HR immediately.
Difficult Stakeholders
Understanding Stakeholder Motivations
Most "difficult" stakeholders are not deliberately difficult. They are under pressure from their own leadership, they lack context about engineering constraints, or they have been burned by missed commitments in the past and have learned to push hard as a defence mechanism. Understanding what drives their behaviour is the first step to managing it effectively. Spend time learning their goals, their metrics, and the pressures they face. When you understand their world, you can frame engineering decisions in terms that resonate with their priorities.
Building Productive Partnerships
The most effective technique for managing difficult stakeholders is proactive communication. Do not wait for them to chase you for updates. Send a brief weekly status - three lines covering progress, risks, and next steps - before they have to ask. When you need to push back on scope or timeline, come with alternatives rather than just saying no. "We cannot deliver all five features by March, but we can deliver the three highest-impact ones and ship the remaining two in April" is far more productive than "that timeline is unrealistic."
Build trust by delivering on small commitments consistently. If you say you will have an estimate by Thursday, have it by Thursday. Reliability on the small things creates the credibility you need when you push back on the big things. When stakeholders trust your judgment, they stop micro-managing your team and start partnering with you on trade-offs.
Missed Deadlines
Why Deadlines Slip
Deadlines in software engineering slip for predictable reasons: scope was underestimated because requirements were vague, technical complexity was not understood until implementation started, unexpected dependencies or blockers emerged, the team was pulled into unplanned work (incidents, urgent requests), or the original estimate was a guess that nobody treated as a range. As a manager, your job is to build systems that surface these risks early rather than hoping deadlines will be met through heroic effort.
Communicating Delays and Rebuilding Trust
When a deadline is at risk, communicate early. The worst thing you can do is stay silent and hope things improve. As soon as you see a credible risk, tell your stakeholders: "Based on what we have learned in the last two weeks, the March 15 target is at risk. Here is what changed, here is where we are, and here is what I recommend we do about it." Stakeholders can handle bad news far better than they can handle surprises.
After a miss, run a blameless retrospective focused on systemic improvements rather than individual blame. Did estimates include buffer for unknowns? Were requirements clear enough to estimate accurately? Were risks surfaced early enough to course-correct? Turn every missed deadline into a process improvement that makes the next deadline more reliable. Over time, this approach builds more trust than never missing a deadline because your team always pads estimates by three times.
Engineer Burnout
Spotting the Warning Signs
Burnout rarely announces itself. It creeps in gradually, and by the time someone tells you they are burned out, they have usually been struggling for weeks or months. Learn to spot the early indicators: declining code review quality or responsiveness, withdrawal from team discussions and social channels, cancelled or shortened 1:1s, increased cynicism or negativity, a sudden drop in output after a sustained period of high productivity, or taking fewer breaks and working longer hours (which paradoxically signals distress, not dedication).
Prevention and Recovery
Prevention is far more effective than cure. Monitor workload distribution actively using your project management data - burnout often starts when your most capable engineers quietly absorb more work because they are reliable and rarely complain. Rotate on-call duties fairly. Protect your team from organisational chaos by being the buffer between them and shifting executive priorities. Do not pass every urgent request straight through; filter, prioritise, and push back on behalf of your team.
When you spot burnout forming, have an honest conversation. Acknowledge what you are seeing without making assumptions. "I have noticed you seem less engaged in the last few weeks. How are you doing? Is there anything about your workload or the work itself that we should adjust?" Then act on what you hear: redistribute tasks, cancel non-essential meetings, encourage genuine time off (not just a day where they check Slack anyway), and if needed, temporarily reduce scope. Recovery from burnout takes time. Expecting someone to bounce back in a week after months of overwork is unrealistic.
Low Team Morale
Diagnosing the Cause
Low morale has many sources: a recent re-org that felt arbitrary, a lack of visible impact from the team's work, too many competing priorities creating a sense of churning without progress, departure of respected team members, or a feeling that leadership does not understand or value engineering work. Before you try to fix morale, diagnose the cause. Run a team retrospective focused specifically on morale, use anonymous surveys, or simply ask in 1:1s: "On a scale of 1 to 10, how motivated are you right now? What would move that number up?"
Rebuilding Motivation
The fix depends on the diagnosis. If the team feels their work has no impact, create visibility: share customer feedback, usage metrics, and business outcomes tied directly to what the team built. If competing priorities are the issue, work with your product partner to ruthlessly cut scope and give the team focus - even if it means saying no to important-but-not-urgent work. If a re-org has shattered trust, be transparent about what you know and what you do not, acknowledge the disruption honestly, and give people time to process.
Quick wins matter when morale is low. Find a small, achievable project that the team can complete and ship in a week or two. The feeling of finishing something and seeing it go live is a powerful antidote to the helplessness that comes with prolonged ambiguity. Celebrate wins publicly - in team channels, in all-hands, and in your skip-level updates. Recognition is one of the most underutilised tools in an engineering manager's toolkit.
Giving Tough Feedback
Why Managers Avoid It
Most engineering managers delay tough feedback because they are afraid of damaging the relationship, making the person feel bad, or creating an awkward dynamic on the team. The irony is that avoiding feedback causes far more damage than delivering it. When you do not tell someone they are falling short, you deny them the opportunity to improve, you allow resentment to build in yourself and in their peers, and you create a culture where mediocrity is quietly tolerated.
Delivering Feedback Effectively
Use the Situation-Behaviour-Impact (SBI) model. Describe the specific situation ("In yesterday's sprint planning meeting"), the observable behaviour ("you interrupted two colleagues and dismissed their estimates without asking questions"), and the impact ("which made others reluctant to speak up and undermined the team's ability to plan accurately"). SBI keeps feedback concrete and prevents it from feeling like a personal attack.
Deliver tough feedback in private, never in public. Do it promptly - ideally within 48 hours of the event, while context is fresh. Be direct but kind: do not soften the message so much that it gets lost, but show genuine care for the person's growth. After delivering the feedback, listen. Ask how they see the situation. You may learn something that changes your understanding. Agree on specific, actionable next steps and follow up in your next 1:1 to check progress. The best feedback conversations end with the person feeling challenged but supported, not attacked.
Remote Team Management
Building Trust Without Physical Proximity
Trust in remote teams is built through consistency, transparency, and intentional connection. Be reliable: if you say you will follow up on something, do it. Share context generously - remote team members miss the hallway conversations and overheard discussions that provide implicit context in an office. Write things down. Record key decisions and the reasoning behind them. Default to transparency about team priorities, organisational changes, and your own challenges as a manager.
Communication and Collaboration Patterns
Establish clear norms for synchronous and asynchronous communication. Not everything needs a meeting. Design documents, architectural decision records, and well-written pull request descriptions can replace many synchronous discussions while creating a searchable record. Use synchronous time for the things that genuinely benefit from real-time interaction: brainstorming, complex problem-solving, difficult conversations, and social connection.
Invest in social infrastructure deliberately. Create space for non-work conversation: a team channel for random topics, optional virtual coffee chats, and regular social events that are genuinely optional (not "optional but everyone attends"). If budget allows, periodic in-person offsites are invaluable for building the relationships that sustain remote collaboration for the rest of the year. Most importantly, measure outcomes not activity. Trust your team to manage their own time and focus your energy on providing clarity, removing blockers, and creating an environment where great work can happen from anywhere.
Related Guides
Frequently Asked Questions
- How do you manage an underperforming engineering team?
- Start by diagnosing whether the underperformance is a people problem, a process problem, or a clarity problem - the intervention is completely different for each. If individual engineers are struggling, check whether they have clear expectations, the right skills for their current role, and any personal circumstances affecting their work. If the whole team is underperforming, look at systemic issues first: unclear priorities, excessive context-switching, too much work-in-progress, or poor tooling that slows everyone down. Set concrete, measurable goals with short feedback loops (two-week check-ins rather than quarterly reviews), provide specific coaching on the gaps you identify, and document everything. Most underperformance resolves when you remove ambiguity and provide genuine support. If it does not, a structured performance improvement plan with clear timelines and success criteria is the appropriate next step.
- How do you handle conflict between engineers on your team?
- Address it early before it calcifies. Start with separate 1:1 conversations to understand each person's perspective without the pressure of the other person in the room. Often, conflicts that look personal are actually about ambiguous ownership, architectural disagreements, or communication style differences. Once you understand the root cause, bring both people together for a structured conversation focused on the specific issue - not on personalities. Set ground rules: speak about behaviour and impact, not intent or character. Your role is to facilitate, not to judge. Help them agree on a concrete resolution and follow up in subsequent 1:1s to check that the dynamic has genuinely improved. If the conflict involves harassment, discrimination, or bullying, escalate to HR immediately - mediation is not appropriate in those situations.
- How do you manage remote engineering teams effectively?
- Remote management requires you to be more intentional about everything that happens organically in an office. Over-communicate context: share the why behind decisions, write things down that you might have said verbally, and default to transparency. Create regular touchpoints - daily standups, weekly team meetings, and fortnightly 1:1s - but be disciplined about keeping them short and valuable so they do not become meeting fatigue. Invest in asynchronous communication: well-written documents, recorded Loom walkthroughs, and clear pull request descriptions replace the hallway conversations you have lost. Build social connection deliberately through informal channels, virtual coffee chats, and occasional in-person offsites if budget allows. Most importantly, measure outcomes rather than activity. Trust your team to manage their own time, and focus your energy on removing blockers, providing clarity, and celebrating wins publicly.
- How do you prevent engineer burnout as a manager?
- Prevention is far more effective than cure. Monitor workload distribution actively - burnout often starts when your strongest engineers quietly absorb more and more work because they are reliable. Watch for warning signs: declining code review quality, withdrawal from team discussions, cancelled 1:1s, increased cynicism, or a sudden drop in contribution after a sustained period of high output. Create explicit boundaries around on-call rotations, weekend work, and after-hours messaging. Protect your team from organisational chaos by being the buffer between them and shifting priorities - do not pass every executive request straight through. Encourage time off and model it yourself. Most importantly, make sure the work has meaning: engineers burn out faster on work they see as pointless than on work they find challenging but purposeful. Regular conversations about career goals, growth opportunities, and the impact of their work go a long way toward sustaining motivation.
Get Personalised Management Coaching
Navigating a tough team situation? Book a 1:1 coaching session to get tailored advice from an experienced engineering leader on your specific challenges.
Learn More