REMINDER: We're TWO weeks away from Season 5 on The Adventures of Blink over on Youtube! If you haven't done it yet, stop by the channel and click subscribe so you'll get alerts when new episodes drop each week - I'd love for you to come on an adventure with me! This season is going to hit you right in the nostalgia with a retro game build - just something fun to work on to keep those coding skills sharp!
Once upon a Time, there was a magical kingdom that produced the best software known to all mankind. When villagers requested things, their needs were fulfilled quickly and generously. When things went wrong, the King's Guard (and often even the King himself) would come and set things right. Everyone lived in harmony.
But the kingdom had grown to the point that it was no longer possible for the king to manage it on his own.
He decided to appoint his two most senior noblemen, each of whom would administer half the kingdom on his behalf: The Duke of Development and the Earl of Operations. Unfortunately, these two noblemen were at odds with each other, and the king's meetings with the nobles were contentious and stressful. In his desire to have a little peace and quiet, the king built a wall right down the middle of the castle - the western tower was for Development and the eastern tower was for Operations. Now he could have some quiet... the two nobles couldn't interact any longer!
Interestingly enough, the villagers weren't moved around at all. When you left the castle, you'd find developer teams and operations teams living near each other and traveling freely through each other's lands.
The Kingdom Was Very Serious About Rules, though
When the castle was split, the king was adamant that the nobles would not encroach on each other's responsibilities, and he issued an edict titled "A Separation of Duties":
- The Duke was responsible for ALL Development; no one in Operations could do that.
- The Earl was responsible for ALL Operations; no one in Development could do that.
The two sides began to bicker and argue constantly over whether some specific task belonged to one side or the other... and large contractual agreements -- "Memoranda of Understanding", if you will -- were created to ensure that everyone in the realm KNEW unequivocally whose role any given task was. Entire Departments of the lesser nobility were ordered to manage all of these agreements and maintain them meticulously.
Changing anything required extensive permissions and approvals from people who lived in faraway villages. Entire committees had to convene, bringing in nobles from across the whole realm, any time anything needed to get done.
And if something went wrong, a special committee would gather to rewrite the rules "so this will never happen again".
And... nothing got better.
The rules were meant to prevent mistakes, but they mostly just prevented improvement.
The Subtlety That Was Destroying the Kingdom
The King wasn't some evil fiend. The Duke and Earl were well-meaning nobles. Yet everything went wildly off the rails. How did things become so argumentative?
The Process became a substitute for critical thinking.
A common trap of designing large organizations is that we believe we can codify everything. "Write a manual that explains everything that happens in our Company, and then just use that." This seems logical enough on the surface, but as the philosopher đ Mike Tyson famously said,
"Everybody has a plan until they get punched in the mouth."
Our need to control every outcome will always prove our undoing... because while you might be able to make your Process comprehensive, it will only succeed at enforcing obedience. Creativity, thinking on-the-fly, and making adjustments will be labeled negatively: first, as "out of Process", but then "noncompliant" or even "dangerous".
The act of improving things will be reserved for a few... and that will be perceived as 'privilege' rather than 'responsibility'. Don't you want everyone to feel responsible to make things better???
The Mysterious Traveler
One day a traveler from a faraway land arrived at the gates of the realm. He set up his shop in the market and became part of the community. As a newcomer, he listened intently to the kingdom's rules - not that he had to do anything to hear them, as they were shouted from the parapets of the castle every day:
- "Follow the Process!"
- "Separate the Duties!"
- "That's Development Work! Send it to them!"
The voices were loud, and they were insistent. But the Earldom of Operations was suffering:
- The Duke of Development was constantly making changes that no one in the other Duchy understood, and he was constantly pushing for changes to be made even faster and more frequently, beyond what anyone in Operations could do. There were never enough villagers in Operations.
- Every time something broke, someone from an Operations village had to reach out for a senior nobleman from Development to come and assist. That meant things were broken for a lot longer, since the travel time was long between the two villages.
The traveler also heard that things weren't going well for the Duke of Development, either:
- "The Kingdom's Treasury will be empty unless we make this change by next week!"
- "Villagers are suffering; we can help them but things move too slowly through Operations!"
- "We have a way to alert the King's Guard to problems faster, but we can't make the change until next summer according to the Roadmap!"
Something in particular gnawed at the traveler, however: in all his visiting and interacting with both sides of the kingdom, he never once heard anyone say, âYou are forbidden from making this better.â
The only thing holding either side back from success was the wall that ran through the castle.
The difference between permission denied and permission never requested
The traveler, who had lived in both development and operations villages in other kingdoms, recognized that many of the problems faced in both villages could easily be solved by the other. So he decided to do something about it.
The First Small, Unapproved Good Deed
Late one night in his small house on the outskirts of the Operations village, he ran into someone who had been assigned a task. The person was planning to be up all night, because that's how long this task usually took. But this time, the traveler opened his Development toolbox and used the tools to solve it.
It wasn't much - a tiny fix, a small script that automated the task. It cut the time from hours down to seconds. He gave his fix to the villager and disappeared into the night.
The next night, he did it again - he wasn't rewriting all the Company's software, just connecting a couple of dots in a small, reversible, safe, and (most importantly) helpful manner.
He wasn't holding meetings. He didn't have a project on the Duke of Development's ledger. Nobody was signing off on these small fixes. Just empathy and skill, intersecting in an Operations village.
Amazingly, the world... didn't end.
The Quiet Magic of Small Improvements
Usually we refer to this kind of work as "Shadow Development"... but maybe that's giving it too "spooky" a name.
What if instead we decided to call this "stewardship"? Or "empathy"?
One small improvement makes another possible. And then another. And then another. Pain decreases, confidence increases.
Over time, we'll see others begin copying this behavior... just looking out for their brethren in Development and Operations... and even more interestingly, they're now treating BOTH Development AND Operations as brethren!
"Shadow Tooling" conjures a mental image of "The Resistance"... "The Rebellion"... but nothing could be further from the reality. When we engage in these kinds of improvements, we're trying to make it better.
The Fate of the Traveler
Gradually, the Operations village came to understand the Development village... and Development came to understand Operations. Through small acts of kindness (and dare I say, love?) the villages partnered again, each bringing their individual skills and talents to bear solving problems for the other.
At first, the Nobles didn't even know it happened.
But eventually, the change in posture was so striking that everything came to light. All the rule-bending, all the work done in the shadows... everything.
Leadership didnât reward the change. But they also didnât punish it.
What This Fairy Tale Is (And Is Not) Saying
First, let me tell you what this is NOT:
- âIgnore securityâ
- âBreak productionâ
- âDisrespect your teammatesâ
What it IS, though:
- "Make small things better"
- "Reduce suffering where you stand"
- "Act within your competence"
- "Leave things better than you found them"
Final Note: The Cost of Waiting for Permission
Collectively, we seem to think that "waiting for approvals" (waiting for permission) is a means of safety. Let's think about what it means in reality, though:
- Broken systems stay broken
- People disengage as their attention span expires
- Good engineers become caretakers of misery
- Organizations confuse compliance with safety
They get so caught up in following the rules that they don't stop to think about whether the rules make sense.
The Wrap-up
You donât need anyoneâs permission to make life better.
You just need to start small,
act carefully,
and care more about outcomes
than appearances.
Top comments (0)