How to build (and live with) empowered teams

Silos Bad.

In the software world, especially in medium to large companies, the word “silo” is a Bad Word. Silos are only good for nuclear missiles and self-centered teams who can’t play nice with others!

Bad Teams — siloed teams — think only about themselves, and think too small, and don’t care about integration points with others or standardizing platforms and process. Good Teams are good citizens, who centralize on a common tech stack and way of working, and always see the forest for the trees. Their decisions make it easier for everyone to coexist, and minimize the pain and cost of future change.

But what if that conventional wisdom has it backwards?

• What if a siloed team, because of their isolation, is able to solve a customer problem faster than a team which lives on a common stack and has to worry about breaking things?
• What if a siloed team, because of their freedom, is able to try out an innovative new way of working, or a new toolchain, and prove its efficacy such that it can then be utilized in the common environment?
• What if a siloed team, because of their single-mindedness, is able to seize an opportunity that other teams, which care more about the common good, think would be too disruptive?

Don’t get me wrong — in many companies, silos are indeed harmful, but mainly because they’re artifacts of a time gone by, when the company only had one product, or when the broader culture was less mature. Supporting multiple tech stacks, or allowing teams to implement completely different product processes, can have immense cost and can bring a company to its knees. I have personally seen more than one company “stop the line” and freeze feature development to solve core architecture issues introduced by silos run amok.

But too many teams have forgotten how liberating and productive it can be to draw lines around their sandbox, and take liberties within those bounds. Sometimes you need to consciously tell the rest of your company to stuff it so you can build something great! The cost of losing those opportunities to quickly innovate can vastly outweigh the gains of having common approach, architecture and resources. This kind of empowerment at the team level is essential to solving your biggest problems, especially those which require outside the box thinking and execution.

—

This tug of war between empowerment and conformity is not a new problem. Here’s an example particularly relevant to New York tech — at large media companies it’s common to see, over a period of months or years, a pendulum swing between shared services and brand autonomy.

If your company publishes 40 magazines, or owns 20 TV channels, it makes intuitive sense that building a set of shared services would be better than having to build 40 separate teams who all know how to build a website, a video player, an asset management system, an ad server, etc. So you take the brand’s budget away, build a shared service for digital product development, tell everyone they have to use it and pat yourself on the back for saving $50 million.

Then you start to hear complaints bubbling up from the brands about how unresponsive and awful the shared service is relative to the 3 developers they used to have who knew their business and could read their minds. A couple of big new initiatives fall behind due to these issues, ad sales suffer, and the next budget cycle is dominated by the brands screaming bloody murder and demanding their money back. They dump the shared service, build a small team to replace it that sits with the brand, and…see where I’m going with this? The pendulum swings back and forth, back and forth, forever. As they say about democracy, silos are the worst way to build a team, except for all the others.

Another example of a silo in action is the classic startup — startups are single minded, scrappy and rough around the edges. But they are fast, disruptive, and tend to be good at doing one thing well. At some point you need to scale, which at first often manifests in building multiple silos, and then you start to worry about efficiency — you call this stage “growing pains”.

You talk about platforms, and process, and rationalizing various roadmaps, and such things. You bring in coaches and dedicate yourselves to Agile, or Lean, or whatever. And what usually happens next? Your velocity goes in the tank — you get less done for your customers in the short term, and whatever gains you might see in efficiency are more than outweighed by your losses in productivity. You try to tell people to be patient but that is easier said than done. In trying to grow up, you lose the mojo that got you to the brink of success.

So the question is: can you have the best of both worlds? Can you capture the speed and focus of silos, without flushing money down the toilet by ignoring obvious ways to be smart and efficient?

— -

The best way I’ve found to claim this middle ground is to respect the independence of product teams, even when they might seem redundant across products or brands, while at the same time to provide best in class tools, process and support as a shared service. When I say product teams, I mean everybody involved in concept and delivery for a given product — tech, UX, design, user research, product mgmt, project mgmt, etc.

This isn’t rocket science, but is not easy in practice. Here are a few rules of thumb to respect product team independence:

1. Teams should be working towards a single set of non-competing goals. I thought about saying “teams should be dedicated to a product, or a brand” but that isn’t always realistic — the key idea is that teams should not have to worry themselves about which of two non-aligned business goals they need to serve today. That is the larger product leadership’s job to figure out. Multiple products can live under one roof as long as they all ladder up to the same objectives.
2. Don’t share backlogs between products. Product managers need to be able to plan and prioritize in isolation, even if they are aware of and responsible for competing goals. If you need to balance resources and timelines amongst different teams and resources, do it at a higher level by adding or removing people from the team, and preferably infrequently (every 6 weeks, or quarterly).
3. Don’t share environments between products if you can help it. This is a balancing act but there is nothing worse than killing someone else’s environment by accident or getting blocked by a freeze that has nothing to do with you and your priorities.
4. If you must share a single dev team across different products, consider alternating sprints rather than interleaving products, or even run multiple consecutive sprints dedicated to one product or the other, effectively putting the non-active product in maintenance mode. Context switching is expensive — do it only when necessary!
5. Resist the temptation to form “tiger teams” that go from product to product solving everyone’s problems and leaving only dust in their wake. It doesn’t work and it makes people mad. Let the people who know the product and the brand solve their own problems and support their own software post-launch, with help from experts.
6. Allow teams to settle and develop their own rhythms, even if they don’t match the playbook or any of your other teams. Process is a resource, not a gospel. Don’t mess with those rhythms unless you are willing to nuke the whole experiment, or unless they ask for help.
7. Encourage and facilitate cross-pollination — your product managers, tech leads, design leads, etc. need to drive exploration and experimentation with new techniques, new stacks, new product areas such that they can share insights, especially successes and failures. The Spotify guild model is one way to do this, but you can also create a public forum for it in context of your sprint demos or other org-wide rituals.
8. If you need to bring in “hired guns” who are experts on a particular technology or product, make it explicit that they are there only to help, not to take over or to inform on any bad behavior. You want to infuse best practices as much as you can across all your teams — it’s essential! But the product team needs to be in the driver’s seat. Anyone who comes in from outside is there to serve the team, and they should take a subordinate role.
9. Measure everyone and everything as impartially and completely as you can, both in terms of product metrics and contributions to the broader tech org (or what they take from it). If you are killing it on your product and being a pain in the ass to everyone else, that may be completely OK or it may be causing sufficient problems that you need to knock it off. Leadership needs to quantify the impact such that it can make conscious decisions about cost vs. benefit. That analysis may also enable you to make minor changes that make everybody happier at minimal expense.

—

If you do these things well, you should wind up with teams who are tightly tied to their products and loosely coupled (but still coupled!) to the infrastructure and shared services that they need to function. These are teams which can jump on opportunities and build new things, but will not leave a smoking hole in the ground while doing so.

These kinds of empowered teams — product focused but respectful of the big picture — can be a bear to create, but they are often exactly what you need to scale your product and your company as you grow. And part of their success is in being able to silo themselves in good ways to protect what they do best — their nimbleness and ability to solve customer problems, even if means asking forgiveness rather than permission.