It may seem handy to have a full stack team that can do it all, but beware of being too prescriptive early on.
Developers are liable to carry titles like backend engineer, senior data engineer, or staff infrastructure engineer as important elements of their identity.
As managers, it can be easy to fall into the trap of treating people like interchangeable pieces on an org chart. A common staffing exercise is to put together full stack product teams consisting of back- and front-end engineers, product management and a designer. In later years we have expanded our view on building engineering teams to use terms from the popular Team Topologies framework, such as stream-aligned teams and platform teams.
Understanding and staffing typical teams with standard roles provides a good baseline for any engineering organization. But engineering doesn’t happen on paper or in a vacuum. Instead, you should go beyond thinking about typical teams to consider:
- The problem to solve. Understand the specific expectations of a given team and what kind of work they will be doing.
- Going beyond roles. Look at the skills, experience, traits, and interests of the people that will be part of the group.
- Adjusting over time. The best teams stay together long enough to become highly productive but know how to evolve, grow, shrink, or split as things change.
And as a team member, always think about what you bring to the team beyond your core skills. How do you enhance the rest of the team?
Figure out the business problem and architecture first
At their best, full stack product teams remove silos, feel empowered to own their problems, and bring developers and operations closer together in a devops culture for your organization.
I was working at Spotify during peak full stack hype. Even then we had big infrastructure, data, and developer experience organizations to support these so-called full stack teams. To quote my manager at the time, the answer to the question of whether you should go with full stack teams is: “it depends”.
Full stack teams work really well for scaling products and doing iterative improvements. In my view they can be slow at product discovery, as it is very easy to start too big or wait to have all the right skills in place before trying things out. As full stack teams tend to own a specific business problem, there are also tendencies that they lock in on a problem and stay with it too long.
My view on teams today is similar to the weekly set of recipes I use when cooking for the family. You have your staple dishes that work well any day and are hard to beat when you get them right. These are full stack product teams paired with some central platform and developer experience capabilities as you scale. Anything beyond that is a snack, that nice birthday dinner, and days when you are in a more experimental mood. These additional options could be small product discovery teams working really close to the users, or a tiger team of some of your best people getting together for a couple of months to solve a tricky technical migration.
The team will change with the mission
Looking back at teams I have built, it’s important to identify the different needs at different stages during a product’s life cycle. Early stage teams tend to be smaller, with people that like quick prototyping and work around blockers to try things. The best versions of this team I have seen focus less on exact skill sets and roles and instead focus on the problem to solve. In order to scale a product that comes out of such a team, adding an experienced “anchor” engineer who can draft plans for the future is a good idea.
As the product matures, stream-aligned or full stack teams start to make sense. I have seen many examples of adding in more specific skills around the anchor engineer to create a devops product team. With a couple of these it starts to make sense to also build platform teams that can support infrastructure and other shared tasks.
Go deeper than resumé roles when staffing
In a high growth organization it’s easy to take the shortcut of simplifying people to roles. Instead, I would advise setting aside time for 1:1s, creating growth plans and understanding who you are working with. This investment will pay off and help avoid building an unbalanced organization.
Two other traps to look out for:
- Over indexing on deep front-end skills in a team delivering data products. A less experienced and more cautious back-end engineer in the team was not able to influence direction enough and the early product ended up being a beautiful view of incomplete and incorrect data. Only after adding strong data engineering skills did we realize that a more simplified view of the data would suffice.
- Hiring more of the same in a platform team. The team operated with a very technical manager and the first couple of engineers had very deep networking skills. As they grew they added more engineers with a very similar profile creating a team that did not complement each other and struggled with tasks outside of pure networking.
The full answer is still to be written
Understand what your team’s mission and success looks like. Why do we put together a team to start with? Then be flexible about the exact set up. There are plenty of templates to use and most of the time one of them will work, but that does not mean it will all the time. Adjust based on where you are in the product life cycle, who your people are, and the technologies involved.
I have gotten it wrong a few times and right a few more times, I hope. It helped a lot to learn about product thinking, team structure, engineering roles and our underlying technologies. Then spend the time to understand the strengths of the people in your organization to build a team fit for the problem to solve.
