You Don't Need Anyone's Permission To Make Life Better: A Blink Fairy Tale

Source: Dev.to

If you haven’t already, head over to the YouTube channel and subscribe so you’ll get alerts when new episodes drop each week. I’d love for you to join the adventure! This season will hit you right in the nostalgia with a retro‑game build – a fun project to keep those coding skills sharp.

🏰 A Tale of Two Kingdoms

Once upon a time, there was a magical kingdom that produced the best software known to all mankind.

• Villagers’ requests were fulfilled quickly and generously.
• When things went wrong, the King’s Guard (and often the King himself) would set things right.
• Everyone lived in harmony… until the kingdom grew too large for the King to manage alone.

The Division

The King appointed his two most senior noblemen to administer half the kingdom each:

Unfortunately, the Duke and the Earl were constantly at odds. To force peace, the King built a wall right down the middle of the castle:

• Western tower → Development
• Eastern tower → Operations

The wall prevented the two nobles from interacting, but the villagers still lived side‑by‑side and traveled freely through each other’s lands.

The Edict: “A Separation of Duties”

The Duke is responsible for ALL Development – no one in Operations may do that.
The Earl is responsible for ALL Operations – no one in Development may do that.

📜 The Consequences

• The two sides bickered constantly over which tasks belonged to whom.
• Massive Memoranda of Understanding were created so everyone KNEW whose role any given task was.
• Entire departments of lesser nobility were tasked with managing and meticulously maintaining these agreements.

Changing anything required:

1. Extensive permissions and approvals from distant villages.
2. Whole committees to convene, pulling nobles from across the realm.

If something went wrong, a special committee rewrote the rules “so this will never happen again.”

Result: Nothing got better.
The rules meant to prevent mistakes mostly prevented improvement.

The King wasn’t evil, and the Duke and Earl were well‑meaning, but the kingdom went wildly off the rails.

Why Did It All Become So Argumentative?

A common trap in designing large organizations is the belief that everything can be codified:

“Write a manual that explains everything that happens in our company, and then just use that.”

On the surface this seems logical, 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 becomes our undoing. Even a comprehensive process enforces obedience, labeling creativity, on‑the‑fly thinking, and adjustments as:

• “Out of Process” → “Non‑compliant” → “Dangerous”

Improvement becomes a privilege rather than a responsibility.

Don’t you want everyone to feel responsible for making things better?

🧭 The Traveler’s Observation

A traveler from a faraway land arrived at the kingdom’s gates, set up shop in the market, and became part of the community. He listened intently to the kingdom’s shouted rules:

“Follow the Process!”
“Separate the Duties!”
“That’s Development work! Send it to them!”

The Operations Side Was Suffering

• The Duke of Development made changes that no one in Operations understood.
• He pushed for faster, more frequent changes—beyond what Operations could handle.
• Operations never had enough villagers.

Every time something broke, an Operations villager had to summon a senior Development noble, lengthening downtime because of the travel distance.

The Development Side Was Suffering Too

• “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 faster, but we can’t make the change until next summer according to the Roadmap!”

Crucially, the traveler never heard anyone say, “You are forbidden from making this better.” The only thing holding either side back was the wall that ran through the castle.

🛠️ The Traveler’s Decision

Having lived in both Development and Operations villages in other kingdoms, the traveler recognized that many problems could be solved by the other side. He resolved to act.

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…

(The story continues…)

🎮 Join the Adventure!

Don’t miss the upcoming retro‑game build and the lessons it will teach us about collaboration, flexibility, and breaking down walls—both literal and metaphorical. Subscribe now, and let’s embark on this journey together!

The Tale of the Quiet Fix

…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.

• No meetings.
• No project on the Duke of Development’s ledger.
• No sign‑offs.

Just empathy and skill, intersecting in an Operations village.

Amazingly, the world… didn’t end.

Usually we refer to this kind of work as “Shadow Development”, but maybe that’s giving it too spooky a name.

What if we called it “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 – looking out for their brethren in Development and Operations, and even more interestingly, treating both 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.

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. 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.

First, let me tell you what this is NOT

“Ignore security”
“Break production”
“Disrespect your teammates”

What it IS

• “Make small things better”
• “Reduce suffering where you stand”
• “Act within your competence”
• “Leave things better than you found them”

Why “waiting for approvals” isn’t safety

• 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.

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.