linkedin Skip to Main Content

6 Ways to Manage Your Software Engineering Team More Effectively

Engineering Management

Illustration of different people around a laptop

Managing an engineering team is no small task. To do the job right, you need to leverage technical expertise, develop leadership skills, create a system that enables your team to do its best work, and improve with each sprint.

Though that might sound like a lot to handle, you are likely already well on your way to building a high-performing software engineering team. In this article, we will share a few things seasoned engineering managers do to effectively manage their teams.

1. Get the right people on the team

The first (and most obvious) step is to ensure you have the right people on the team. 

Part of that comes from improving your technical interview process, and part of it comes from deeply understanding each team member’s strengths, gaps, and personal motivations. It’s also crucial to have a sense of the overall product roadmap and how the engineering organization needs to evolve over the next 9-12 months.  

Ask yourself six questions:

  • Do we have a good understanding of the product roadmap and vision?
  • Does my team have the technical background to execute against the roadmap—and if not, can we upskill, or do we need to hire for specific expertise?
  • Is our engineer to engineering manager ratio reasonable, or are we too top or bottom heavy?
  • Does the team need to be composed of primarily mid- to senior-level engineers, or can it have a mix of junior and senior software engineers? 
  • Do we have a well-defined, structured technical interview process that also deliberately assesses whether candidates fit the team’s values?

TL;DR Getting the right people on the bus is one of the first things a manager should do.

2. Align and define teams deliberately

Great teams almost always have a few things in common. They have a well-defined scope, operate independently, know how to interact with other teams in the engineering organization, are appropriately sized, and have a clear decision-making framework both within and across the eng org.  

When thinking about alignment, it’s helpful to recognize that there are four team topologies.   These are:

  1. Stream-aligned (most commonly a feature/product team)
  2. Platform teams
  3. Enabling teams
  4. Complicated subsystem teams.  

As the engineering org grows from a startup to a mature organization, the number and distribution of team types will change and each team’s scope will narrow.  For current teams, you might want to classify them by type, document their present scope, and determine if a change could help you manage more effectively or increase overall development velocity. Documenting scope can also clarify the boundaries and hand-offs between teams.

While thinking about sizing, Jeff Bezos’s golden rule on team structures offers a good heuristic. If a team can’t be adequately fed with two pizzas, then it’s too big. Depending on your developers’ appetites, that usually means around five to seven individual contributors per team. Will Larson, author of An Elegant Puzzle: Systems of Engineering Management, recommends having one engineering manager for every six to eight developers in order to coordinate, escalate, mentor, and coach. 

TL;DR Managing the team means defining the “team” and periodically evaluating the corresponding org design.

3. Find and eliminate bottlenecks

In order to manage effectively and make meaningful progress, you first need to take a step back and understand what places limits on your team. That’s where bottlenecks come in.  Bottlenecks (also known as constraints) are the factors that hold your team back. To better understand bottlenecks, it’s helpful to consider a framework called the “Theory of Constraints,” which paints a more holistic picture of your team’s most-likely challenges. 

Through the Theory of Constraints, engineering teams can act on the assumption that bottlenecks will occur and can therefore proactively bring them to the spring planning or product planning process to improve development velocity.

The simplest place to start is to look at your delivery lead time, the aggregate measure from ticket creation to in-production. You can also explicitly measure the cycle time between each stage in your JIRA or other workflow, then systematically tackle the longest cycle times.  In some cases, this could mean optimizing your CI/CD pipeline. In others, it might mean working more closely with Product Managers to better define requirements.

TL;DR Decide which delivery metrics matter most and then enable each team to eliminate their own constraints as a standard business practice. 

4. Maximize uninterrupted development time

We’ve all been there: You’ve found your flow and are starting to make real progress, then someone sends you a series of Slack messages and interrupts your train of thought. For your team, these interruptions are a massive drain on productivity. As an engineering leader, it’s up to you to be intentional about maximizing the time developers have to stay in the zone and, in turn, eliminate these types of distractions. So how can you best maximize uninterrupted work time?

