How to structure your software engineering team

The CTO of a growing startup recently asked my opinion on how to structure their large engineering team. They are scaling up quickly and looking for ways to improve efficiency. He had been thinking of switching from horizontal (functional) to vertical (product) teams.

One concern was the potential impact of this change on their mobile app development process. Their mobile releases tend to need a coordinated effort from mobile engineers. Today their mobile team sits and works together to manage this. Splitting them up into separate product-centric teams could be problematic.

But their current functional team structure makes coordination on products challenging. Their mobile team is dependent on many other functional teams to build any feature or product. They need to coordinate with product, design, backend and API teams to ship any feature. Each team with its own priorities, which need negotiating to line up interests. The result being bottlenecks and features that don't always work as expected.

So, what are the options?

Team structure is a common challenge for growing tech organizations. It's also one that's worth spending time on because the right design can make a big difference. It not only affects communication and productivity but can also impact team morale.

The core question is whether one should organize people around functions (e.g., backend, frontend, mobile, design, product) or have cross-functional teams focused on products and features. There are pros and cons for each. I've tried both and several (hybrid) variations between. Let me start by making the case for each.

Functional Teams

Functional teams are probably the most common form of team in the growth stages of a tech org. As teams expand, people tend to group up by specialization. Designers, Engineers and PMs sit with others of similar roles and skills. Within engineering, the same thing happens. Mobile, web frontend and backend engineers etc end up grouping together based on function.

This seems to happen naturally for a variety of reasons. One being that it's usually pretty efficient to sit and work with people doing similar tasks as you. Functional teams are also great for sharing knowledge and learning. People develop their skills by working with peers who have similar expertise and interests.

functional teams do tend to be more efficient.

In my experience functional teams do tend to be more efficient. They focus on a single problem space and avoid a lot of context-switching overhead. Members are surrounded by peers with similar skills, who can assist them if needed. Mobile engineers working together, and focused on, mobile engineering problems. I also think many people really enjoy working this way, surrounded by their kin. Happy that they are being productive, learning and specializing their skills.

Cross-functional Product Teams

The first team in a startup is often a cross-functional product team. A small group of people with different skills working together to build the same thing. But this structure tends to change as a company grows beyond one team.

On product teams all members focus on the same goal- the success of their product or feature.

On product teams all members focus on the same goal- the success of their product or feature. There is an inherent shared ownership of the product. Everyone is in it together. This is often not the case with functional teams. Members of a functional team tend to work across a variety of different products or features. They usually don't share common product or customer goal for long. The result is less of a sense of ownership and accountability for the success of the product.

Product teams are great at promoting cross-pollination of ideas. This is the result of having people with different skills working together on a similar goal. Designers evolving ideas with Engineers, and PMs to solve a customer problems together. Some of the best products ideas develop this way.

Product teams also provide continuity. They tend to focus on the same problems for more time. Over time team members gain deeper shared knowledge of the product problem space. Functional teams move from problem to problem. Going to where their skills are required to build different product and features.

People with specialized roles sometimes feel isolated in product teams and may dislike them. Their peers may not share the same interests, skills and career goals. This is challenging particularly when a team is new. It can take more time to form a good team dynamic and get everyone focused on common goals.

Hybrid Structure

Another common option is a hybrid of product and functional teams. This often makes sense when particular functions are scarce. For instance if a company has a small team of designers, and many engineering teams that need to share their time. It can also make sense for teams working on infrastructure. Teams that support others and may not map well to a specific product or feature.

In my experience most companies end up with some form of hybrid. It's challenging to build a completely functional or product-centric organization. A hybrid structure provides the benefits of both while avoiding their problems.

Trial and error

I'm a big fan of product teams for a simple reason, they focus on the customer. "How do we build a product that meets our customer's need?". They live and breathe the customer problem and do whatever it takes to solve it. Every function and skill on the team is dedicated to this.

Functional teams tend to focus on the domain problem. "How do I fix this issue with the mobile app". That's great when your goal is to fix your mobile app but is not exactly aligned with the goal of the company.

Don't be afraid to iterate and make difficult changes when needed.

There is no simple answer when it comes to structure. What's most important is a commitment to experimentation. Don't be afraid to iterate and make difficult changes when needed. People often resist changing teams and structure. I think this comes from a fear of change. It's important to listen to people but push difficult changes through, if you believe in them. If something doesn't work, you can always roll it back or try something else.

REquest a demo

Get detailed analytics on work and collaboration in your organization

Get Started