Why Don’t We Talk More About Transparency?
In real-world projects, uncomfortable truths often get buried in status meetings. Delays are sugar-coated, technical debt is ignored, and communication issues are swept under the rug. Not out of malice, but out of fear—fear of punishment, judgment, or being labeled the “bearer of bad news.”
Decades ago, this dynamic got a nickname: the “Masked Man.” It’s a metaphor for the anonymous or impersonal role someone plays when delivering uncomfortable truths. But in an age of agile, feedback, and transparency—why do we still feel the need for masks?
Where Does the “Masked Man” Come From?
A student from another university recently reached out to me asking about this term. At first, I thought it was a joke—but it’s real. The concept comes from a 1980s comic strip by B. C. Boyer, where a masked figure exposed organizational dysfunction.
Years later, Steve McConnell repurposed the metaphor in his IEEE Software column, using it to describe tech-enabled strategies for anonymous and impartial feedback in software projects. The idea: any team member can raise red flags without fear of backlash—because someone needs to.
As McConnell puts it:
“If developers are turning their code over to testing later than scheduled, a concerned tester can report that… If a project manager is exaggerating the project’s progress in reports to upper management, a concerned developer can report that.”
The Cost of Masked Communication
Despite all our agile advancements, fear still rules in many teams. Status meetings become performances. Feedback gets withheld. And what should be a space for learning turns into a place for posturing.
Kent Beck, in Extreme Programming Explained, says many project failures happen because “someone didn’t talk to someone.” It sounds simple—but it’s profound. Communication doesn’t just happen—it needs to be invited, protected, and rewarded.
This is where McConnell’s metaphor hits home. When feedback is discouraged or punished, people retreat. The developer stays quiet. The tester pretends it’s all fine. The manager hears what they want to hear.
How to Unmask Your Team
If we want real agility, we need teams that trust each other enough to share the truth—especially when it’s hard. This isn’t a culture of blame. It’s a culture of shared ownership.
Here are three things that help:
Normalize discomfort in updates Let someone say, “This is delayed,” without public shaming or micromanagement. The focus should be on solving, not blaming.
Use retrospectives as safe zones, not rituals Retros should be protected spaces for venting frustrations, flagging risks, and proposing solutions. What’s said there stays there—except the insights.
Create visible, shared feedback loops Kanban boards with clear policies, weekly trust check-ins, or even a “stress barometer” can give the team ways to speak up without pressure.
Closing Without Masks
Before we teach technical practices, we must teach trust practices. That starts with leadership creating an environment where truth is welcomed—even if it means admitting a delay or exposing a flaw.
No tool, no methodology, no certificate matters more than the courage to say: “Something’s wrong.” And when that courage is nurtured, good teams become honest teams.
Posted as part of a reflective series on engineering culture. Inspired by real questions and real projects—because engineering is about people too.