Just like in sports, successfully leading a software development team takes strategy.
You’re recruiting top talent, calling the shots, and coaching the team through them. But one strategic piece that often gets missed is team structure. Even with the best players out there, your team can’t win if they can’t agree on who’s playing what position.
Having a clearly defined team structure helps leaders build accountability and ownership, so that teams can build faster, scale better, and launch winning, quality products.
So what does a winning development team structure actually look like? And how can you set your team up for success?
Let’s start by exploring the most common team structures. It’s important to note—these approaches aren’t necessarily mutually exclusive. For instance, you might have a triad leadership structure but have specialist and generalist engineers within the team.
Then, in the sections below, we’ll talk about how to choose which is right for your team.
These days, most software development teams follow some take on the “triad structure” — which unites three core competencies: design, eng, and product.
Generalist development teams include folks with broad skills and experience, who can handle the end-to-end development of a feature or product.
Each team member is responsible for implementing features as a whole, which means fewer blockers and dependencies, but sometimes slower launch times as teammates work on tasks that may be completely new to them.
This is a common approach for smaller companies, brand new features, or on teams looking to invest in their talent, upleveling with new skills and competencies on each project.
On a specialist team, each team member is an expert in a certain programming language, technology, or framework, and is therefore responsible for that part of development.
Depending on the scope of the work, you may have multiple specialists and hierarchy in each area of expertise.
This approach can sometimes provide faster development, since many pieces can be completed simultaneously, but can lead to waterfall-like practices which create gaps in communication when different specialists don’t speak each other’s lingo.
There’s also a high level of dependency on certain folks to get things done, and more coordination required.
This approach is a mix of the two above—with some team members being generalists who can focus on the product as a whole, and others being subject matter experts in one specific area.
This flexible team structure helps maximize efficiency, but can be most costly and time-consuming to build.
Here at Range, we follow a hybrid, triad structure. Read more about how the Range team is structured.
Many larger companies chose to structure their product development teams around their key business units or initiatives. Under this approach, teams typically operate as their own unit within the company, with the triad of product, design, and engineering.
On matrix teams, managers are in charge of people management only—not product leadership. Product teams (often called tribes) set goals and pursue them on their own, with leaders serving a distinct coaching role external to the team. This requires strong communication to work effectively.
When it comes to choosing which structure your team will follow, it’s never one size fits all. What works best for some teams might not be the right fit for others.
To land on your most effective structure, experts recommend starting with a list of top business or org outcomes. Once you align on what’s most important, it can become a lot easier to see how to organize a team in order to achieve that.
Some example business outcomes:
For instance: If your top priority is minimizing dependencies, a generalist structure where each engineer handles end-to-end development might be your best option.
Looking at your team’s current makeup and interests can also be an effective way to staff certain projects.
“I've had success structuring teams based on staffing and peoples’ interests. Like if you have a lot of competent junior folks chomping at the bit for more impact, it can work well to give them ‘project lead’ roles and have some supervision from a more senior tech lead. But that may be less feasible if you're looking to roll out one structure across hundreds of people.” — Jean Hsu, VP of Engineering at Range
Another layer of complexity when it comes to structuring your team, is that not every project will be (or should be) staffed the same.
When kicking off a new project, consider the following to help determine your structure.
As more teams move to remote and hybrid ways of working, eng leaders have new considerations to take into account when it comes to team structure.
“It's not easy to do products remotely. Product development is naturally very collaborative in nature. A lot of that doesn’t translate really well to online or remote work.” — Katie Wilde, VP of Engineering at Ambassador Labs
There are workarounds to help make remote development more effective though.
For instance: On fully remote teams, limiting the location of teammates to 1-2 time zones is starting to become more of a norm.
“Seattle to SF can collaborate more easily than SF to London. When you’re more spread out, there’s more informal communication, which leads to uneven levels of context and trust.” — Dan Pupius, CEO and Co-founder of Range
For hybrid teams, having some teams that are all in-office and some that are fully remote is becoming a common path too.
Now that you’ve got a few different models for team structure and staffing in mind, let’s review the typical roles and responsibilities within a software development team. Here are your key players.
The product owner deeply understands (and is responsible for) the project at hand. They’re familiar with requirements, limitations, user needs, and trends that might shape the work, and typically own the vision for what the final output should look like.
The eng manager oversees the engineering team’s work, and is responsible for project planning, scoping, implementation, and tracking progress throughout the development cycle. While they don’t usually code themselves, they’re typically experienced developers who can help the team troubleshoot different routes when issues arise.
These are the people responsible for actually coding the software. Front-end developers work on the visible elements and back-end developers handle the functionality of your product.
Your designers are responsible for how users experience and interact with your product. UI designers are responsible for the user interface—your product’s look and feel. UX designers focus on how user’s will interact with it, suggesting improvements to the experience that make your product easier to use. Design typically includes visual and interactive elements, as well as the words and content within the experience.
This is the teammate responsible for defining the complete architecture system of a project. They describe technical and functional aspects of the software and work with developers to build its components throughout the development cycle. They’re part leader, part programming expert.
Your QA (quality assurance) engineer makes sure products launch with a high bar for quality. Their role is about more than just bashing bugs, it’s more holistic—they work to understand the processes used to develop the software and suggest improvements that’ll bring higher quality and functionality to the final product.
In software development, the business analyst helps clarify the business need, analyzes the data behind it, and translates it into clear technical requirements for the development team to tackle.
Your team’s size has a direct impact on its productivity and effectiveness. For software development teams, experienced leaders say groups of 5-9 tend to be most effective. Once you grow larger than that, things like standups and updates tend to feel less relevant to the entire group and it’s probably a good idea to split into concrete sub-team groups.
“For example, if you have a team focused on core products and another on new experiments, it may be helpful to split the teams. However, be intentional in communicating team re-orgs because people sometimes can feel trapped or like there isn't mobility between teams, which can be problematic.” — Jean Hsu, VP of Engineering at Range
For manager/direct report ratios, most leaders agree that seven is the magic number. Though this might vary depending on factors like team location, seniority, and other manager responsibilities.
“Our workstreams, our weekly check-ins, all of that stuff is basically up for change every quarter. I have the team participate to make sure the process we’re creating actually works for everyone. ” — Kate Heddleston, Senior Engineering Manager at Samsara
How you organize your team will provide direction and structure, but it’s never set in stone.
As your org grows or priorities shift, you’ll want to reevaluate what approach is most effective and empowering for your teammates. Just as you evaluate your processes and goals on a regular basis, consider building a quarterly or annual cadence around reevaluating teams, sub-teams, and workstreams.
Are they still serving their intended purpose? Or would another approach be more impactful?