On confusing position and velocity: process and risk in the corporation
I have seen large and well-funded organizations use their social and monetary capital to acquire large and highly experienced teams. The great danger with this is the ensuing confidence of success. To visualize this linearly, that collective experience in person-years might mean you are ahead of everybody. But to visualize it differently, this starting point is the Y axis intercept. If we assign time to the X axis, we realize that what really matters in the long run is slope, or velocity. Even with an excellent head start of an impressive Y axis intercept, if the slope is shallow, it will be intersected by a line with a steeper slope and a smaller Y axis intercept.
What the large organization has done is to confuse position with velocity. An organization that can learn and improve faster will win. Really, all that matters in the fullness of time is that learning rate. This is why startups can come from behind to beat big companies. While the big company has a much more impressive set of resources to begin with, large companies usually do not do a good job at optimizing for learning rate. Learning means trying new things, risky things, which means having a possibility of failure. Large companies often are defensive about their brand, which means that their brand cannot be associated with something that could fail. By being unwilling to fail, they’re also unwittingly hobbling their ability to succeed.
What is most interesting to me about this is that absolutely nobody will say “we need to be slow”. That’s a strawman. Everybody knows that being able to learn quickly is important, in theory. But in practice you will run across interesting individuals who will identify things like “brand risk”, or “best practices”. They will say reasonable things like “we must to make sure that whatever we do is high quality, even in the first version.” These things sound good, which is what makes them so dangerous.
Whenever somebody in an organization proposes a new process, they may be lowering the risk of making a mistake by adding reviewers and rubrics, but they are also slowing the rate at which the organization can learn. This is especially true of processes that are introduced without service level agreements (guaranteed turnaround times) or delegates. If a new step in the process requires five different approvers, the odds that one of them will be on vacation this week gets to be pretty high! If there is no way that a process approver can designate a secondary/delegate guaranteed to be on call for the process, we have just introduced indefinite process delay. If we view individuals in the organization like neurons and the entirety of the organization as a brain, such processes are, effectively, brain damage — slowing the speed at which neurons can fire and process new information.
That’s not to say that all process is bad! Moving fast and breaking things in pacemaker design could kill people. There should be a lot of cautious process around the design of pacemakers, even if it comes at the cost of lower innovation in the space. But the level of process one engages in should be proportionate to the level of risk of activity. When a given learning activity is found to be risky, the right reaction should be to ask how one could quickly acquire equivalent learnings in a less risky fashion — not to start by enquiring how new process can be introduced.
When the end product is very well defined in constraints, process is mainly about making sure that you’re actually delivering what you thought you were going to deliver. Process slowness is a fixed tax — it sucks but the product will still ship. In cases where the product is not yet well defined, process slowness can be fatal. Let’s assume that 30 learning loops are needed to arrive at the beginnings of a satisfying solution to a currently poorly defined problem: if a learning loop takes a year, you won’t have developed the needed IP for three decades and you’ll almost certainly get defunded well before that. The program will fail. Conversely if your learning loop takes a week, you could be ready to go to market in earnest in a year. Speed is survival. And that’s even before factoring in your (speedy) competition’s role in your demise.
Similarly, a common reaction to a system that is slow is to ask for more predictability to mitigate the impact of the slowness by letting folks plan around it. But systems that are slow are often slow because they are complex, making demands for predictability a fragile response: it requires introducing another complex component — a sophisticated prediction algorithm — and does nothing to alleviate the underlying problem: the responsiveness of the system to changing needs. Solving for system responsiveness requires finding ways to reduce complexity and latency in the current problematic solution. That’s admittedly hard but it’s the better problem to solve.
So we see that what is needed is a shorter learning loop (aka: OODA loop) where given the state of the world we can hypothesize about something that we could do to improve it, effect the change, observe the outcome, learn how that differed from our expectations, update our mental model of the world, and come up with a revised new hypothesis. Rinse, repeat. That’s learning. The speed at which an organization can perform this activity will define its ultimate success. A system with short learning loops is anti-fragile: as the world evolves and increases in complexity, such a learning-optimized organization will outperform organizations that are slower to adapt.
Different wings of an organization may have responsibility to help the organization avoid making critical errors: violating regulations, breaking the law, losing sensitive user data, or spending more money than is available. What’s important in these cases is to collect information about critical guard rails: what are the things that we must make sure never happen? Within these guard rails, we should get all parties to explore solutions that maximize learning rate. Everyone needs to be thinking about how to move fast. This happens very naturally at a startup, because everybody knows that if they slow down the rate of learning too much they will introduce the risk that the startup fails and they’ll lose their job. At a larger company, much of this “payroll risk” is gone. Even if an individual program gets defunded, employees can find other projects to work on at the company. So there is no “skin in the game” and nothing deterring them from introducing process when it’s not critical. Indeed, failure to perceive risk and introduce appropriate process to mitigate that risk could be career-limiting at a big company…while almost nobody would accuse those who introduced process of being the root cause of a program’s failures (even if they’d be right). You don’t usually get promoted by *removing* processes at a company. But maybe you should be!
While much of this is in the framing of the organization vis-à-vis the market, similar learnings apply to internal organization dynamics. In a transparent company culture with good communication, people feel comfortable to try new ideas and new ways of interacting with each other — they get candid and timely feedback about the success or failure of these approaches and can safely and rapidly iterate to maximize their personal effectiveness. On the other hand, an organization with executives that don’t give direct and timely feedback creates a culture of fear and uncertainty. People cannot safely learn what ideas and interactions are acceptable or not. Consequently, an organization’s ability to fully harness its people will be hindered, slowing down the organization’s overall ability to learn — and win.
A culture of “blameless postmortems” is also important for encouraging learning from failure and avoiding individuals fearing innocent failure. Percolating failures allows the organization to avoid repeating mistakes and build on the work of others. This allows the organization to move faster, execute better, and incorporate everyone’s ideas.
Finally, to address “you can’t manage what you can’t measure”, process latency must be measured and goals must be set and embraced by an executive team to reduce this latency and improve speed. Parties that contribute to measuring and improving velocity should be celebrated. I learned about this approach from Regina Dugan when she was running ATAP at Google. She quoted Linus Pauling: “If you want to have good ideas you must have many ideas. Most of them will be wrong, and what you have to learn is which ones to throw away.” Making it fast to try an idea let’s you try more ideas, which can allow you to be more innovative. She identified several basic tasks like the time from when a job needed outsourcing to when a vendor began work, or the time from completing interviews to sending a candidate a job offer, and mapped out the different stages that task could be in and how long it was in that stage. Once the data was in hand, she could have data-driven discussions about where the slowness was and how it could be improved. Who knew that innovation stems from decreasing contracting times through templating — or making sure your finance approvers aren’t all on vacation? (And a faster place is more *fun* to work, anyhow!)
Speed is a weapon. Learning rate is your key to success. Go learn!
