Effective Product Teams are Dedicated, Colocated, and Cross-Functional. Period.

We get into way too many debates about this as an industry (by which I mean all of us who build software systems for a living). I am writing this post as an attempt to put this debate to rest once and for all. Of course, that won’t actually work. So enjoy it as an irreverent rant by an impassioned expert, at least.

Why Dedicated?

Well, what’s the opposite? In most companies, it is very common for teams to be composed of individuals who are already assigned other projects. A project is handed down from some celestial body: “migrate such-and-such from system X to system Y.” This kicks off a process called “project planning” during which some poor sap is required to estimate the scope of the project, the skills required to execute it, the proper size of the team, and (worst of all) the timeline for completion. It’s an approach that practically begs for failure, since few of these things can be known in advance for 99% of software projects. But, hey, who’s counting?!

The resulting team configuration is a Frankenstein monster of partially assigned people from all over the company’s various functional silos, all of whom are also committed to working on half a dozen other projects at the same time. When this situation occurs, the entire culture of the team revolves around meetings. When to have them, who should be there, who missed the last one and why? The coordination costs alone should make this method of team formation a non-starter, but no one ever seems aware of how costly it really is.

A dedicated team, meaning that each and every member is fully assigned to the project and to no others, seems wasteful to managers who are unfamiliar with product management. It is because they see people on teams as functionally equivalent to the machines in an assembly line. What they fail to register is that the real work of product development happens between team members—in collaboration—not within each team member as individuals. Product development is not assembly. It’s design, art, systems engineering, and architecture—all in one.

Why Cross-Functional?

Handoffs between functional specialties will kill your project speed. What do we mean by handoffs? Well, a software feature needs to be designed or architected, then developed, then tested, and then shipped. If you are building an app on your own, you inevitably do all of these things yourself. But most of us don’t work alone, and have to rely on a process of transferring work items from one state of completion to the next.

Every time you need to pass your unfinished work to a function in another department, there is a wait time between when you drop it into their lap and when it gets completed and passed to the next function. Actually, if you want to get “Lean” technical, there is wait time while the item sits in the queue, and then there is cycle time while it is actually being worked on.

The further the separation of functions from each other, say design from engineering, the more tempted we are to hand off work in large batches. Why not get all the designs completed first, and then start the coding? Well, suppose there are errors in the design that only an engineer would catch? If we wait until they are all complete before providing feedback, that error could be replicated in every design artifact. They would all have to be redone before we can move forward.

That’s the norm for projects that rely on a function that is external to the team. Engineering sits in one place, and design in another, and QA in another still. A cross-functional team, by contrast, situates everyone together. Furthermore, if you’re really doing it right, each work item is built by everyone, together, with as few handoffs as possible.

Why Co-located?

In every talk that I give, I go over the need for your product teams to be cross-functional, co-located, and dedicated. And every single time there is always someone who wants to argue that distributed teams are more effective than co-located teams. It feels like arguing with someone about whether you could build a skyscraper out of popsicle sticks. Of course, you could do it. But why would you choose to, if you didn’t absolutely have to?!

Honestly, people. I don’t get this obsession with distributed teams. People who crave working from home so badly should maybe reconsider working on team-based projects. Sure, there are times when the best or only people for your project are living in different cities. But, as I said, only do distributed if you have to.

“Why is collation so important? We have Slack and Zoom and GitHub, man. You’re just old-fashioned,” you say!

Bah! You’re only thinking about a narrow segment of the work of building software. GitHub is amazing, and so (to a lesser degree) are Slack and Zoom, and all the other collaboration tools you want to mention. I use all of them, here and there.

But, here is what you don’t get. Software is a team sport. It consists of a million tiny decisions. We don’t all agree. When we don’t agree, we need to resolve the conflict somehow.

Teams that work in the same space spend a lot of non-work time together, like lunch and after work drinks. Those casual personal conversations build trust that help us resolve conflicts later in a work context.

You cannot discount the importance of interpersonal bonding among the team. It’s probably the single biggest reason startup teams are so much more effective than typical corporate teams. The bonding that happens when a team are glued together in a small space around a single mission... Well, you simply can’t fake it with process or tools.

My anecdotal experience (which is 20 years old, and includes at least 100 teams) has shown me that the only teams that really rock at being distributed are those that (a) already knew each other personally beforehand, and established trust long before this particular project, and/or (b) started out collocated and migrated to being distributed over time. I have not met a team that started out as a distributed group of strangers that came anywhere close to the product speed and quality of your average team of 5 sitting together in a WeWork somewhere. Not. Even. Close.

Conclusion

Setting up a product development team has risks. Embracing a dedicated, cross-functional, and co-located approach as best practices which take a little effort but enormously reduce risks is just common sense these days. It’s like driving on a long trip to another city. Have your glasses? Wearing your seatbelt? Car properly gassed and tuned up? Sure, you can skip any of these steps. But then you’re taking on unnecessary risks that could be managed with minimal effort.

—

Be a better technology leader

Learn to apply these skills in the context of your organization. Check out the Startup Patterns master class on technology leadership. We cover topics like how to discover and pursue your professional direction, how to have difficult conversations with peers, how to manage up to executives, and how to lead change in an organization using influence rather than authority.

Registration is now open. Apply here.