Erin was a newly-promoted manager over a software engineering team. She had been hired 5 years ago as a junior developer and worked on 3 major projects in her time with the company - one of them a multi-year build that moved the company's flagship application to an altogether new stack, saving hundreds of thousands of dollars in licensing and infrastructure costs.
Once she was promoted to manager, the normal corporate leadership pressures took over and she of course had a ton of new responsibilities to learn... but within 6 months of her promotion, she was spending her lunchtime building her first AI application because she wanted to see how to use LLMs to find evidence in her mailbox and Slack history for filling out her team's performance reviews.
James joined the company 15 years ago as a sysadmin assigned to handle a special operating system audit being performed as part of trying to win a new contract. After that audit was completed and the contract was won, he was promoted to supervisor of "the Audit Team", which then formed the foundation of a Governance and Compliance organization. After several years as a supervisor he was offered a promotion to Manager of the organization.
As a Supervisor, James spent most of his time in meetings, coaching his Audit Team and providing meticulous attention to the details of changing audit controls. While he was the first to admit that he was "not technical at all anymore", he regularly went toe-to-toe with all of the Software Engineering Directors across the organization, ensuring that everyone in the organization followed every Audit Guideline to the letter. He was immensely proud of The Audit Handbook, a 1,400-page PDF that documented with laser-precision everything that Developer Teams were absolutely required to do to stay compliant.
Erin's lunchtime experiment uncovers a need in the organization: to provide context for the glowing reviews she wants to give her team members. She talks about it with the engineers on her team, and they exchange ideas; they even possibly collaborate on it some! Through the excitement she generates, she's building relationship... and importantly, respect. Engineers love a manager who can "get in the weeds" in a helpful way, and Erin's experiment is keeping her technical skills sharp in a way that helps the organization. Her curiosity is infectious. While she knows she's not writing mission-critical code like her team members, her team comes to respect her because she can relate to their day-to-day struggles.
James, on the other hand, is building something different: ** DISTANCE**. Every audit finding report, every mistake found across the organization... they all become a new Rule, or Checklist, or Procedure, added in perpetuity to the all-consuming Handbook. And as the Handbook grows, the
You could sum it up like this: The more Governance Processes James creates, the less he actually understands the work he's "Governing".
Erin got closer to the work.
James built systems that kept him farther away from it.
Think about it: Technology moves incredibly fast. The state-of-the-art systems we built 5 years ago are dinosaurs today. With that kind of half-life on knowledge, staying current requires effort. And just like the old "telephone game" we played when we were kids, every time the knowledge passes from one person to another without firsthand experience, errors multiply. In James's case, policies created far from execution accumulate friction.
And before you say "Hey Blink, your example is fictional and contrived and unrealistic"... answer a couple questions for me:
The farther you are from the work, the easier it is to be confident about things that aren’t true.
Erin is a model manager because her curiosity shines through. But did you notice what she didn't do?
She picked a task that would be of benefit, but that wasn't in the critical path. It gave her the ability to touch the system, to feel the friction. This gives Erin a taste of the reality that her team faces every day. When she has to put on her manager hat and make decisions about how work gets done... she's built EMPATHY by experiencing the friction herself.
They'd be loath to admit it, but... companies in general incentivize their management to "grow" in this way. Oh sure, while things are small and lean and scrappy the managers remain hands-on (possibly too much... it's a delicate balance), but when an organization reaches a certain size, management-hierarchy politics finally catch up to the growth curve. Then the org has to start "cultivating" managers, and they start setting up rewards for stuff like:
Now none of these things are problems by themselves (as much as I hate meetings 🤮), but they're supposed to be means to an end, not the end itself.
As a manager's job becomes more abstract and less rooted in the actual work, the organization encourages them to become "more T-shaped" and broaden their exposure... so they start managing adjacent teams.
Or even non-adjacent ones. 😱
Soon, the people designing the system are the ones least affected by it; even worse, they have absolutely nothing concrete to connect all their abstractions to.
Leaders with "Dirty Hands" may not be an expert in whatever their team does, but they could perform at a "junior level"... but leaders with "Clean Hands" can't even fall back on that. And that leads me to the accusation I'm leveling at you leaders today:
If you don't ever do what your team does, you probably don't understand it. And if you don't understand it,you shouldn't be in charge of it. Hear me out: I'm not just doing this to throw shade, and I'm not saying you're in a pickle you can't get out of.
I'm saying you need to engage. Start doing the kind of work your team does... in a low-stakes environment, inconspicuously... but get your hands in the dirt a little bit, just so you know what the dirt feels like.
Consider it "Professional Development"... that actually develops you.