Since starting Lumen5 in 2017, I’ve been a part of hundreds of interviews for our engineering roles. One of the most common questions that candidates ask is some variant of “what kind of work does my team do?”. This is a simple question, but it’s something that I’ve put a lot of thought into as we craft our engineering teams.
At Lumen5, the kind of work that each of our engineering teams does is dictated by what we’ve formed our teams around. In my opinion, there are two common options around which to build teams:
- Technology Teams
- Product Teams
In this blog post, we’ll explore these two models from the perspective of a fictitious company that is building an Instagram clone. We’ll call our company Instaclone! We’ll also discuss the engineering team structure at Lumen5 and why we’ve chosen to organize teams this way.
Technology Teams
Definition
In a Technology Team model, engineering teams are built around specific technologies. As a business grows and develops more technology, teams naturally continue to be structured around the key areas that are being developed.
As a start-up, Instaclone would have two teams: a backend team and a mobile application team. As Instaclone grows, we’ll hire more engineers and start splitting out teams dedicated to the technology pieces that we’re building. We could launch an Android team, an iOS team, a dev tools team, a database team, a computer vision team, and so-on.
Pros
In a company with Technology Teams, it’s easy to make decisions about architectures and dependencies. For example, if there’s a decision about whether or not to upgrade the backend web framework, that’s easy — the backend team can decide! No one else is affected.
Technology Teams are often motivated to improve the core underlying technology. Usually, on these teams, technological excellence is valued, and technical experts within specific domains flourish. For example, on Instaclone’s backend team, backend engineers that really know the web framework will thrive.
Cons
However, the focus on technological excellence may come at a cost! On Technology Teams, product goals and user experience may be deprioritized in favour of further technical development. This can lead to suboptimal end-product quality, which can be a severe issue for a product company. At Instaclone, our backend team might be so focused on improving the backend code quality that they deprioritize creating functionality for a new feature that users have been asking for.
Additionally, for an idea to be transformed into a feature that gets shipped to users, it must often pass from one team to another. This leads to a series of handoffs, which can be expensive.
In the most basic scenario, there are only two teams (a backend team and a frontend team), and a simple new feature is being created. The two teams must plan together how the feature will work ahead of time, and then the backend team will take a sprint to implement the backend.
The backend team can hand off the feature to the frontend team, communicating how the API works, and finally, the frontend team can finish the feature in the subsequent sprint. If everything goes smoothly, a feature will take a minimum of two sprints (usually four weeks) to develop.
If there are complications, miscommunications, or delays, the feature will take even longer to come to fruition. As there begins to be a greater number of teams, more inter-team communication is required and the process gains complexity. This is because the teams are tightly-coupled.
A simple example — a feature going through the Backend Team to the Frontend Team and then shipped to users. This can be done in 2 sprints: one sprint from the Backend Team, and one sprint from the Frontend Team.
The above example shows where a feature requires database changes from a separate team, a Backend API, and implementation in three different frontends. There is a shared dependency (for example, a component library) between the iOS and Android Teams that also requires updating. The number of handoffs here means that this is going to be a very complex project and very difficult to execute efficiently. In the best case (no delays or unforeseen events), it will take a minimum of 3 sprints to release a feature, if not 4, for the shared dependency update.
Product Teams
Definition
The second organizational model forms teams around dedicated areas of the product. If the company has multiple products, a team can be organized around each offering. If the company has a single product, the team can be organized around different features inside the product.
For Instaclone, we would have a Stories Team, and a Profile Page Team, among many other feature-specific team examples.
For a Product Team structure to work, the team needs to have end-to-end ability to build and deliver a completely new feature. Instaclone’s Profile Page Team needs the ability to write code on the backend and frontend (including mobile) and requires the ability to maintain their own CI/CD and infrastructure. Because of this, full-stack generalists tend to shine on Product Teams because they can move freely through any part of the stack to develop a feature from start to finish.
Cons
Often, technology decisions are more complicated within an organization made up of Product Teams. For example, suppose there is a question about updating the backend web framework to a newer version. In that case, it’s difficult to get consensus because there are backend engineers on many different teams are affected. In this way, technology is more shared across teams, rather than developed by a single, dedicated team. In cases where the technology is especially critical or complex, this can be prohibitive.
Pros
However, this also means that the team’s emphasis shifts to product excellence (rather than technological excellence). The teams are organized in a way where the focus is put solely on developing a good end product for users.
Another advantage of this method is that it requires fewer hand-offs between teams. For a feature, a single team has end-to-end control and can make quick adjustments to address changing requirements. This approach is far more flexible and allows Product Teams to iterate quickly, creating a better end product.
Instaclone’s two Product Teams, able to independently work on two features simultaneously. More Product Teams can be added without hampering these two teams’ ability to independently ship a feature, resulting in shorter product iteration cycles.
So what does Lumen5 do?
As you can see, there are trade-offs between Technology Teams and Product Teams. So what do we do at Lumen5?
At Lumen5, we use an interesting Hybrid Team model! Most of our teams would classify as Product Teams. However, we have one exception: the team that is creating our video rendering engine. This team is partially a Product Team (their “product” is the end mp4 file that we deliver to our users) and partly a Technology Team (they have full ownership of the rendering technology, which is used through an API by our other teams).
In this structure, we think of the team as having two different types of customers: one is our end-user, the person who gets the mp4 file, and the other is the different engineers at Lumen5 who are consuming the rendering engine’s API.
Using this approach, we can focus on technical excellence within a critical piece of our technology (the rendering engine) while not blocking our other teams from moving quickly on developing new features that don’t require upgrades of our rendering engine.
If you’re interested in working inside of this alternative hybrid structure, check out our job postings. We’d love to have you as we further develop our engineering strategy!
