Total Product: Cruyff Comes to your Scrum Meeting
Or, why, maybe, you don't need only product managers, designers, or for that matter, engineers
The Rocks at the Bottom of the Lake is one of those Zen-like parables of Lean manufacturing1. In that metaphor the water is the intermediate product of a certain process - say work in progress (WIP) inventory- and the rocks at the bottom of the lake are all the weaknesses and problems in your system. The simple idea is that the high water covers the rocks. The more water (i.e. stock) you have sitting in the system, the less likely you are to see the problems impeding the flow of water through the system. And because most production systems aim to maximize flow, high stocks are almost always indicative of problems lurking below the surface. Inversely, a system that consistently generates output (flow) as quickly as it receives the input, will have no stock, and - conceptually - no problems.
In a software production system, one can say that the inputs are user requirements, and that the outputs are features delivered to customers. The stock - the WIP - the water - are all the features sitting on your backlog. Now, look at your team’s feature backlog, and then look in my eyes and tell me there are no rocks at the bottom of that lake.
We need to talk.
You Call Yourselves a Team?
But, “that’s not fair” you tell me. “Backlog features are written by the PM based on customer input and insight (hopefully). These are much faster to produce than the software to address them.” True. Customers always want more than what you have capacity to produce. But that’s a statement about the world, not about how your team should operate. The problem is that one part of the team is producing inputs (user stories) at a much faster rate than the rest of the team can produce their output (software). That might be the reality of it. But is it accurate to call this a team? It is like having a football (soccer) team where a couple of players are measured on the number of passes they make, and everyone else is measured on the end result of the game.2
This is not just an inconvenience. It is a problem for team morale. PMs are sitting there frustrated that the engineering team is not moving fast enough. UX designers are trying to think how to incorporate all these features (most will never launch) into a cohesive framework. Engineers - good ones especially - start thinking about long term architecture to support all these new features coming down the pike. And, everyone is arguing incessantly about the relative prioritization of a feature that was added to the backlog a couple of years ago after a sales call to a company that is probably already out of business. Meanwhile, an imaginary customer is looking puzzledly up your product’s water tap, wondering why no water is coming out despite all the sound and fury behind the wall.
The “Broken Window Theory” suggests that visible signs of disorder in an urban environment (e.g. broken windows) encourages further disorder and crime. The mechanism is a simple: it seems like it is ok to break windows around here. Without arguing the validity of the theory in criminology, Lean recognizes a similar dynamic in production systems. One of the Lean folktales I heard was about two Japanese experts from Toyota who come to an American manufacturing company in the 80s to teach it about Lean, and promptly set out to take off their jackets and ties, roll up their sleeves and start scrubbing work stations. After two days of nothing but cleaning, the Americans ask them what is this about, and the Japanese experts respond that you can’t eliminate waste in a process if there is waste all around the worker. It’s a dissonant message.
As I said, folksy and Zen-like, but there is truth in it. You can’t have a culture of execution and speed when at the same time it is ok for user requirements to languish for a couple of years. It seems like it is ok to move slow around here.
How did we end up here? I thought we were Agile™!
The PM Hammer
There are many reasons you have too many things sitting in your backlog. Some are quite natural: when customers use your product they discover new things they wish they can do. Sometimes they discover things that break. Good teams figure out ways to sort through these, and fix bugs promptly. But there remains a bunch of “cool” features that no one seems to have the time to work on. Why are they there?
Part of the reason is that - especially in Big Tech - it is much easier to hire a PM than a team of Engineers. From a budget perspective, a PM costs almost the same as one Engineer. But you can’t do much with one engineer. So in a world of limited resources and too many things they wish they can do, managers will hire a PM “to get us started”. That’s what I call the “PM Hammer.”3 If I have a new problem I want to solve and only 1 job I can hire, it does make some sense to hire a PM. There is also some truth in the fact that there is lead time involved - again especially in big companies - between figuring out what to build and actually starting to build it. So, maybe, yeah, we need to start with a PM.
The PM comes in and starts hammering away at the problem. They discover there is a lot that can be done/built (isn’t there always?) and they write requirements. Even with the best intentions, and circumstances, chances are they don’t have an engineering team in place yet. So what do they do? Depending on the org, they will either keep spinning out more documents and requirements - flooding out everyone with reviews and decisions that are not getting close to threatening the customer with any new launches. Alternatively, the more enterprising ones will go out trying to find someone, anyone, to build their requirements, and they will flood other engineering teams’ backlogs with orthogonal requests, and more meetings and reviews to explain what they are even talking about. Repeat this process a few times, and it is no surprise everyone is buried under a backlog of features, reviews and decisions, with very little delivery to show for it.
If you step back enough, the core issue here is that hiring more PMs ramps up the demand on the system, without doing anything about the capacity of the system to produce. You end up creating a “Bullwhip” effect, with the few additional features created by 1 PM creating work for 2-3 UX designers, and tens of Engineers, and so on.
Painting The Chapel
Remember the point about how a product team feels like a football (soccer) team with a couple of players tasked with making passes, while everyone else is supposed to win? Turns out that football was (and still is to some extent) like that. Football teams have goalkeepers whose sole job was supposedly to keep the goal out of the net, defenders who were strong enough to push attackers off the ball or boot the ball away to safety, midfielders who took the ball from defense to pass to attackers, who were the ones supposed to score the goals. Each role had certain characteristics, objectives and career progression. Goalkeepers, defenders, midfielders, attackers. PMs, UX Designers, Engineers.
Until a Dutch team walked onto the World Cup pitch in 1974 and changed everything. All of a sudden you had center forwards pressing to win the ball, defenders creating scoring opportunities, full backs overlapping attacking players, and goalkeepers taking passes in mid-field. It looked like mayhem. It was not supposed to work, but it did. It looked something like this:
And it inspired the world. Total Football was introduced. And Johan Cruyff - the Netherlands’ center forward in 1974 - was the man who embodied it as a player, brought it to Barcelona as a player then coach, and then passed it on to a generation of disciples. The most famous of course is Manchester City’s Pep Guardiola who noted that "Cruyff painted the chapel, and Barcelona coaches since merely restore and improve it."
Wikipedia defines Total football as a “a tactical system in association football in which any outfield player can take over the role of any other player in a team.” But Cruyff had a more sophisticated understanding of football, that will sound familiar to anyone building product. Take for his example his view - in his autobiography - that “football is a process of making mistakes, then analyzing them to learn lessons”. That empiricism is supported by observations on the field: “That, in fact, has always been the essence of Total Football, you always play based on what you can see and never on what you can’t see.”
The most relevant lessons to the topic at hand, comes from one paragraph in the autobiography:
I like to turn traditional thinking on its head, by telling the striker that he’s the first defender, by helping the goalkeeper to understand that he is the first attacker and by explaining to the defenders that they determine the length of the playing area. Based on the understanding that the distances between the banks of players can never be more than ten to fifteen meters4
In that you see a more sophisticated version of the Wikipedia description. It is not that everyone should be able to do everyone else’s job, but that 1) everyone’s job is the same based on context. While attacking, everyone - including the goalkeeper - is an attacker, and while defending, everyone is defending. And, 2) the lines should always be compact. That second point is important because if a defender is only 20 meters away from the attackers, it means they are more likely to find a gap in the opposing defense and move to a goal scoring position themselves, than if they were 60 meters back. Which means they need to know how to score. Similarly attackers need to know how to defend.
Are Two Pizzas Enough? How About 4-4-2 Pizzas?
The parallels between sports teams and all sorts of business teams have always been made. They are usually variations on the theme of “there is no ‘i’ in team”. Teamwork, collaboration, desire to win, etc. are usually the lessons taken from sports. Better team analogies focus on solving for communication problems. Famously, Jeff Bezos, advocated for “two pizza teams” as the ideal size of a team to minimize communication overheads.
All of these ideas are valid, but they usually don’t say much about role diversity within the team. They assume that you need to have specialists on the team, and that your role as a manager is to ensure they work together better. But, the controversial implication of Total Football is that maybe we don’t need as many specialists. Like defenders who can pass, and attackers who can tackle, maybe your team needs PMs who can push code and backend engineers who can design.
The flexibility that a team of true, productive, generalists can create solves many of the problems discussed earlier. By allowing individuals to flex between creating demand (writing requirements) and generating capacity (writing code) the overall team output is better matched. The flow from input to output gets closer to 1:1, and the water in the lake goes down, allowing you to discover true issues and opportunities that need to be addressed.
One approach that people take to solving the problem of matching demand and capacity is using ratios. So you’ll have teams that say we need 1 PM and 1 UX designer for each 8 Engineers, etc. That could work, but it is too static. Your needs evolve throughout a project, and you might need 2 PMs at some point, but 0.5 later on. Without the individuals themselves being flexible, it is hard for your demand to capacity ratios to stay balanced. The ratio approach is also very similar to football formations. Pundits and fans love talking about whether a team is playing a 4-4-2, or a 3-5-2, or a 4-3-3. And that’s how teams submit their lineup sheets to TV broadcasters. But the best teams and best coaches realize that this is just a starting point, and that positional fluidity during the game is key. Guardiola famously called formations “nothing more than telephone numbers”. Jurgen Klopp, Liverpool’s manager has a similar sentiment: “In possession [the formation] can be everything.” And the evidence from their teams support it: Liverpool’s top goal scorer over the last 4 years is a right winger, and Manchester City’s current top goal scorer is a defensive midfielder.
Some will read this and think it is the most obvious thing in the world. Most startups constitute of generalists who interview customers, design, code, and make sales calls. But as most companies grow, specialization starts creeping in, and you end up with 8 kinds of engineers, 4 kinds of designers, and 5 kinds of PMs. And based on the org design, each one of those job roles could be sitting in a very deep functional team, or a shallower one.5 Sometimes all of these different roles are working on the same project, creating all sorts of work queues and bottlenecks.
The argument usually made in favor of that kind of specialization is twofold: 1) you get better by being around people of similar profession or trade, and 2) it is better for your career progression as an Engineer (or a PM, or a UX designer) to report to someone who has the same job. It means you can do their job eventually.
Both of these statement are tautological for a similar reason. If you define a PM role as someone who thinks of strategy and writes business requirements only, then yeah - sure - they need to be around people who do the same, and report to people who do the same. But it’s like saying: as a defender, you should be in a team of defenders, and play for a defensive coach so you can grow. But that is not the game we are playing, Timmy. In football, the goal is to score goals, and win. In product teams, the goal is to ship the right product to the customer. What you do minute to minute and day to day will vary by the situation.
Of course, there are some realities to skillsets, training and experience that will lead people down a certain specialization. And I don’t think it is realistic to expect everyone on a team to be good at everything. But you probably need people who are good at multiple things at the same time. I’d go as far as saying that people who insist on doing only a specific role or reporting to someone with a specific job title are maybe people you don’t want on your team. As Cruyff put it you need players who “arrive as a team, leave as a team, and […] who clean their own boots.”
Lean Manufacturing is a once revolutionary system that corporate America’s limitless platitude-making abilities transformed into something about six nines, Kanbans, and Karate belt colors.
It’s actually exactly like that.
Not to be compared to, or confused with, the MC one. Also, apologies for getting you to click down for this joke. I’ll do better.
Football fields are 100 meters long on average, so he is talking about compacting the team within ~30% of the playing area.