Shielding the Team Doesn't Mean Silence
You didn't shield too much. You communicated too little.
You didn't shield too much. You communicated too little.
Roman Nikolaev, a Head of Technology who writes a weekly engineering leadership newsletter, posted this on LinkedIn:
"I was taught that a manager's role is to shield the team. Let coders code. This is wrong. Engineers need exposure to the business side. They need to understand why they are doing what they are doing, who the client is and how their work helps her. 'Let coders code' is a dangerous fallacy."
He is partially right; but his framing is completely wrong.
Roman presents shielding and context as opposites; as if protecting your team's focus means keeping them ignorant of the business. That's a false choice.
Shielding the team never meant siloing away from the rest of the company.
It meant filtering out noise (organizational politics, thrashing priorities, executive drive-by requests) so engineers could focus on work that matters. Done right, shielding is the mechanism that delivers context; it removes the static so the signal gets through. If your version of "shielding" produced engineers who didn't understand the business, you weren't shielding too much; you were communicating too little. The job isn't to choose between protecting focus and providing understanding. The job is to do both.
Roman's post resonated with me because it is a pattern I seen come up time and time again: managers who absorb everything, translate nothing, and call it protection.
You've probably seen it, and even worse, suffered the consequences. A well-meaning engineering manager who thinks "shielding" means absorbing every piece of organizational stress until they burn out or their team operates in a vacuum. That pattern is a failure of management, not a failure of shielding; conflating the two leads to the wrong solutions. And the wrong fix, and eventually it creates a different kind of dysfunction.
What "Shield the Team" Means
The concept didn't emerge from nowhere. Robert Sutton, a Stanford professor, wrote the foundational case for managerial shielding in Harvard Business Review back in 2010. His argument was straightforward: "the best bosses identify and slay those dragons, thereby protecting the time and the dignity of their people and enabling them to focus on real work." He cited William Coyne, former R&D head at 3M, who was determined to let his teams work for long stretches -- unfettered by intrusions from higher-ups. Good bosses reduced outside distractions; they streamlined processes, championed focus time, and occasionally defied their own bosses when necessary.
What teams need to be shielded from is pretty obvious. Unnecessary meetings that consume hours without producing clarity. Thrashing priorities -- executives changing direction every two weeks. Drive-by requests from stakeholders who skip the prioritization process. Scope creep and last-minute changes that undermine sprint commitments. Conflicting priorities from multiple stakeholders who haven't aligned with each other.
None of that is about hiding information. None of it requires keeping engineers ignorant of the business. Every item on that list is noise; none of it is signal.
Shielding was never about preventing engineers from understanding customers or removing them from strategic conversations; it was about protecting the conditions under which they could do their best thinking. The distinction matters because Roman's post conflates the practice with its worst misapplication. If someone told you "shield the team" meant "keep them ignorant," they taught you wrong.
Filter the Noise, Translate the Signal
A manager's job isn't to choose between protecting focus and providing context. It's one job with two halves: filter the noise, then translate the signal.
Shield FROM the things that destroy focus without adding understanding. Shield WITH the things that turn code into informed decisions -- business context for why this work matters, customer understanding for who benefits and how, strategic clarity for where this fits in the bigger picture.
The difference between bad shielding and good shielding isn't volume; it's direction. Bad shielding sounds like: "Don't worry about it, just build what's in the ticket."
Good shielding sounds like: "The board is pushing for Q3 delivery on three competing priorities. I've negotiated us down to one. This is the one that matters most to the business, and here's the customer problem it solves."
Both are shielding. Only one leaves engineers in a contextless void.
This isn't a new idea. Stefan Wolpers has called the "developers just code" mentality pure Taylorism (industrial-era thinking applied to knowledge work). "In a complex environment, those closest to a problem are best suited to make the right decision to solve it." They can't make those decisions in a vacuum; they need context, customer proximity, and an understanding of business constraints.
Gergely Orosz has documented the same pattern from the engineer's side -- product-minded engineers who understand the business become key contributors and team leads. Engineers don't develop product sense by being shielded from it; they develop it when managers filter the noise and let the signal through.
Where Roman Has a Point
Roman isn't reacting to nothing. Plenty of managers do exactly what he describes -- they absorb every piece of organizational input, translate none of it, and call the result "protecting the team." The protective bubble is a documented anti-pattern; Jade Rubick has argued that the "shit shield" mentality frames the rest of the organization as the enemy and prevents the cross-team collaboration that makes organizations work. "An organization composed of self-protecting teams," Rubick writes, "isn't an effective organization."
The hero manager syndrome makes it worse. The Fixer solves every hard problem personally, robbing the team of growth opportunities. The Shit Umbrella absorbs organizational chaos to create a false sense of stability; the team is unprepared when reality eventually breaks through. The Hen fights every battle on the team's behalf, even battles nobody asked them to fight. The pattern across all three is the same: "This protection from reality is not leadership -- it's infantilizing."
These are legitimate dysfunctions. I have seen them. Roman has probaby seen them. Most of us have.
The problem isn't that these managers shielded too much; it's that they shielded badly. Removing the shield doesn't fix the underlying failure -- it just replaces one kind of dysfunction with another. Engineers exposed to raw organizational chaos without filtering or context don't become empowered; they become paralyzed. Ronald Heifetz and Marty Linsky put it precisely: "Leadership is disappointing people at a rate they can absorb."
Not all at once. Not never. At a rate they can absorb.
Where This Breaks Down
This framework isn't universal.
In crisis mode, everyone needs to know everything. When the production system is down or the company is facing an existential threat, filtering is information suppression; the framework assumes normal operating conditions.
On small teams (five people, early stage) there's no noise to filter. Everyone is already in every conversation. Shielding is a scaling function; it matters more as organizational complexity grows.
If you're the only channel between engineering and the rest of the organization, you haven't built a shield; you've built a bottleneck. Good shielding includes creating direct connections where appropriate -- not making yourself the permanent intermediary.
And if trust is broken, none of this works. A team that doesn't trust their manager to filter accurately will hear "I'm shielding you" as "I'm hiding things from you." That's not a framework problem. That's a leadership problem.
What I Do
Since the first time I became an engineering manager, I've tried to be the kind of manager I wanted to have. That meant seeding context early and often -- to the point of overcommunication.
My teams know when sales missed targets this quarter and what that means for the product org. They know where pressure is likely to come from before it arrives. If a board conversation is going to shift priorities, they hear my translation of it before the mandate lands. Not every detail; not the political maneuvering behind it. The signal: what changed, why it changed, and what it means for the work in front of them.
I believe in hiring smart, talented people. That kind of person does their best work with context, trust, and space to execute their craft. Remove any one of those three and you get diminished output from someone capable of much more. Context without trust feels like surveillance. Trust without context feels like abandonment. Space without either feels like neglect.
The trade-off is real; overcommunication takes time, and not every update lands the way you intend. Some context creates anxiety rather than clarity. I'm still learning and calibrating after years of doing this. But the failure mode I fear most isn't sharing too much -- it's the engineer who builds the wrong thing because nobody told them why it mattered.
Questions to ask yourself
Can your engineers explain why they're building what they're building this sprint? Not the what -- the why. If they can't, you're not shielding. You're siloing.
When was the last time you filtered something out that your team genuinely didn't need to know? If you can't remember, you might be passing through too much noise.
Do your engineers know who their users are? Not the persona document. The people. If not, that's not a shielding problem; that's a connection problem.
Are you the only channel between your team and the rest of the organization? If yes, you've built a bottleneck, not a shield.
Shielding the team doesn't mean silence. It means deciding what's noise and what's signal -- and making sure the signal gets through.