“Far over the Misty Mountains cold,
To dungeons deep and caverns old,
We must away, ere break of day,
To seek our pale enchanted gold.”
Isengard had only one gate, which faced south. In other directions it was surrounded by the arms of the southernmost peak of the Misty Mountains — a great mountain range extending far up north. The mountains, so vast and mysterious, were hiding a lot of dangers that made it really hard for unwanted guests to do a safe passage. Goblin town on the north, the underground city of Moria located beneath the mountains (the fellowship took this path) and wandering orcs among the peaks. Considering altitude and harsh weather, Misty Mountains were a great defense wall for Isengard fortress from most of the outside threats.
You can probably recognize some product organizations or leaders that try to settle near the slippery slopes of great mountains to hide from specific kind of invasions — external forces questioning the way we craft our product. In this case, hiding behind the mountains means a total rejection of the knowledge and experience from outside the product team. The two pillars of this rejection are discrediting the authorities and deprecation of methodologies.
There’s a scheme of keeping these pillars in place — the rejecting leader uses simple rhetorical tricks to keep them wise guys behind the mountains.
The “We are special” trick.
Heart of this trick is to point out some unique circumstances that distinguish a rejecting leader’s product ecosystem, market or other important factor from “all of them out there”. If, for example, he can prove that his delivery department is bigger than suggested in SAFe methodology, it’s clear he can trust none of its instructions: they’re simply not suited for him. Or, the cheapest variant of “We are special” trick, we don’t have time for MVPs (to avoid failing fast), because time to market is a crucial metric in our case (we’re in a rush to fail). IDIs also last too long, obviously. And so on.You get the point. There’s always something exceptional and unique in the way we operate, hence we cannot trust that those general, probably inaccurate guidelines are useful.
Blind-spot hunting trick.
Every methodology, just like scientific disciplines, has its boundaries — the field of interest. That means it’s always possible to find an unaddressed problem, a blind-spot on the shady borderline of this field. And these blind-spots are a playground of this trick. One simply hunts down a blind-spot of methodology and elevates it as a fundamental issue for specific discipline. If this methodology lacks answers for something so crucial (allegedly), then it isn’t complete. Not being complete means being vulnerable for surprises, means being untrustworthy. Case closed.
For example, once we tried to implement product discovery Kanban in our organisation. Senior leadership discarded it as incomplete because it… lacked strictly identified criteria for decision process in the exploration loop.
The most cynical way of rejecting external knowledge is to pretend we actually embraced it. One implements a process or methodology in a slightly, but essentially changed form. The adapted way of work becomes “our way of work”, and it’s a gold plated wonder, a semi-outer layer of mountains impossible to cross. Do you need lean? — “Nah, we have our process, it’s lean-reinvented, we’re cool”.
The disguise sometimes evolves to a blatant lie. A great example would be organizations having scrum teams and claiming to be agile, at the same time violating literally all Agile Manifesto principles.
Obsession with control
I once heard one product leader say: “Nobody will tell us how this stuff should be done. It’s us who knows it the best”. Simple as that. That’s the climax of this destructive product organization antipattern.
Having to learn only on your own mistakes is tough, undoubtedly. But probably the most devastating effect of hiding your team behind Misty Mountains is people getting used to “our way of working” and losing the ability to constructively challenge the status quo. Being isolated from the world also makes it harder to catch up with accelerating change, not to mention innovate.
Fear of the external knowledge and experience comes from obsession with control. If I commit to a particular way of doing things, wouldn’t I be somehow forced to obey the preachers and apostles reinterpreting and reforming “the law” all the time? Even if I become one of them, wouldn’t I become a slave of my own rules? These are exaggerations, but I guess that’s where the truth lies.
It’s not all or nothing
I used to be sceptical about methodologies. I even remember how reluctant I was back in 2006, when I was about to work in a SCRUM team for the first time. Ofcourse, SCRUM didn’t last in its pure form in our company, but after being adapted to our conditions it improved the way we worked. I’m still more of a laggard than an early adopter. In fact, I can’t recall a single case of successful product-related methodology implementation done comprehensively. Although, every time product team takes an effort to adjust it to its needs, nice things happen. It’s simply not all or nothing, if you can improve your craft by employing some pieces of methodology, it’s good enough.