I've recently been reading/listening to 'The Lean Startup' and 'The Making of a Manager' (Disclaimer: Associate links!), so this may be the impact of thinking about startups a lot and how they function. However, I think that in more 'established' companies, we do things inefficiently and don't ever try to get better. Startups are great at getting ahead and disrupting because they need to be impactful instead of stagnant.

In traditional 'enterprise' software companies, you can almost guarantee that everybody works solely within their area of expertise: their ‘silo of expertise’. They are isolated from each other. Engineers work exclusively on engineering tasks, salespeople focus solely on sales, etc. Each department operates separately, leading to a lack of collaboration. For example, in developing a product, engineers write the code without involving designers until much later, when they ‘throw it over the fence’ to the other ‘silo’. The ‘silo’s’ never really interact or collaborate, and nothing is done promptly. 

We should strive for something more akin to startups. Cross-functional teams designed around a product to focus on that one product and not their 'silo of expertise'. Let's call a simplified version of this structure the 'Product Silo' (aka, a cross-cutting product team).

Contents

• What it means to have a cross-cutting product team
• Why would I want a cross-cutting product team?
• Why don’t companies adopt a cross-cutting product team structure?
• The unsolved problems

What it means to have a cross-cutting product team

So what? What does it mean to have a cross-cutting team? Just another name for the team building the product, right?

Nah. It's foundational; it's cutting down the barriers. It's a way of working.

When you're in a silo of expertise, your team is other experts in your domain. In a cross-functional team, your team is only the people needed for the product to succeed. Rapport and collaboration are different - we are all biased toward working better with our team than with generic colleagues.

There's no throwing shit over the fence and blaming the salespeople now, you're one team. It's like the shift-left movement of DevOps; you become one team with one focus.

Instead of putting in a request to design to mock up the UI flow, you sit with them and build it together. Instead of sales selling every product the company makes, they sit with the product owner and engineers to have deep product knowledge and know all about the upcoming features they can convince prospective clients they want.

So, what does it mean to have a cross-cutting product team? It means having a team of experts dedicated to one product.

Who's in this supposed team, then?

Everybody who needs to be to make and sell the best damn product you can.

The non-exhaustive list, if you need somewhere to start:

• Product owner
• Product engineers
• Product support
• Sales
• Marketing
• Design

Why would I want a cross-cutting product team?

Great question.

You’ll have a product that users want, with fewer issues.

But you don't just get that automatically by forming the team. The team gets there (eventually) for multiple reasons.

Feedback loops are shorter.

You'll get the right product in the hands of the right people quicker.

It's easier to get direct user feedback to the correct people because they're the teammates of the ones who hear it first - Sales, product support and the product owner. They can pass a note over as they're on the call; it's that quick. There's no barrier to break, no having to go through multiple team leads or jump through hoops that make you give up. Tap them on the shoulder (as they probably sit next to you now) and tell them. Better yet, take them out to clients with you - and no hoops to jump through to get that approved.

Sales can get all the metrics/insights they need to help sell the product directly from the engineers - or even be given hands-on ability to get the data because they're a trusted team member. They can hear from the team what's in the pipeline and are ready to start telling clients about it, and they can say to the product owner right after a call what the clients are screaming for before they can make the sale.

Support can work with the product owner to ensure they have the proper domain knowledge to help customers. Work with engineering to eliminate the biggest problems that keep occurring or get playbooks in place that make the resolutions quicker.

Marketing, design, and engineering work side-by-side to build the best damn-looking product out there - and the iteration is tenfold quicker because there are no scheduling issues.

Quicker feedback loops lead to teams being more efficient and more agile. The whole team can pivot and shift focus on what's most essential to the product without any roadblocks or re-alignments needed across multiple teams - it just happens.

Deep knowledge base

Everybody on the team will have a deep knowledge base about the product; they'll be able to chat your ear off about it.

What this translates to in value, however, is:

• No bus factors in knowledge
• A team of product experts, people who can knowledge-share with others and answer questions
• A team of people who think differently can contribute to solving a complex problem - instead of lots of people who think like engineers (for example)

Cross-cutting expertise

Let's take T-shaped engineers to another level. Let's build a T-shaped team.

Okay, maybe not—that's too much of an ask. But we can get a team of experts with basic cross-domain understanding instead.

When you have a team of people with varying expertise, you'll find that everybody starts to be able to speak the same language. That's because they all develop foundational skills for each expertise they interact with.

Suddenly, sales can have a more technical discussion with the CTO they're trying to convince to be a client.

Marketing can use the domain lingo with an understanding that entices users while collaborating with design to provide consistency across their advertisements and products.

Engineers can better support users and experience dogfooding the product and support pressures while cross-training their support peers to have a deeper understanding of the technical details that enable them to help users better. They can join sales on a call with a prospective client and demo the product without blundering and putting them off.

Fewer distractions

What slows down a lot of delivery? Distractions and context switching.

What causes distractions and context switching?

