Six things to consider when structuring engineering teams

Are you organizing or reorganizing engineering teams? Here are some best practices to keep in mind.

For evolving software organizations, change is the only constant. These changes come in different shapes and forms, perhaps as a result of a new business strategy, an opportunity to scale, a need to address gaps, or an attempt to save a ship from sinking.

As leaders, we need to evaluate our organizational structures regularly to ensure that they are geared for long-term success. But how can we know if and when a change is needed? What are the key areas to focus on when planning and driving structural change?

In this article, we’ll share six important factors to consider while organizing or reorganizing engineering teams, and how to communicate that change.

1. Identify dependencies and ownership

Dependencies are a vital consideration when organizing teams. If your teams are wasting time waiting on dependencies and it’s impacting their velocity, it’s important to dig in and understand why. For example, is there a difference in priorities within or between teams that’s impacting the level of commitment? In this case, your current team structure might be the problem.

You could create teams that are either aligned on software services (service-based ownership), or on the basis of their products or features (product-based ownership). In a service-based ownership model, teams have a clearer and independent charter. They spend more time learning their services, which results in a level of expertise and ownership. In a product-based ownership model, teams normally work on various services to achieve a common goal. In this case, the service ownership boundary can get blurry, potentially preventing teams from having a true sense of service ownership.

Talking in terms of dependency, both models have a dependency element associated with them. In the case of service-based ownership, teams rely on each other to deliver on their parts to effectively make a final feature run end to end. This can cause slowdowns if the teams have different priorities. That’s why it’s highly recommended that teams consider at least one single-threaded owner who can drive them towards their goals.

In the case of feature-based teams, there are fewer dependencies and teams can deliver on features more independently. However, there might be multiple teams working on the same service at the same time. The software codebase needs to be ready to handle multiple team members working in parallel as well as simple enough for team members to understand and contribute to. Also, it’s important for teams to identify their customers and have the ability to deliver features independently. Leaders need to limit the size of their features so that team members do not feel overwhelmed with breadth of knowledge.

Teams should evaluate the pros and cons of each of the above approaches, or even adopt a hybrid service/feature ownership model depending on their situation and goals.

2. Assess your organizational readiness

Is your organization ready to undergo structural change? As leaders, we need to set baseline expectations and understand where we stand before developing plans to move to the ideal state. When it’s time, those plans should be driven by clear and measurable success criterias.

Although it’s not always possible to get the perfect baseline before re-organizing teams, it’s essential to align with other leaders on key priorities before restructuring. For example, does your software stack have the right software architecture? Could you organize teams before having a perfect software architecture? The software architecture might not be best to start with, but the most important thing is that leaders are aligned and in agreement with the organization around current and expected final state.

Along with architecture, we need to consider how operational readiness and toil fits in. If new teams are formed, will they have a balanced operational load? Will the operational load be heavy initially but normalize over time? It is important to determine what percentage of the team’s time will be spent on day-to-day operational activities, such as keeping the lights on, compared to longer-term improvements.

3. Establishing team balance

Great teams have a balance of strengths and weaknesses across teammates, as well as breadth of industry experience.

Before you organize your teams, are you aware of the strengths and weaknesses of your talent distribution within your current structure? If not, what steps are you taking to measure team balance? Aligning on company principles is a good way to start assessing the team as a unit. Here are a few examples of things you might want to keep in mind:

• Do you have a good mix of engineering skill sets across teams, for example, a backend engineer, a data engineer, a designer, and a systems specialist? Are there skills gaps in any teams?
• Is there a strong level of diversity in each group?
• Do you have a mix of individuals who are talented and passionate not only about coding but also about quality?
• Do you have folks invested in DevOps as well as team productivity? 
• Do you have a mix of engineers who like structure in place as they scale?
• Do you have individuals from different backgrounds?

Try keeping a document with a prioritized list of strengths, and an overview of the current and ideal states. This document will be useful in understanding and recommending team changes for individuals, especially when new teams are formed or when individuals are transitioned between teams. It will also help in hiring decisions for new and existing teams.

4. Location matters

Organizational changes, and the desired goals of those changes, also require considerations about where and how people will work. Will you adopt a fully distributed model or take a co-located approach?

The benefits of a fully distributed model include enabling workers with disabilities or family and child care needs to fully participate in the workforce, delivering value and unique perspectives. Forbes reports that remote workers are 20% happier, which can help with talent retention and overall company culture. A company that is growing internationally may find it easier to serve and support international users with a distributed workforce. If this is the case for your team, a distributed workforce might be worth considering.

In work environments where relationships are paramount to the success of the business, a hybrid or even fully co-located office can help achieve these goals. Organizations with growth goals that revolve around quickly building strong, high-trust relationships should consider if having their team co-located makes sense. Co-located teams have different opportunities for collaboration and communication, and can build higher levels of trust and interdependence based on the frequency of interpersonal interactions.

5. Be ready to scale

If you’re reorganizing, it might be because the business is doing well and you need to scale and change the team structure. But how can the team grow smoothly and successfully?

To make sure you are ready to grow your team before you need to hire more people, think carefully about all the systems that you need to attract, hire, and retain the talent you want for your team.

First, ensure that you feel great about your recruiting process, and that you have strong and well-articulated goals for attracting underrepresented candidates to apply for your roles, since research shows that these candidates are less likely to apply to roles for which they are qualified.

If you feel your hiring process is not as robust as possible, work with your recruiting team to put fair interviewing processes in place, such as question banks, interview rubrics, and interview and bias training for any team members who will conduct interviews. These efforts help ensure that all candidates have a consistent and fair experience, and are evaluated on their skills and abilities.

Once you have your new team members, have a strong onboarding program in place to help them get settled, happy, and productive. Onboarding should include everything from the standard company onboarding, to more team-specific onboarding. For the best possible experience, work to support any of your existing team members who will be participating in the onboarding process.

Finally, make sure that as a leader, you are aware of and actively promoting the professional development opportunities that are available to your team (and to you!). By doing all of these things and thinking about scaling holistically, you can grow a robust team, quickly, even in a competitive market.

6. Set timelines

Before your organization executes on any structural change, leaders must clearly communicate the change. Get aligned with other leaders and your own manager around who will be delivering the message and how.

Like every successful project, the communication around any organizational change should have a timeline:

• First, leaders should clearly document the changes including team charters, vision, expectations, and reasons for change.
• Thereafter, depending on the situation, leaders should work with existing teammates to understand their motivations and help match team members within the new organization.
• Once this has been done, leaders should ensure a smooth transition for any staff requiring a change in manager.
• Thereafter, if the situation demands setting up new team processes, leaders should document a prioritized list. Each team should have a definition of success and expectations.
• When the change is underway, leaders must communicate progress and final goals to team members.
• Once engineers are placed in their final teams, each team will drive their own team processes, as well as adhere to some basic mechanisms for the entire organization.

Reflections

Once you’ve set any change in motion, it’s very important to assess the health of the organization from time to time. In addition to checking if the engineering organization is delivering its goals, don’t forget to assess the morale and health of your teams. Without a happy and committed team, it’s impossible to call an organization successful.