Building Product and Engineering Teams — Part 2
In part 1, I spoke about a model to build teams in the tech industry. I talked about 3 concepts in this post — the concept of organizations, functional areas within organizations and autonomous teams that are formed out of organizations. The diagram below should be familiar.
Also, remember the composition of an autonomous team. It has all the roles to be able to ship a product end to end.
In this post, we will specifically talk about building teams and how modern tech companies can think of scaling these teams based on the product they are building.
Starting Off
Lets consider the evolution of a typical web product (mobile is similar). Most web apps start off as a monolithic or with a simple 3 tiered architecture. Also these organizations normally start off with 1 team working on the entire stack.
As usage keeps increasing, requirements keep increasing. As requirements keep increasing, more features need to be added and existing features need to be supported on production.
This is probably the first phase where you’d start thinking about creating more than one team.
Remember the concept of an autonomous team from Part 1- A team should be able to ship a product end to end without the need to depend upon schedules or APIs or anything from other teams. They should be able to deploy and support their product end to end on production.
So with that being said, a good split as you grow would be as follows:
Start splitting parts of the platform that are common and can support a range of apps on the frontend. The web apps team can work on customer facing features, managing their service and data with a loosely coupled dependency on these “common services”. An example of such a common backend services would be: “Search” or “Personalization” or “Email”.
Question
You might ask — why does a web app team even work across the entire stack? Why can’t we have a bunch of service teams and a web application team?
Sure. If you don’t need your own service and you can support yourself completely by calling into services of other teams without the need to go down the stack yourself, then you come up with a structure as below. However, at times the web app might need to manage its own data so it should be able to have the ability to have its own end to end stack.
Growing
Now you’re going to grow even more. You’ve realized the need to have many more such services in your organization and now your web app teams are expanding as well. You don’t have a single web app, but your core experiences are split into smaller web apps. Going forward a web app team will be represented as a single circle (but do know that it could involve an entire stack to manage some local data).
Further Growth — Platforms
Now you’ve realized that you might need to add in platforms to your architecture. For example: There might be common elements on the frontend that deserves its own team or you might other areas like a master database that needs to be managed or you might have a special cross functional security, performance teams.
Where is Mobile?
You should be able to answer this now. Yes, build a mobile team to interface with your services, but at the same time be able to do some of their own logic.
Pattern
Note the pattern since we started. As we grow as an organization, we’re taking out commonalities in our architecture and we’re building out teams to support them.
The core principle remains the same:
Teams are Small and Autonomous. They have all the elements needed to ship a product end to end without or with minimal dependencies on other teams.
Microservices
While we’re at this topic, I’ll talk about the concept of microservices. Microservices are services (end to end from service to data) that serve a single business purpose.
An autonomous team works on a microservice that can be consumed by other microservices or other web apps. Each microservice can be deployed and managed independently as we’ve discussed.
Spotify is a great example of a company that has promoted the use of microservices in their engineering organization. You can read a presentation (http://gotocon.com/dl/goto-berlin-2015/slides/KevinGoldsmith_MicroservicesSpotify.pdf) and watch a video about the same here:
Conclusion
In my experience, and in this modern day and age where applications are complex, have massive usage, have to scale quickly, have to be deployed and managed quickly, the use of small autonomous teams and using microservices is the way to effectively scale. Each team is independent and should be able to ship a product on their own without the need of dependencies on other teams. Keeping this rule in mind and overlaying that on top of your architecture will help you effectively scale your engineering organization.
