This is the second post in my blog series about team patterns, and it’s about the technology team pattern.

A technology team is focused on a technical area, such as front-end or back-end, and all members of the team are specialists in that area. So there will be no product managers, QA specialists, or engineers specialized in other technologies on the team. All members of the team report to a manager who is also a specialist in this particular technical area.

For example, it could be a mobile team with a number of mobile developers reporting to a mobile development manager:

When there are multiple technology teams, such as a mobile team and a back-end team, there is usually very little (if any) code shared between the teams. This is because the code is often written in different languages/framework (e.g., Swift versus Python) and exists in different code repositories. The interaction between the teams will often happen through REST APIs or similar.

A real-world example of this team pattern is early Instagram (around 2015) where they had split their engineering organization into three development teams (they eventually moved away from this setup, but more about that in a later post):

The reporting lines in such an organization is based on expertise. In other words, a mobile developer will not report to back-end development manager, but to the mobile development manager.

The managers in such an organization is likely to be a senior engineer who has been promoted into management, and now also takes care of people management on his or her team. The manager may still be writing code (or at least have the ability to do so). It is also likely that the manager will handle project management for the team’s work and coordination with other teams.

The rock star in such an engineering organization is likely be a technical specialist measured by some technical standard, such as mastering all the advanced features of the chosen language, or writing the most elegant, concise code.

Strengths

The primary strength of the technology team is its technical mastery, which is likely to be higher than in any of the other team patterns which we will explore in the following posts in this blog series.

The team’s codebase is likely to be of a high quality and take full advantage of the latest advancements within the chosen technology — and there is likely to be little technical debts.

It can also be easier to recruit technical experts for such a team. For example, if an engineer is intensely passionate about Django then the idea of working in a Django team, reporting to a Django manager and being surrounded by Django engineers is pretty attractive by default.

Finally, the team’s manager is likely to be highly competent in the work that the team performs, which is key to high job satisfaction according to recent research. This also means that the manager can evaluate the engineers based on merit, and not some measure which can be easily faked (like who stays the longest in the office). The manager will also be able to provide detailed coaching, such as how to write better code and be aware when an engineer is ready to be promoted to the next level.

Weaknesses

A common problem for engineering organizations which use the technology team pattern is that time to market (for new features) tends to be slow.

The reason is that one team may finish its part of the feature fast, but the next team might be busy with something else and cannot pick up the task any time soon — as shown in the diagram below:

This means that work queues up between the teams. The cost of a feature may not be higher in actual development time, but it can be very expensive in calendar time.

This problem should not be underestimated. Time to market is hugely important for most businesses. In Lean thinking, unfinished features are expensive inventory that cost the company money, because they don’t generate business value until it’s in production and being used by the end-user.

This team pattern will also nudge you towards phased (or waterfall) development where each team finishes its part of the work before passing it on to the next team. This will discourage iterative development and feedback loops — and when mistakes start to occur due to limited communication between the teams, the handovers are likely to become elaborate and time consuming — and it can even lead to a destructive “us-versus-them” mentality between the teams.

In an attempt to overcome the weaknesses of technology teams, some engineering organizations introduced cross-functional matrix teams. The thinking was that this would lead to improved collaboration between functions (e.g., product management, development, testing) because they would now literally be the same (matrix) team. On top of that, the expectation was also that time to market would improve, because when a matrix team takes on a new feature it will have all the necessary skills inside the team to finish it!

So in the next post in this blog series, we will explore the matrix team pattern. Stay tuned!