Reducing Uncertainty: Why Stakeholders Asking for Transparency Don't Want More Data

I spent days preparing for one of my first one-on-ones with the CEO.

We were running a hybrid system — part cloud, part on-premise — and any feature that needed data from both sides multiplied in complexity. Something that looked trivial from the outside could take weeks of careful work just to avoid breaking the fragile connections between the two environments. I mapped the architecture in my head, rehearsed my key points, anticipated his follow-up questions. My logic felt airtight: if he understood why this work was hard, he'd see how much value the engineering team delivered. The complexity itself was my case for more headcount.

Within a few minutes, I could see him losing interest. Then his questions changed direction. Why do we have so many engineers already? Why can't any of them solve this? If the work is this complicated, are we even structured correctly?

I had walked in to demonstrate value. I walked out having created doubt. That meeting taught me the lesson that reshaped my career: my job was never to transfer my technical knowledge upward. My job was reducing uncertainty so other people could do theirs.

Internal Marketing Isn't Spin — It's Translation

Afterward I went to talk to our COO, who had become a mentor. Outside his operating role he taught graduate classes at the University of Chicago Booth School of Business, and he understood how executives think in ways I was only starting to grasp.

He gave me a phrase that made me flinch: internal marketing.

Marketing sounded like spin. Like making things look better than they were. I was an engineer — my job was to be accurate, to convey the full picture, to make sure people understood the real complexity we were dealing with.

But he meant something different. Marketing isn't misleading people. It's simplifying complex ideas so they can make decisions. The CEO didn't need to understand our hybrid architecture. He couldn't evaluate whether I was technically strong — that wasn't his expertise, and it wasn't his job. What he actually needed was much narrower:

• What are we going to do?
• When are we going to do it?
• Where should the company hedge against risk?

Simplifying complexity isn't dumbing it down. It's translating it into something people can act on. That reframe is one of the ideas I keep returning to in my book, Don't Think When You Code, because it's the point where a strong engineer either becomes a leader or stalls out.

The Career Shift Nobody Warns You About

Early in an engineering career, the question is straightforward: how fast can you build? You're measured on output. Ship code, close tickets, deliver functionality. Technical skill is visible and directly rewarded, and the engineers who build faster get promoted.

As you advance, the question quietly changes to something else entirely: how effective are you at controlling noise?

Noise comes from two sources. The first is unexpected outcomes — things breaking in production, requirements shifting mid-project, dependencies failing, launches going sideways. The second is poor communication — misaligned expectations, unclear decisions, assumptions that don't surface until they're expensive, meetings where everyone leaves with a different understanding of what was agreed.

The engineers who become technical leaders aren't necessarily the fastest builders. They're the ones who reduce noise for everyone around them. Fewer surprises. Fewer misunderstandings. Fewer moments where someone says, "Wait, I thought we agreed on something different."

A week of certainty is worth more than a month of chaos. Organizations would rather move slower with confidence than faster with risk. This shift — from feature velocity to noise control — is the defining transition of a senior engineering career, and almost no one tells you it's coming.

The Transparency Trap

Here's a pattern I've watched repeat at nearly every company I've worked at.

Things are going well. Then something derails a team — an industry shift, an unexpected technical problem, a dependency that fails. The disruption creates frustration downstream for people who had built their own plans around your dates. Headcount plans. Training plans. Process changes that assumed a capability would exist by a certain week.

The frustration snowballs. The further downstream it rolls, the bigger it gets. And the universal response, every single time, is a request for more transparency.

The natural reply is to give them data. Backlog items. Sprint velocity. Bug counts. Deployment frequency. Burndown charts and cycle time dashboards. Access to the project management tools. Weekly reports with every detail.

It never helps.

The stakeholder opens the board, sees dozens of items in statuses they don't fully understand, numbers without context, and no way to tell what matters from what doesn't. They can't tell whether things are on track or falling apart. They leave more anxious than they arrived — and at the next meeting, they ask for even more transparency.

Research on information overload confirms what I've seen play out over and over: past a certain threshold, more data reduces decision quality instead of improving it. It creates confusion, slows decisions, and lowers confidence. The instinct to share everything is well-intentioned and counterproductive.

