The Hero's Dilemma – Drag and Flow 01
Concentration of Strength or Expertise is Always a Bottleneck
Every hero fails without help.
At the office, we use our heroes up and throw them away.
Hero fixation is central to human story telling and certainly in every culture in its own way. We have different spins, but we have an appreciation for “the one”. And when we end up being “the one” it is a wonderful burden. We love being the person, hate the lack of freedom that the responsibility comes with, and we start to manage our time by “exclusivizing” our availability.
We will invent ticketing systems, tithes, and other rules to protect ourselves. As we do, we become even more exclusive and our hero status and level of “bottleneckiness” rises. People rely on us more and become followers. Work in the company slows to the hero’s ability to respond. Collaborators, co-creators leave the building and soon we are left with a sea of incapability.
Stay tuned for a story of how we can rebuild capability and get around Hero Fixation Drag, after a few definitions.
Hero Fixation Definition: When critical knowledge or processes are concentrated in a single person or small group of people it creates both dependency and burnout while generating bottlenecks throughout the organization and strangles innovation and improvement.
How it Creates WIP: The hero becomes overwhelmed with constant requests, interruptions, and context-switching between different urgent needs. Meanwhile, others accumulate waiting work that can't progress without the hero's input.
How it is Toxic: Creates unsustainable pressure on the hero, breeds resentment from both the hero and dependent team members and establishes a seemingly strong “expert” that hides a fragile system that crumbles when the hero is unavailable.
A Quick Story of How We Solved This: A sizeable startup with a large book of business created their product quickly in ways that delighted the customers, but left significant defects that could only be solved by the few remaining developers who had been with the company since the beginning. The tech behind the system was not capable of handling the load, the diversity of users, or even the specific functions being provided.
The whole company was crumbling around outdated decisions made when the startup was more interested in “experiments” than an actual product.
When we arrived the daily work was this:
Something breaks -> Hero works 8 to 14 hours fixing it -> Go to bed -> Wait in Terror for Repeat
Every single day.
We replaced this workflow with:
Something breaks -> Hero fixes it -> Go to bed -> Pair with other coder to refactor and document -> Fix Next thing that breaks with more shared expertise and confidence -> Repeat cycle less over time as product becomes more understood
The heroes were important because they were the only people that understood the product. The more they quickly “solved problems” the more they exacerbated the problems. They created code no one else could read, took shortcuts no one understood, and “fixed” the system a little worse every time.
The company became more and more dependent on them as they drug the company to bankruptcy.
The new system solved this problem by:
Built a Personal Kanban for the team that followed the new standard work, ensuring that before “done” was always “collaborate”. It was visual, unavoidable.
Making sure we took advantage of the hero’s expertise
Making sure the code was documented, understood by someone else, and immediately improved
Making sure that in the future, if things broke there was a higher likelihood that other people could respond
Removing the false assumption that only the heroes had value in the system
Gave the heroes a break so they weren’t overworked
Created a system that was more stable and maintainable
Ultimately this allowed the heroes to stop working on the original system and for them to spend time creating the Version 2.0 of the product that was built on technology that could actually handle the work, but doing that in a way that started with the expectation that clean code, documentation, and collaboration were valuable corporate assets.
Okay here’s the Personal Kanban because it has some added context
Here is a perfect recreation of the board we built to solve the hero problem.
I had finished this post and was ready to launch it, but realized there were some key points in hero culture to watch out for.
Hero Identification and Ownership - The hero currently identifies with the work and the need. The board and the new way of working needs to help fix the overall business problem without undermining the hero’s abilities or previous contributions. We don’t want to demoralize the hero before the problem is solved. To respond to that specifically, all tickets are “owned” by a particular hero at first, then a hero and team member later. The hero column and initial solution are all theirs unless they ask for a collaborator.
Humor During Adversity - The board was silly (originally it said something worse than “oh no”) but functional. Diffuse the “emergency of emergencies” by creating a working system that solves the problem without being overly process-driven, boring, or punitive.
Obviously Temporary - The board was on a white board, could be erased at any time, and the overall victory condition for everyone was not to need it any more. Don’t make your repair-state into a permanent solution.
Done is not “I’m Done” but is “The Work is Done”. - The done column has a state where the initial work is done, but the problem itself requires a waiting period to see if the fix worked. The '“definition of done” is that the problem does not come back, not that we finished our task. If more teams got just this one point, we’d have much healthier systems in this world. And, to be clear, we’ve seen or implemented this multi-step done column in construction, manufacturing, software, hospitals, etc. This is not “a software thing” and it absolutely applies to you.
CALL TO ACTION: If this is interesting to you, you can hire me and Toni to help (just message me on substack or linkedin), or take a class at Modus Institute, or simply get a paid subscription to Humane Work here on substack (button above).
This is what we do and have done for decades, and what we work with others on. Simple, visual, humane strategies to fix the real problems of work.
Isn't the story an example Theory of Constraints, except applied to purely human, i.e., not machinistic, context?
Granted, the humane context adds the whole layer of complexity. After all, a machine doesn't complain it has to wait for another machine, that happens to be a bottleneck.