Indeed. Certainty bias is the term we use in reference to organizations’ tendency to demonstrate overconfidence in desirable outcomes while in fact operating in an environment of uncertainty. A lot of organizations are exposed to this phenomenon. Yours too, most certainty… no pun intended. The problem has some typical symptoms:
- Assumptions are perceived as facts
- Organizational behavior is predefined and over-constrained
- The gap between reality and plan is never properly understood
As a result, we get a whole bunch of “funny” things happening in the enterprise; and those are not exactly “ha-ha”-funny. We see product management that obsesses with scope while there’s no evidence of its value whatsoever. We see long-term, fairly detailed organizational plans that span unimaginable amount of time and cannot be delivered in principle the way it was intended. We see budgets that are tied to detailed scope and we see capacity expectations which never work out. But despite all that, what’s much worse is that the organization continues to live under the impression that it’s actually all working out just fine. The organization de facto loses its ability to learn. The gravity of a fine-elaborated plan with scope and budgets attached to it takes huge toll: people at different levels tend to acquire political skills much rather than the ability to problem-solve and as a result, often chose not to raise systemic issues even if they happen to stumble upon them. Everyone becomes a hostage of the system, which is a result of the flawed thought process.
Okay, but what’s the right thought process then?
I will try to briefly summarize it as a set of principles, a vector in the direction that provides a better toolset for dealing with systems of uncertainty. Here they are:
- Aim at business outcomes
- Minimize unmanaged assumptions
- Align individual motivation with value delivery
- Provide room for emergent behavior
- Exploit cross-level learning
1. Aim at business outcomes. Hmm… Of course everyone aims at business outcomes, what else should they aim at?
Well, while it really sounds simple and obvious, it doesn’t mean that it actually takes place. What do you think a product manager is aiming at when they demand “all these features” from the team, having no idea whether any of it will produce business value? Or a team that is obsessed with cycle time. Deliver more! Deliver faster! …Does it produce more loyal customers or more revenue or significant long-term competitive advantage? Are those questions even being asked when making scope, quality, schedule or cost decisions?
2. Minimize unmanaged assumptions. Assumptions inevitably arise when we are operating in the environment of uncertainty: we don’t posses full knowledge over organizational behaviors and outcomes. Therefore we assume. The problem comes when we assume this and assume that every step of the way, while pretending that those are not assumptions but rather firm facts. Why do we think this scope will have the anticipated business impact? Will the other team provide the functionality that our team needs? Will this data connector work? Will this funding be sufficient for the initiative? Assumptions are everywhere: in business and technology strategy, in requirements, in implementation approach, in team and skill-set structure, in funding, in interpretation of the company’s bottom-line and more.
On the one hand, the problem is in that we don’t acknowledge assumptions and don’t manage them as such. On the other hand, due to ineffective process and structure, we tend to spawn assumptions in large quantities where they could be avoided in the first place. So, for instance, a rigid structure of teams that have significant dependencies on each other creates unnecessary assumptions that could have been avoided should the teams be more flexible and organized to better contain the dependencies rather than have them scattered across the organization. Similarly, rather than having requirements trickle down the long organizational hierarchy, which ironically enough, bypasses customer every time and generates more and more bold assumptions (of both what to build and how to interpret the requests from above), it would be a lot more productive to provide each team or a small group of teams with a stakeholder with the sufficient requirements decision-making authority who directly interacts with the customer and a few key internal stakeholders.
3. Align individual motivation with value delivery. The type of motivation that dominates across the industry, is usually only loosely connected with value delivery. Organizational leaders should be the ones to take care of this problem, but they are themselves subjected to the same blind spots as everybody else and, as interesting as it sounds, can hardly be blamed for anything. To best illustrate the detail behind this principle, we need to ask ourselves, what organizational behaviors and qualities are we after when we talk about value delivery. Well, we are looking for collaboration along the pathways of critical dependencies, we’re looking for flexibility to be able to respond to new facts, we are looking for openness and transparency for communicating and eliminating impediments. But is that what we usually see? Managers that are overly possessive of “their” people, even though another team or program badly needs help with high-priority work, are hardly a good example of a collaborative spirit. Similarly, who would be motivated to respond to change when the top leadership creates an immense pressure to deliver according to a master plan and measures everyone’s “productivity” based upon that? Finally, what manager would like to be known as the barer of the bad news, given that mostly the “yes-men” and the “happy land” folks get promoted in their organization; no wonder that systemic impediments remain forever unaddressed. The right motivation model has to found human motivation upon adequate thinking and seek to enable the organizational qualities, some of which we mentioned above.
4. Provide room for emergent behavior. One of the deadly sins that stem from the certainty bias is the idea of preprogramming the enterprise. We aim at preprogramming the organization because we lack the right model for thinking about organizational behavior; something that would show us how flawed is that idea in the first place. We tend to believe we can preprogram market conditions, customer needs, scope, team behavior in implementing it, etc. It’s the “clock mechanism” model. Instead, it’s better to think of your organization’s ecosystem as of a city or a garden. You can never direct a specific way in which a city or a garden evolve. You can influence them, of course, by affecting various enablers but never to expect the exactly predefined behavior. A city may decide to sell some land to a hotel chain to attract more small business to the area, but which business will end up there and what other enablement will they require – there’s no way to know upfront. You may decide where to locate different plants in your garden but you can’t expect them to grow precisely like you want. You will know more as you go, but to respond to new facts, you need to preserve flexibility for behaviors you don’t yet know. So, how exactly is an enterprise supposed to provide flexibility for emergent behavior? Well, how about creating plans that explicitly contain the unknowns, multiple possible solution options and experimentation required? How about the funding being detached from exact scope expectations? How about team and department boundaries being a bit more flexible for people to be able to swarm around the problem, when needed?
5. Exploit cross-level learning. It is impossible to establish any of the above, if this aspect of the organization’s life is not in place. See, it’s very easy to believe in long-term fixed scope commitment or in scope-based funding or in the detailed upfront architecture or in the flawlessness of your team structure, when there’s no information flows in place that would demonstrate the gap between those beliefs and reality. Every organizational layer lives with their own sweet, comfortable version of the truth. The idea behind the principle is very simple, there needs to be a mechanism that, in a sense, “collapses the pyramid”. This does not necessarily imply that organizational levels should be abolished, but they have to start to operate differently, overlapping a lot more across multiple levels at a time and immersing themselves into the rich context of experimentation, execution and validation, rather than staring in their dashboards filled with vanity metrics.
This may be enough for the initial discussion on the topic, enough for you to start thinking about it in the context of your organization. Start by asking yourself how your current organizational reality support the principles above.
By Alex Yakyma, Org Mindset.