What People Actually Mean When They Ask for Visibility

The clearest lesson I ever got on this came on an early morning flight from Chicago to New York.

We had multiple production issues on a fifteen-year-old product, and I was flying out to present a modernization roadmap to one of our largest customers. They had already asked for transparency to the point of sending two of their directors to shadow me in our office for several days. That hadn't satisfied their leadership, so now we were going to them. Our SVP of Sales and I had built a carefully worded deck — slides, timelines, feature descriptions, technical explanations, committing to what we had to without overcommitting.

A senior executive from their company walked into the room and opened before we'd started.

"I'm responsible for an extremely large percentage of this company's revenue," she said. "So if I'm in this room, it means you have created an unexpected problem for us. All I want to know is when we can count on things being fixed so that we can build a process on our end to minimize the damage you have created."

She didn't want the roadmap. She didn't want to understand the features or the architecture decisions or our technical constraints. She wanted to know when her team could rely on us — so she could make her own plans with confidence.

That's what people are really asking for when they ask for transparency. Not more information. Less uncertainty. Dumping data on them achieves the opposite: it adds noise instead of removing it. Transparency isn't about volume. It's about clarity.

How to Practice Reducing Uncertainty

So what do engineers who are genuinely good at this actually do?

Find language that travels. Identify a small set of key terms — project names, phase labels, capability descriptions — that work in a technical deep-dive with engineers and in a status update with executives. They need to be memorable, specific enough to mean something, and usable by anyone in the organization. These become the anchors for every conversation.

Build a high-level plan on top of those terms. It should be understandable by someone with no technical context and answer three questions: What are we doing? In what order? Roughly when? This isn't a project plan. It's a narrative — a story people can hold in their heads and repeat to someone else accurately.

Keep the complexity, but map it. Your team still needs full task breakdowns, technical decisions, and implementation detail. That detail should ladder back to the key terms so anyone can connect the work to the big picture. Executive asks about progress? Answer in key terms. Engineer asks about implementation? Drill down. Same structure, different altitude — and the connection between the levels is what makes it work.

Name unknowns out loud, early, and repeatedly. Don't bury risks in a document or mention them once and assume they stuck. Make them part of the regular conversation. When something goes wrong later — and something always does — "this is the risk we flagged in week two" is a collaborative problem-solving conversation. "This came out of nowhere" is a trust-destroying crisis. The only difference is whether you named the uncertainty before it materialized.

Do this consistently and other leaders can make their own plans. Marketing can commit to a launch date. Sales can set customer expectations. Finance can forecast. If you're reliable about what you'll deliver and when, the people who depend on you get to be reliable to their teams. If you're unpredictable, their unpredictability cascades and noise multiplies across the whole organization.

The Walk Past the Cloud Room

After that conversation with the COO, I changed how I ran my one-on-ones with the CEO.

I stopped explaining complexity. I stopped preparing material designed to make him appreciate why things were hard. Instead I prepared answers to three questions: what we were going to do, when we were going to do it, and where the company should hedge against risk. When I didn't know something, I said so — and said when I would know. When there was risk, I named it instead of hoping it wouldn't come up. When priorities shifted, I explained what that meant for timelines without relitigating the technical details.

The meetings got shorter. His questions got more focused. Instead of probing for problems, he started asking how he could clear obstacles. He still couldn't tell whether I was technically strong. But he could tell I reduced his uncertainty, and that was what he actually needed from me.

I still walked past the cloud room on my way to his office — the same conference room where I'd once rebuilt a search engine over a weekend, where technical excellence had been the entire game. I'm still proud of what I did in that room. But I wasn't that engineer anymore. The skills that got me there weren't the skills that would carry me forward.

The cloud room was where I learned to build. The walk past it was where I learned to lead.

If your stakeholders keep asking for more visibility and it never seems to satisfy them, the problem probably isn't your reporting — it's that you're answering a request for data instead of solving for uncertainty. Don't Think When You Code walks through this shift alongside the rest of the system: deliberate practice, task templates, mental models, and durable decisions that free your conscious mind for the problems that actually deserve it. Pick up a copy, and before your next executive update, try cutting every slide that doesn't answer what, when, or what could go wrong.