Shielding your engineering team isn’t about keeping them in the dark. It’s about cutting through the noise so they get the real message—why their work matters, who it helps, and what success looks like. Too many managers mistake shielding for silence, but that’s a failure of communication, not protection.
Roman Nikolaev recently argued that shielding means letting coders just code, but that’s a false choice. Shielding isn’t about hiding the business from engineers; it’s about filtering out distractions like politics, shifting priorities, and last-minute requests while still providing clear context. If your team doesn’t understand the business, it’s not because you shielded too much—it’s because you communicated too little.
The idea of shielding comes from Robert Sutton’s work, which shows good managers protect their teams by slaying dragons—meaning they reduce distractions so engineers can focus on meaningful work. That doesn’t mean locking them away from customers or strategy. It means cutting out meetings that waste time, conflicting priorities, and scope creep, none of which add value or clarity. Shielding is about protecting the environment for good work, not creating ignorance.
The key is to filter noise and translate signal. Shield your team from organizational chaos, but shield them with context: why this work matters, who benefits, and how it ties into strategy. Bad shielding sounds like “Just build what’s in the ticket.” Good shielding sounds like “We had three competing priorities, but I fought to focus us on the one that solves this key customer problem.” Both are shielding, but only one empowers engineers with understanding.
This isn’t new thinking. Labeling engineers as just coders is industrial-era Taylorism. In complex environments, those closest to the problem must make decisions—and they need context to do that. Product-minded engineers who understand the business become invaluable contributors and leaders. They don’t develop that insight by being shielded from it—they develop it when managers do the hard work of filtering noise and letting the signal through.
Roman is right to call out managers who hoard information and call it protecting the team. This “shit shield” mentality treats the rest of the company as the enemy and stifles collaboration. The “hero manager” who fixes every problem and absorbs all chaos leaves their team unprepared and infantilized. This isn’t leadership; it’s dysfunction. The problem isn’t shielding too much—it’s shielding badly. Removing the shield entirely just exposes engineers to chaos they can’t handle. Leadership is about disappointing people at a pace they can absorb, not dumping the whole mess on them at once.
That said, this framework isn’t universal. In crises, no filtering happens—everyone needs full visibility. Small teams don’t need shielding because they’re already in every conversation. And if you’re the only channel between engineering and the company, you’ve created a bottleneck, not a shield. Plus, if your team doesn’t trust you to filter accurately, they’ll hear “shielding” as “hiding.” That’s a leadership failure, not a shielding problem.
In my experience, the best managers overcommunicate context. My teams know when sales miss targets, what that means for product, and when board decisions might shift priorities before it lands on their desks. Not every detail, but the signal: what changed, why, and what it means for their work. I’ve learned it’s about balancing context, trust, and space to do their craft. Remove any one, and you get diminished output. Too much context without trust feels like surveillance; trust without context feels like abandonment; and space without either feels like neglect. It’s a trade-off, but the worst failure is an engineer building the wrong thing because no one explained why it mattered.
Ask yourself: can your engineers explain why they’re building what they’re building this sprint? If not, you’re siloing, not shielding. When did you last filter out something your team didn’t need to know? Do they know who their users really are? And are you the only communication channel to the rest of the company? If yes, you’ve built a bottleneck, not a shield.
Shielding the team doesn’t mean silence. It means filtering noise, translating signal, and making sure your team has both focus and context.
You can read the full article—with all the data and sources—on ThePragmaticCTO Substack.
Read the full article — with all the data and sources — on ThePragmaticCTO.