Let’s start with meetings. A recent industry survey on developers revealed that over 35% of respondents see meetings as their greatest challenge to productivity.

Lengthy all-hands meetings and quick stand-ups alike can impede productivity, especially when they’re scattered throughout the day. To avoid this, managers need to conduct calendar reviews to understand when common “off times” might be and schedule accordingly. You can also encourage developers to block out windows of time in their day when they feel most “in the zone”—that way, there’s no chance a meeting will steal their attention and get in the way of deep work.

Then comes the challenge of communication—both on- and offline. While it”s true that, in a modern work landscape, a co-worker is always a message away, that doesn’t mean there need to be constant distractions. With digital communications, such as Slack, it’s up to managers to set a precedent for what a message really stands for. In actuality, Slack messages are akin to a tap on the shoulder—as such, you need to set boundaries for your team’s use of Slack and respect “do not disturb” as exactly that.

TL;DR Be deliberate about when your team meets and how they communicate to maximize uninterrupted development time.

5. Drive customer focus across the engineering team

To some, it may at first seem counterintuitive to put a technical team in front of customers. But giving developers first-hand experience dealing with customers does, in fact, bring tangible benefits. Some of these include:

  • Experience solving problems in real-time and learning to comprehend code written by others on-the-go
  • Boosting soft skills and helping to concretely conceptualize the software user’s experience
  • Assuring customers by putting them face-to-face (or, more likely, ear-to-ear) with software experts rather than sales representatives whose technical understanding may be foggy

In order to continually drive customer focus among developers, there are a few direct steps you can take. The first is to place your team on rotations between the support desk ticket and ticket resolution systems, giving them even more insight into customer issues and common holdups.

Aside from customer service integration, your team should also gain insight into how users are interacting with software. Two options to analyze this type of information are Hotjar and FullStory, which let anyone review metrics like time spent engaging with software and individual points of difficulty that users may be experiencing. 

Lastly, engineers should participate actively in the product discovery stages. This bridges the gap between what customers want to see in a product and what is, in reality, doable from the technical development side. 

TL;DR Get engineers as close to the end customer as possible.

6. Invest in engineering team culture

In the corporate and engineering worlds alike, the term “team culture” gets thrown around a lot—often without much context. It goes without saying that you should strive for your engineering team to have a positive working environment that not only boosts morale but fosters creativity and innovation. But how can you make it a reality?

A good culture doesn’t simply appear out of thin air. The first step for managers is to outline which values matter most for a team. 

For instance: Do you place importance on autonomy, collaboration, accountability, or, perhaps, letting employees follow their passion? When deciding upon values, you should collaborate with the whole team and be sure to hear everyone’s perspective so they reflect an accurate set of priorities.

One successful example of a software team establishing values comes from Gitlab. Gitlab prioritizes transparency and openness, and these ideas are prevalent all the way from how employees work together to how they communicate with higher-ups within the company. They also prioritize flexibility,  letting individual contributors make the call on where and how they work. 

Once you’ve put the building blocks in place to establish a team culture through values, it’s important to document them. This gets rid of ambiguity and allows your software development unit to implement the values for newer employees, too. When it comes to those responsible for hiring, clear documentation of values also gives you a chance to introduce these norms in the interview process. This serves to streamline onboarding and, further, offers a useful preliminary screening to understand if new employees align with a team’s mission.

Much like a software product itself, a company or team culture should evolve and iterate. One way to measure—and subsequently improve—culture is through eNPS, or employee Net Promoter Score. Using eNPS allows you to have a metric for employee satisfaction, and, after collecting survey results, you can plug this insight into future planning.

In addition to formal tools for measuring employee satisfaction and productivity, managers also need to foster an environment that is open to feedback. You should make eNPS results public and hold discussions with the team to better understand what works, what doesn’t, and let individual contributors voice their opinions on how the culture can be modified to facilitate better outcomes.

TL;DR Don’t forget about nurturing your engineering team culture.  This is the key to hiring and keeping the right people.