A few weeks ago, we had a conversation about Shadow I.T. and about how it's actually a sign of gaps in your Developer Experience.
Today's adventure is going to pick up that thread; let's talk about what we can learn from The "I.T. Gunslingers" that lurk in our organizations, and how we should think about them.
No Plan Survives First Contact With The Enemy
Here’s the thing: the tools your developers build when no one’s watching? They aren’t just shortcuts or hacks—they’re artifacts. Evidence. Field reports from the frontlines of your broken processes and unclear growth paths.
So identifying and observing Shadow tooling should make us think, because:
- It reflects how your developers are improvising to accomplish their mission.
- It highlights what the organization should have built in the first place.
And if it does those things, shouldn't we intentionally make space for devs to have expanded influence in our strategy and architecture discussions?
Let’s unpack that.
1. Shadow Tools Aren’t Rebellion... They’re Research
There's a common subtext in architectural circles regarding "Shadow I.T.": it's treated with disdain. "These dirty stinkin' developers can't follow basic policies! They think everything is the Wild West and carelessly blow holes in our finely-crafted organizational framework!"
Let’s kill the myth right now: Shadow tools are not acts of defiance. They’re acts of necessity.
When a dev on your team spins up an internal CLI wrapper, throws together a Slack bot, or duct-tapes three dashboards into one, they’re not trying to go rogue. It's a COPING mechanism. They're doing this because they have an acute need for something that your architectural framework hasn't provided for them, and they're addressing the need as only engineers can: they build their way out from behind the 8-ball.
And that’s the perspective twist that you absolutely must adopt: shadow tools are often the purest form of platform research your company has. Think about it:
- They're truly opt-in; no pressure to use the shadow tool if it's not a genuine improvement.
- They're born of real pain. Workarounds are called that because they WORK AROUND a pain point!
- (If you don't squash them) They live or die based on developer demand rather than OKRs or politics.
If you attune to these shadow experiments, you'll learn lots of interesting things:
- Where your docs are failing you.
- Where the golden path breaks down.
- Where your devs spend their weekends building things they wish existed Monday morning, or last night at 3 AM when they were fixing a problem instead of getting some sleep.
Treating shadow tools as problems to shut down misses the point. The smart orgs know: if you want to understand your DevEx gaps, follow the shadows.
Shadow tooling is the user research your platform team didn’t know it needed.
2. Your Policies Are (Probably) Stifling Good Ideas and Initiative
Here’s the silent killer of good internal tools: nobody knows what building them gets you.
We say we want engineers to take initiative. We celebrate “going above and beyond.” But when someone builds a helpful tool that isn't on the roadmap, where does that work go on their promotion packet? Who’s going to back that “extracurricular” effort in a calibration meeting?
Too often, it doesn’t fit anywhere.
I've heard it said that engineers live on a spectrum whose two endpoints are "Imperial Navy Officer" and "Pirate". (In Dungeons & Dragons terms, we'd say we're either aligned as "Lawful" or "Chaotic")
Every one of the engineers in your organization is going to see the Developer Experience gaps. They'll feel the pain. Here's the catch: in most organizations, The Lawful folks won't fix it for you. They're going to live within the boundaries and wait for an official initiative to address it. They might be willing to speak up about gaps they've identified, but don't expect them to go and solve the problem... because that's not policy!
On the other hand, the Chaotics in your organization absolutely will solve the problem... by going to the Shadow Realm. They know they're breaking policy, but they evaluate "addressing the need" as of higher importance than "following the book".
But let's go back to the rule-followers a minute: smart, motivated devs who are wired to stay within the policy boundaries play it safe. They learn to accept the status quo. They bury ideas that could help everyone, because "owning developer experience" isn’t on their job description and breaking the rules isn't their nature.
You have talent in your organization that goes untapped because you have trained them to stay in their lane instead of fixing problems.
I'm sure you think of yourself as "encouraging innovation"... but... do you really?
3. Turning Shadow Builders Into Platform Co-Owners
If shadow tools are signals, the question isn’t how to shut them down. It’s how to listen better, respond faster, and elevate the builders behind them.
Here’s how you start:
🔍 A. Audit the shadows, don’t squash them
Create space for a regular “Shadow Demo Day” or internal tool showcase. Invite developers to demo the things they’ve built on the side: scripts, dashboards, bots, whatever. The purpose: Not to judge them, but to learn from them. Treat it like user research. What pain did this tool solve? Who else is using it?
This turns invisible effort into visible insight.
🧭 B. Add “DevEx ownership” to career conversations
If your promotion guidelines only reward shipping features, you’re telling your devs that internal experience work doesn’t matter. Bake platform impact, internal tooling, and cross-team enablement into your career growth frameworks, especially at senior levels.
If someone builds a tool that five different teams start using, that’s not “side work.” That’s architecture.
🪴 C. Plant seeds from the shadows
Some shadow tools won’t be production-grade, and that’s okay. But if one solves a real problem? Back it. Allocate platform team time to co-develop it. Offer maintainership options. Let organic innovation shape your roadmap.
Shadow tools don’t need to stay in the shadows. They can evolve into supported features... if your culture lets them.
🧠 D. Train leaders to recognize platform work
Engineering Managers and Technical Leads need to know how to spot and champion this kind of initiative. That means giving them the language to talk about DevEx impact and the permission to advocate for it during promotions and planning cycles.
If your leaders only value ticket velocity, they’ll never recognize the developer who's quietly saving everyone five minutes a day.
Shadow development isn’t a threat to your org; it’s a gift. But only if you’ve built a culture that knows how to receive it.
Wrapping up
It's easy for architecture teams to fall into the trap of thinking that their collaboration is unilateral: "we prescribe and they build". But that's extremely myopic (and not really collaborative)! Sometimes the engineers who are "in the weeds" have perspective that their buddies "in the Ivory Tower" can't see.
Shadow tooling is that perspective brought to life. It's the architecture decisions your team would have made, if they'd known where the friction really lived.
If you want better platforms, reward the people already trying to make things better. If you want engineers to grow, make sure there’s a path where internal impact counts. And if you want to unlock real developer experience insight, stop just talking to the users; start listening to the builders hiding in plain sight.