Managing a software development team means coordinating technical work, removing blockers, and creating an environment where engineers can ship quality code consistently. The role is less about writing code yourself and more about aligning people around clear priorities, establishing processes that reduce friction, and helping each person on the team grow. Whether you’re a first-time engineering manager or looking to sharpen your approach, these are the core areas that make the difference between a team that delivers and one that spins its wheels.
Pick a Workflow That Fits Your Team
Before you can manage the work, you need a shared system for how work moves from idea to production. The two most common frameworks are Scrum and Kanban, and choosing between them depends on how predictable your team’s work is.
Scrum organizes work into fixed-length sprints, usually one to four weeks, with a clear start and finish date. Each sprint has a defined set of ceremonies: sprint planning at the beginning, a daily standup (a short check-in, typically 15 minutes), a sprint review to demo what was built, and a retrospective to discuss what went well and what didn’t. Scrum also defines specific roles. A product owner manages the backlog and represents the customer. A scrum master keeps the team grounded in the process. The development team collectively decides what they can commit to within a sprint. This structure works well when your team builds discrete features and benefits from a predictable rhythm.
Kanban takes a different approach. There are no sprints, no prescribed meetings, and no required roles. Work flows continuously through columns on a board (typically “To Do,” “In Progress,” “Done”), and the team limits how many items can sit in any column at one time. That limit, called a work-in-progress (WIP) limit, prevents the team from starting more than they can finish. Kanban suits teams that handle a mix of feature work, bug fixes, and support requests where priorities shift frequently.
Many teams blend the two, running sprints but using a Kanban board to visualize flow. The framework matters less than the consistency. Pick one, run it for a few months, and adjust based on what your team tells you in retros.
Define Clear Priorities Every Week
The fastest way to slow down a development team is to leave engineers guessing about what matters most. Your job as a manager is to make sure the backlog is ordered, not just populated. Work with your product owner or product manager to stack-rank upcoming work so that when an engineer finishes a task, they know exactly what to pick up next.
This means saying no to things. If everything is a priority, nothing is. Protect your team from context-switching by batching requests and pushing back on “urgent” work that isn’t truly urgent. When a genuine emergency does come in, be transparent about what gets displaced. Engineers handle interruptions much better when they understand the tradeoff being made.
Measure Delivery, Not Activity
Lines of code, hours logged, or tickets closed per day tell you almost nothing about whether your team is healthy. Better signals come from outcome-based metrics. The DORA research program identifies five metrics that reliably indicate software delivery performance:
- Change lead time: how long it takes a code change to go from committed to deployed in production.
- Deployment frequency: how often the team ships to production.
- Failed deployment recovery time: how quickly the team recovers when a deployment breaks something.
- Change fail rate: the percentage of deployments that require immediate intervention, like a rollback or hotfix.
- Deployment rework rate: the percentage of unplanned deployments triggered by production incidents.
You don’t need to track all five from day one. Start with deployment frequency and change lead time. If your team deploys once a month and each change takes three weeks to reach production, that tells you there’s friction in your pipeline worth investigating. These metrics work best as conversation starters in retrospectives, not as individual performance scores. The moment you tie them to someone’s review, people will game them.
Protect Time for Technical Debt
Every team accumulates technical debt: shortcuts in the codebase that speed up delivery now but slow it down later. Left unchecked, debt compounds. Builds get slower, bugs get harder to trace, and onboarding new engineers takes longer.
The Carnegie Mellon Software Engineering Institute recommends that teams track the percentage of resources allocated to managing technical debt per sprint or iteration and keep that effort visible in the backlog alongside feature work. The critical step is protecting that allocation from pressure to focus only on new capabilities. If technical debt items are always the first to get cut when a sprint gets tight, they’ll never get addressed.
A practical approach is to reserve a consistent slice of each sprint for debt work. Some teams dedicate one out of every five or six sprints entirely to maintenance. Others mix debt items into every sprint. The method matters less than the commitment. Make the debt visible on your board, treat it as real work, and review it regularly.
Build a Feedback-Rich Code Review Culture
Code review is where technical quality and team culture intersect. Done well, it improves code health and helps engineers learn from each other. Done poorly, it creates bottlenecks and resentment.
Google’s engineering practices offer a useful standard: reviewers should approve a change once it clearly improves the overall health of the codebase, even if it isn’t perfect. There is no such thing as perfect code, only better code. Requiring authors to polish every detail before approval slows everyone down and demoralizes the person whose work is being reviewed.
Encourage reviewers to distinguish between blocking feedback and minor suggestions. A common convention is to prefix optional comments with “Nit:” so the author knows they can take it or leave it. This small habit dramatically reduces friction. When disagreements arise, ground them in technical facts and data rather than personal preferences. For style questions, defer to your team’s style guide. If the style guide doesn’t cover it, accept the author’s preference.
When a reviewer and author can’t reach consensus, have them talk face-to-face or on a video call rather than going back and forth in comments. If they still disagree, escalate to a broader team discussion or ask a technical lead to weigh in. Document the outcome on the pull request so future readers understand the decision.
Run Effective One-on-Ones
One-on-ones are the most important meeting on your calendar. This is where you learn what’s blocking your engineers, what’s frustrating them, and what they want to work on next. Hold them weekly, for 30 minutes minimum, and treat them as the engineer’s meeting, not yours.
Resist the urge to use this time for status updates. You can get status from your board, standups, or async check-ins. Instead, ask questions like: What’s the hardest part of what you’re working on right now? Is there anything slowing you down that I could help remove? How are you feeling about the team? These conversations surface problems weeks before they show up in your metrics.
Take notes and follow through. If an engineer tells you they’re frustrated by flaky tests and you do nothing about it, they’ll stop bringing problems to you. Your credibility as a manager is built entirely on whether you act on what people tell you.
Create a Clear Growth Path
Engineers leave teams when they feel stuck. A well-defined career ladder gives people a map of where they are and what they need to develop to advance. Typical engineering ladders include tiers like associate engineer, mid-level engineer, senior engineer, staff engineer, and principal engineer, with a parallel track for people who want to move into technical leadership.
At early levels, expectations center on being able to contribute to team work without constant guidance: writing solid code, participating in code reviews, understanding the team’s product and codebase, and practicing test-driven development. Senior engineers are expected to choose specialty areas and influence technical direction beyond their immediate tasks. Technical leads add responsibilities like building psychological safety on the team, assessing the skills of other engineers, removing impediments, and conducting technical interviews.
Publish the ladder so everyone can see it. In your one-on-ones, reference specific skills from the ladder and help engineers identify concrete projects that let them practice at the next level. Promotion should never be a surprise, either to the person getting promoted or to their peers.
Manage Communication Deliberately
Software teams drown in communication when it isn’t structured. Slack messages, email threads, meeting invites, and ad-hoc questions can fragment an engineer’s day into chunks too small to do meaningful work. Research on developer productivity consistently shows that uninterrupted focus time is the single biggest predictor of output.
Set norms around communication. Designate core focus hours where the team is not expected to respond to messages. Move decisions out of synchronous meetings and into written documents when possible, so people can review on their own schedule. Use standups to surface blockers, not to give paragraph-long updates that could be a Slack post. If a meeting doesn’t have an agenda and a clear purpose, cancel it.
For distributed or hybrid teams, async communication becomes even more important. Record decisions in a shared wiki or project management tool so that someone in a different time zone doesn’t miss context. Over-document rather than under-document. The five minutes you spend writing up a decision saves hours of repeated explanations later.
Shield the Team, but Stay Transparent
Part of your job is absorbing organizational noise so your team can focus: shifting priorities from leadership, cross-team dependencies, political dynamics. But shielding doesn’t mean hiding. Engineers are smart, and they notice when something is off. If the company is restructuring, a product direction is changing, or headcount is frozen, share what you can as early as you can. People handle uncertainty far better than they handle finding out their manager knew something for weeks and said nothing.
When you relay decisions from above that the team disagrees with, own the message. Saying “leadership decided this, not me” erodes trust in both directions. Explain the reasoning, acknowledge the tradeoff, and focus the conversation on what the team controls.