Four years ago, I wrote an article on the different ways one could structure their software engineering teams. The article turned out to be rather popular and it’s one of my most viewed articles.
Since then, I have had to rapidly scale teams from zero to 50+ software engineers four times across organisations like Facebook and the OVO Group. I have learnt a lot and I now firmly believe that there’s only ONE way to structure an engineering team.
Build teams around products
Gone are the days when products were built using Waterfall and new versions came out every few years. Today, many companies do continuous deployment where software is updated multiple times a day.
Speed to market has become the #1 differentiator of a successful company. How then, can you create that speed?
By intentionally building teams around products (or micro-products) with all the functions needed for the product to succeed within the team. For instance, if one was building a simple app, the ideal team could contain the following functions,
- Software Engineering — to build the product.
- Product Management — to help prioritise what gets built next.
- UX — to shape the user journey within the app.
- Design — to make the app look good.
- Data Science — to provide feedback on what’s working, what isn’t and inform the product direction.
Why build teams around discrete products
When you build a team around a product, a number of wonderful things happen,
1. Team gains autonomy
Once the goals and metrics are set, The team is empowered to make decisions as long as the decision moves the metric in the right direction. Almost all decisions can be made within the team without going to an external stakeholder, reducing turnaround times. The team also makes better decisions as context isn’t lost between the team and an outside decision maker.
2. You build better teams
When people are working together for a while, they learn to work more effectively as a team. They develop trust and learn each others strengths and weaknesses. They have each others backs and stick with each other through times good and bad. This team not only is better able to predict their delivery but remains together for longer with lower attrition. (As a manager, you are responsible for creating a balanced team with people who complement each other)
3. Team has ownership and feels accountable
With this structure, the team feels complete ownership of the products they have built. They aren’t just building a component and passing it on to another team, like an assembly line, but are building the whole product. The team starts to really care about their product — it becomes their baby. This change in mindset not only improves quality and the speed at which things are delivered
Where do you begin?
If you are a large company and your teams aren’t organised in some kind of a pod structure, this is going to be a hard transition. It may be easier to seed this structure on a greenfield product.
There are three things you need when building a team around products,
1. Set goals and metrics
Be clear on the outcome you want the team to achieve. Then create metrics that help track against that outcome. Set intermediate goals or milestones. Be sure to take your team on the journey so they don’t feel that the goals have been top-down. You want a team that feels in control of its destiny. Let them be a part of setting it.
2. Hire the right people
It’s ultimately people who will drive this and make it successful. You need to ensure that the team is balanced with the right archetypes and skills needed. These factors change with the stage of growth you are in and the nature of product you are building.
Importantly, keep your teams small. I’d say the ideal size is 6 people with about 3–4 developers. Any more and decision making suffers.
3. Get out of the way
Most importantly, let the team run with the goals. Let them choose the what and the how of what they want to build. Tempting as it may be to step in, you hire smart people so that they can tell you what to do and not the other way around.
Your role as their manager changes and you will spend a lot more time on the people side, ensuring that the team has all the resources it needs to be successful and that they have autonomy in decision making. You will also be focused on ensuring that the outcomes and goals remain consistent with the rest of the business over time and that the metrics still help you track against those outcomes.
If you are running software engineering teams, and don’t currently run a pod structure based around products, do give it a go. It creates happier motivated teams which deliver better software with better predictability, reduces collaboration and management overhead ultimately leading to better business outcomes.