“Top-down, command-and-control organizations with billions of dollars and thousands of employees are getting their butts kicked by small, agile teams with only a handful of employees, informal org structures and very little resources.”
Although the media loves to present this story, this isn’t actually what’s happening.
The reality is more complicated. Some large companies, with their associated scale and bureaucracy, are doing pretty well, while many small companies with all their nimbleness and flexibility are struggling to stay alive.
So what’s better, big and robust or small and adaptive? The answer is both.
An inauspicious start
To understand how the modern product teams are delivering value to their companies and customers, we need to take a look at the sometimes distasteful evolution of the product organization.
By the end of the 1800s, the business world was frothing in excitement over the scientific management promises of Taylorism. Suddenly the randomness of hand-crafting products was replaced by a predictable approach. Factories full of “mentally sluggish” workers could start making things with greater scale, frequency and precision.
Taylor’s mocking attitude and reductionism brought control and planned outputs to the previous era of unpredictable quality and unreliable delivery. These improvements in efficiency came at the cost of individual creativity and respect for the worker.
In Taylor’s world, managers did the “thinking” while factory floor or typing pool workers kept their mouths shut and performed their mundane tasks.
Sadly, this approach persists in some industries, and certainly in many developing parts of the world. We don’t need research to tell us it’s a great way to piss people off and simultaneously create myopic, inflexible businesses. Employees hate these human factory environments and customers dislike the companies that create them.
Slowly leaders started to discover the drawbacks of taking away the worker’s ability to make decisions on the spot. Command-and-control often meant long delays in production-line halting decisions and the poor execution of instructions as information got tangled up in the back-and-forth bureaucracy.
This was never more apparent than in the military. Where structure and discipline had initially brought fractured tribal groups together to create unstoppable armies, this rigid command structure became it’s own worst enemy. Generals, lacking knowledge and insight from the frontlines, made poor decisions on behalf of the men on the ground. Soldiers paid the ultimate price for this top-down insanity.
Probably the best statistical graphic ever drawn, this map by Charles Joseph Minard portrays the losses suffered by Napoleon’s army in the Russian campaign of 1812. (Source Edward Tufte)
More agility was required. In the theatre of war, the small autonomous fighting team was emerging. Although Britain’s secret sabotage teams were not the first guerrilla fighting force to exist, even Churchill, a lifelong bureaucrat, conceded to the ability of these small teams to turn the tide of WWII. These agile teams achieved outcomes that the brute force of the armies, air forces and navies were incapable of.
What was considered ungentlemanly at the time is now standard operating procedure in all modern military forces.
Here’s where it gets messy. When only viewed from a historical perspective, it looks like we have two conflicting models of organization:
Command-and-control vs. autonomous teams
But as with all things, this categorization leaves out the 50 shades of grey.
Strengths of teams
If you’ve ever watched a world-class team play sport, it’s obvious that although each team member has specific skills, nothing is achieved without the collaboration of everyone. Once play begins, teams don’t need to constantly watch the coach for instructions. Their actions are quick and decisive. They have a shared goal, they are practiced, but they operate autonomously.
This is the primary strength of a team: autonomy.
Decisions get made on the field, not in a boardroom. Individual skills networked into a cross-functional group can yield delightfully fast results. In many cases, this networked arrangement of teams makes it easy to replace lost members or continue without any supervision. The advantages of field-level decision making was beautifully demonstrated by the emergence of Lean manufacturing and the Agile development principles.
But teams can lose their way more easily than command-and-control organizations. Even the mythical Silicon Valley startup with an embarrassment of funding, talent, and support gets lost when they don’t have a real pain to solve or a meaningful reason to exist.
Strengths of command structures
Without a doubt, any group that’s pursuing a goal does better when it has a purpose. A meaningful North Star to guide their actions provides a lens for organizations to align their behavior. Any company, big or small, can create a mission, but as they grow to a significant size, it becomes increasingly difficult to maintain alignment.
Command structures provide institutionalized alignment to their missions.
Bureaucracy has value. Not in the mind-numbing paperwork or adherence to rules, but in the optimization of resources, lines of accountability, and long-term capital considerations like talent development and infrastructure investments.
Unfortunately, bureaucracy often loses touch with its raison d’etre. As the scaling organization divides itself into departments and product divisions the company mission can get diluted. This dilution results in more policies, more rules, and less flexibility. A vicious circle indeed.
Bureaucrats often become a self-perpetuating institution enforcing policy over purpose.
One part of the solution to avoiding death by bureaucracy is the creation of a product vision and product strategy for each product group. This reinforces a relevant product-level North Star, while taking advantage of the corporate benefits of resource allocations, long-term strategic planning, and senior-level support.
Reality has a habit of making fools out of theorists. While it might be easier to latch onto a single model, the messy truth is that organizations are essentially combinations of different approaches. Like the recombination of parental genes, organizations are a blend of inherited characteristics.
Outside of economics class, all companies are imperfectly blended models.
The fast-scaling business has problems that the startup just doesn’t have. Amazon announced last year that they will hire 50,000 new employees. Demands like this are an inconceivable challenge for new companies. While Amazon might preserve the zeitgeist of a startup with its two-pizza meeting rule and Day One Principle, it needs some control over the massive organization it has become.
When companies promise customer value that’s reliant on complex logistical, financial and administrative systems, a little control goes a long way.
Enter the hybrid model.
When I interview veteran product leaders, they always embrace the ambiguity of evolving businesses.Unlike the business student bent on a perfect model, seasoned leaders know that the Franken-org is a little closer to reality.
In contrast to the monster metaphor, a modern product organization hybrid doesn’t need to look or act like something that you built in your garage.
Chris Fussell, author of One Mission and coauthor of Team of Teams, describes the benefits of the hybrid, “You can’t throw away what works in a bureaucracy—optimization of assets, accountability, long- term planning and development of talent, certain linear decision-making processes.”
The command model provides much-needed air support, while Fussel says, “Teams and small units, by contrast, are unmatched for their spirit and agility of performance; also their ability to make non-linear decisions and innovate on the fly.”
Design Thinking Handbook
In this book, you’ll learn how to put the thinking-based framework popularized by the Stanford d.school into practice so you can take on challenges in your organization and reach insightful solutions.
Given that bureaucracies can be rigid and risk-averse, they need to be infused with the agility of teams. Simultaneously teams need to ensure they don’t end up in a bubble of their own team culture, a lack of empathy or a failure to communicate with other teams.
How does this work for your company?
The approaches below are not linear. They are intended to be parts of a larger effort to make your product organization more adaptable and flexible. However, they could certainly be used independently.
1. Determine product vision, product strategy, and priorities
For the scaling company a single company mission is necessary but insufficient. They will also need to create a Product Vision, Product Strategy, and Priorities for each product that it supports. A Product Vision is also necessary but insufficient, and thus requires a full exploration of capabilities and sustainability.
Developing a Product Vision that is both connected to the company mission above it and connected to the strategy and priorities below it will create more alignment both vertically and horizontally across your organization.
This approach benefits from the top-down focus of a command model while preserving the autonomy of the product team. Alignment also leads to better decision making, which creates velocity.
2. Communicate, communicate, and communicate
It cannot be overstated how important it is that the Mission, Product Vision(s), and Product Strategy be communicated at every opportunity. Communicate every single day. Until you hear your team repeating these things back to you without prompting, or observe it in their daily actions, you have not made an impression.
The first step in communication is to have your story straight. A clear, motivating narrative needs to back up all of your conversations and actions. Walk the talk.
Whether you’re presenting to the entire company or a subgroup of your team, narratives are essential. Nate Walkingshaw, Martin Eriksson and I wrote a few chapters about this topic in our Product Leadership book so I’ll refrain from regurgitating it all here.
3. Network the network
In his book of the same name, Stanley McChrystal refers to this as the Team of Teams, but as he writes that it’s more than just teams. A team is just part of a network, and for it to continue to be valuable, it needs to be both connected to other teams and to the mothership.
Networking teams require bold moves from leaders. Apart from ensuring consistent communication of the Mission, Product Vision, and Strategy, it’s essential that teams be connected. This can be done formally and informally, either way, it can’t be left to chance.
Formally, you may choose to have team members from different product teams meet regularly to share insights, exchange ideas and learn from each other’s mistakes. For example, a product designer would meet weekly with other product designers from other teams to discuss each other’s work.
At first, product teams might feel like this sharing is like giving away some of their competitive advantages, but over time this will be replaced with “Oh wow! That’s so helpful” moments.
Informally, teams that spend time with each other will relate to each other better. For a lot of people, strangers are the enemy. Encouraging simple interactions like eating lunch together, seating team members at the same table, inviting other teams to join your meetings, and demo days, are just some ideas that bond people together.
It’s important to start with trust. In spite of rumors to the contrary, transparency of knowledge gives everyone insights that raise the tide for all boats.
In a competition designed to solicit solutions to the Prisoner’s Dilemma, the winning entry was a simple four-line code that always began with cooperation. The program by Prof Rapoport would also never hold a grudge so that even when an opponent didn’t cooperate, the program would re-engage the moment the opponent started to cooperate.
Cooperation drives networks to grow stronger. Biological systems are the same. Neural networks that fire together, wire together. The more a neuron is used in a neural loop, the more likely it is to build permanent connections to the neurons around it and increase the fluidity of that loop.
4. Structure as strategy
At Pluralsight, a company now famous for its autonomous, cross-functional Product Experience Teams, managers deliberately connect team members in daily and weekly sessions, and in real-time across a range of tools and technologies.
The creation of PXTs and the environment that nurtures them allows the teams to focus almost all of the time on “the experience of the product.” This should always be the team-level priority—the customer’s experience.
Product managers, unbound from supervising teams, can then focus on networking their insights and knowledge with the rest of the organizations.
In Nate Walkingshaw’s words, “this is organizing, communicating, and collaborating with different parts of the organization to inform them on what’s happening when.”
To be clear, networking your teams is not something you can achieve with process management. Methodology, values, and principles guide the human transactions within a network but the network itself is grown through active nurturing.
The failed promises of Agile and Lean to drive speed and focus in our organizations remind us that process means nothing when the structure is not there to support it. Structure is strategy.
Process is important, but it is not a substitute for structuring your organization for better knowledge sharing, understanding, and communication.
These cross-functional, diverse and autonomous teams are the building blocks of the modern product organization, but they are just a part of it. Spinning up these PXTs won’t magically reshape your destiny. Leaders need to also provide these teams with space to experiment, psychological safety and to allow them to possibly fail for them to develop confidence. Like a toddler learning to walk, parents can’t hold their hands forever.
5. Educate, don’t train
When building the type of hybrid teams and environment we’ve discussed here, you’re going to meet with resistance. These changes are not easy. The bureaucrats will throw the book at you and the autonomous teams will cry “live free or die.” Both will need time to see the value of this hybrid approach.
An education is what’s required. But not the condescending training organizations force their workers through whenever there’s a “restructuring.” Personalized, thoughtful education that begins with having team members spend time with their colleagues in other departments and divisions.
Embedding people builds empathy and connections. Connections create networks. Networks create speed.
Education happens when you experience something yourself and then pass on that knowledge to others. Like the surgeon’s motto, “Watch one, do one, teach one”, having team members cross-pollinate and then return to their teams to share what they have learned builds understanding and respect.
Until you can publicly explain someone else’s work and their value to the organization, you don’t understand it.
When product teams are structured so they can easily share information between the members, and the members of other teams, they get faster at making decisions. Better decisions are possible when there is a lens. Your mission, vision, values, and priorities are that lens.
Faster decisions equal more velocity.
Add to this a deliberate interconnectedness of teams to the corporate support structures and now you have the resources needed to accelerate innovations, on-the-ground decisions, and responses to a fast-changing market.
The leader’s role in all of this is to create a nurturing environment for these structures and behaviors to exist—and then stay out of the way! A leader will be judged by what happens when they are not in the room. too much oversight or over-the-shoulder supervision will reverse the trust these things aim to create.
As a friend once reminded me, “Trust is like glass: once broken, it’s almost impossible to repair.”