• Needing to interact with other people, particularly those outside of the team.
• Different projects/products requiring your input

Bring the people into the team and the inherent trust circle, and put their sole focus on one product.

By having one sole product to focus on, there's no real need to context switch. You don't need to learn about another domain or product regularly so that you can contribute your expertise to it; you just contribute to the one you're now an expert in.

You become an expert in the two things that matter and need execution: The product and your skillset. You're efficient when an expert, so keep the expert's experts.

Being in the circle of trust of the team also has its advantages; there's less back-and-forth. For example, the engineering team can teach sales how to use the analytics tool and only need to teach two people - then they can be trusted to have full access and not break it. They don't need to distract engineering ever again for this data.

Better business understanding

When working in silos of expertise, it's effortless to fall into the trap of focusing solely on your 'craft'. For example, engineers may chase 'perfect code' instead of recognising the cost of refactoring because they're focused exclusively on producing the perfection of their craft.

By contrast, a cross-cutting product team has a broader view of the business—it becomes easier to see and understand the product's impacts on the company.

As a team, you're all closer to the impact of decisions, and you can see the pressures every team member has to face. You'll hear the sales experts talking about how they still need to find £0.5m to hit revenue targets for the product, and you can help them get on top of that because now these targets hit closer to home. If your product doesn't hit its goals, you're closer to the chopping block than when you are merely in a silo of expertise.

A significant problem existing in ‘silo of expertise’ companies is that everybody is disconnected from focusing on making the business/product profitable. It’s not their responsibility, and they have no direct impact on the bottom line (or so they believe).

Why don’t companies adopt a cross-cutting product team structure?

Why isn't everybody doing it if it’s so great ‘KB’? Great question!

Inertia

Inertia is required to make an idea come to life. Once the ball gets rolling, it’s much easier to get buy-in from others.

Gathering inertia in a company requires political capital, especially for a change like this, which is probably controversial, ‘unknown’, and challenges egos.

‘Unknown’ ideas are feared as they can cause disruption, making it hard to get buy-in from people with the capital to spare.

Cost of change

Rome wasn’t built in a day, and there’s no Trojan horse. 

Changing tact across a whole org is costly, and many companies don’t like experiments—especially when they take a lot of time to prove. 

Cultural barriers

Some cultures don’t care for teamwork and are more finger-pointy. Cross-cutting product teams require collaboration, trust, and selflessness to work. 

Everybody shifts away from the comfort zones of their silos/departments and has to learn to work closely with other experts. They’re no longer ‘the’ expert. Some will struggle with this shift from focusing on being top-dog, particularly those in top-down cultures. 

Good enough is good enough.

Sometimes, chasing perfection isn’t worth it, and companies are happy with ‘good enough’.

Why risk changing something that already works(ish)?

The unsolved problems

I think cross-cutting product teams are more effective than silos of expertise. But look, perfect doesn't exist. There are problems with every approach.

My unsolved issues are either unsolved because I don't know the answer or because I'm not sure I'm right.

Cost

These teams are going to cost more to run than traditional silos of expertise, in a sense.

'One salesperson per product?! We're going to need 5 salespeople per client!!'

On paper, you're going to want more people. However, there are tradeoffs.

While you may need more of each role, like the above sales example, you will have more efficient teams. Does this mean you can run leaner overall as an organisation? Possibly!

You may also reduce labour hours. If you've got experts focusing on problems (such as a member of support dealing with a client outage), they can find the solution quicker than a non-expert. That reduced labour time could add up to less cost overall.

Multiple teams for one product

Extensive products may be too big for one team to handle. It then becomes tricky, as you don't want large teams - it'll likely fall back into silos of expertise.

The question is: Do you need multiple teams?

You're trying to do too much if you answered yes. You don't. You should make smaller, more focused products - split your 'big' product into multiple, more defined products.

If Amazon's two-pizza team size is accurate, then most AWS products are owned by a team of 10 or fewer people. If they can build things like S3, Lambda, etc., with that few people - why can't you?

Splitting products up will cost money, so it’s probably a significant deterrent for companies that already have their products tied together.

Team growth is more challenging.

How do you grow your team of experts professionally? Being mentored by experts is a big part of learning to perfect your craft. Your team will be filled with experts but not with the expertise the mentee needs.

More senior teams are needed.

It is harder to grow teams professionally, so you probably need more senior teams. Hiring juniors is now less effective (fewer mentors), and thus:

• The teams cost more to hire and run.
• Juniors are not coming up through the ranks, making the team less sustainable in the long term.

Summary

Cross-cutting product teams are a strategy you can use to change how work works in your company. Move the focus away from expertise and to the product - align the right people to the work, leading to better outcomes from a leaner team.

I'll add a cheeky disclaimer here, too. I've never fully experienced working in a cross-cutting team, so some of this is hypothetical, but I have tasted the forbidden fruit. It works.

However, I'm just an engineer trying to do things right and efficiently. I'm probably deluded and drinking the Kool-Aid.