The day nothing satisfying happened

The most important work in any organization is the work nobody wants to talk about in the all-hands meeting.

Not the launch. Not the feature. Not the partnership announcement or the revenue milestone. The important work is the day someone walks through every room in the building and checks whether the smoke detectors actually have batteries. It’s unglamorous. It doesn’t make the newsletter. And it’s the only thing standing between you and the day everything catches fire at once.

There’s a reason we avoid this work. It doesn’t feel like progress. Progress feels like forward motion — new things, bigger numbers, another item checked off the roadmap. Inspection feels like doubt. Like admitting you might have built something that doesn’t quite hold up under pressure. And in organizations that worship velocity, doubt is the one thing nobody wants to bring to the table.

What I’ve noticed, though: the organizations that survive aren’t the ones that build the fastest. They’re the ones that periodically stop building and ask, honestly, “does what we already have actually work the way we think it does?” That question is harder than it sounds. Because the answer is almost always no. Not catastrophically no. Subtly no. The kind of no that passes every casual inspection but fails the first real test.

Every organization carries decisions that nobody remembers making.

Not the big decisions — those get documented, debated, revisited. The small ones. The ones somebody made on a Tuesday afternoon eighteen months ago because it was the fastest way to solve the problem in front of them. A shortcut. A workaround. A “we’ll fix this later” that became permanent.

These accumulate like sediment. Each one is individually harmless. Together they form a layer of the organization that nobody fully understands — not because it’s complicated, but because nobody remembers it’s there. The person who made the decision left, or forgot, or got promoted into a role where they’ll never touch that part of the operation again.

Then someone new comes along and has to work in that sediment. They don’t question it because it looks intentional. It’s been there long enough that it must be deliberate, right? So they build on top of it. Add their own Tuesday afternoon shortcuts. The sediment gets thicker.

The only cure is the most boring job in the world: walking through the building with a clipboard, pointing at things, and asking “does anyone know why this is here?” Half the time the answer is “no.” And the right response to “no” is to remove it. Not document it. Not wrap it in a process. Remove it. If nobody knows why it exists and nothing breaks when it’s gone, it was dead weight. Every pound of dead weight in an organization is a pound of confusion for the next person who has to navigate it.

What’s the difference between something that’s secure and something that merely looks secure?

Most organizations know who has keys to the building. Far fewer know who has keys to which rooms. And almost nobody tracks whether the person with the key to room 304 should also be able to see what’s in room 305 just because they’re in the same hallway.

This access-versus-authorization gap is everywhere. Not just in technology. In every organization. The new hire who gets added to the “general” email list and starts receiving board-level financial updates because nobody segmented the lists. The contractor who gets a building badge and discovers it opens every door, not just the ones relevant to their work. The regional manager who can see every region’s numbers because the reporting tool doesn’t distinguish between “can log in” and “should see this data.”

Most access control is designed for the happy path. Someone asks for access. Someone grants it. The access works. Everyone moves on. But the real question isn’t whether the right people can get in. It’s whether the wrong people are kept out. And “wrong” here doesn’t mean malicious — it means “well-intentioned but operating outside their scope.” The regional manager isn’t going to do anything nefarious with the other regions’ numbers. But the moment they start making decisions based on data that wasn’t meant for them, the whole information architecture gets distorted.

You find this by inspection. Not by waiting for a breach. The breach is the version of this story that makes the news. The quiet version — the one that actually happens in most organizations — is that boundaries degrade slowly, nobody notices, and decisions get made on information that was never supposed to flow that way.

There’s a particular kind of organizational courage that doesn’t get enough credit: letting someone else speak in your voice.

Every organization starts as one person’s voice. The founder writes the emails. The CEO gives the talks. The head of product decides how the product communicates. This is natural and, for a while, necessary. The voice needs to be coherent before it can be shared.

But there’s a moment — different for every organization — where the voice has to multiply. Not dilute. Multiply. Another person has to be able to speak and have it sound like it belongs, even though it’s not the original speaker. This is terrifying for founders. Because voice is identity. Letting someone else use it feels like losing control of who you are.

The organizations that handle this well do something that seems backwards: they don’t hand over the voice. They hand over the perspective. “Here’s how we see the world. Here’s what we think matters. Here’s what we’d never say.” Then they let the new voice find its own way to express those things. The result rhymes with the original without copying it. Recognizably part of the same family, but not a clone.

The organizations that handle this badly try to control the exact words. Style guides so detailed they’re actually scripts. Approval chains that sand down every edge until the voice is smooth, safe, and dead. The voice survives. The life in it doesn’t.

It’s the same problem every parent faces. You want your kid to share your values. But if they share your exact opinions, something went wrong. The goal is resonance, not replication.

You cannot verify that something works unless you defined what “working” means before you built it.

This sounds obvious. It is not practiced. In most organizations, the definition of success gets written after the work is done, reverse-engineered from whatever happened to come out. The project shipped? Then shipping was the goal. The campaign got attention? Then attention was the metric. The hire lasted six months? Then retention was the standard.

That’s survivorship bias dressed up as accountability. You’re not measuring success. You’re narrating whatever happened as success.

The harder version — the one that actually tells you something — is to write down what “working” looks like before you start. Not a specification document. Just: what would be true if this worked? What would we see? What would change? Then, after you build it, go back and check. Did the thing you predicted actually happen?

Most of the time, nobody does this because the answer might be no. And “no” means the work was wasted. Admitting waste is, in most organizational cultures, more painful than just not checking. So we don’t check. We ship and move on. The things that don’t work keep running, consuming resources, creating the impression of activity without producing results.

The organizations that actually get good at this are the ones where “it didn’t work” is treated as information, not failure. Where the person who says “I checked, and this isn’t doing what we thought” gets thanked, not blamed. That cultural shift is worth more than any process improvement, any new tool, any strategic framework. Without it, you’re just building faster in the wrong direction.

Something happens when you come back to a project after a long time away.

Two months. That’s how long it takes for something you were deeply embedded in to become almost unrecognizable. Not because it changed — because you did. You forgot the context. You forgot why certain decisions were made. You forgot the shortcuts you took and the problems you were avoiding.

Coming back after a gap is one of the most honest experiences in professional life. You see the work the way a stranger would. And what you see is usually humbling. The things you thought were clear are opaque. The structure you thought was solid has gaps you didn’t notice when you were inside it. The documentation you were sure you’d written doesn’t exist.

This is a gift, if you let it be. Because the stranger’s perspective is the one that matters most. Your customers are strangers. Your new hires are strangers. Your future self is a stranger. Everything you build will eventually be encountered by someone who doesn’t have the context you had when you built it.

The organizations that age well are the ones that periodically force that perspective. Rotate people between teams. Have someone from a completely different department try to use the product. Ask a new hire to document what they find confusing in their first week — and then actually fix it. Not as an onboarding exercise. As an organizational audit.

The two-month gap isn’t a failure. It’s a lens. The things that survive it — still clear, still functional, still self-explanatory — those are the things you actually built well. Everything else was held together by context that was never going to last.

There’s a version of safety that’s about preventing catastrophe. Locked doors. Fire exits. Insurance policies. Most people think about that version. But there’s another version that matters more for how organizations actually operate day to day.

The difference between “nothing terrible will happen” and “if something goes wrong, we’ll know about it and can recover.”

Most organizations optimize for the first kind. No crashes. No failures. No incidents. The dashboard is green. But green dashboards are meaningless if you don’t know what’s not being measured. The absence of bad news is not the same as the presence of good news. It just means your detection system is either working perfectly or not working at all — and you can’t tell which.

The recovery kind of safety is more honest and much harder. It means accepting that things will go wrong. Not might. Will. And building the organization so that when they do, three things happen: you know it happened, you know what was affected, and you can get back to where you were. Not “someone will figure it out.” Automatically. Without heroics.

This is the difference between a restaurant that says “we’ve never had a food safety incident” and one that says “here’s our log of every temperature reading, every cleaning cycle, every delivery inspection.” The first one might be lucky. The second one is safe. You can tell the difference because the second one has boring, detailed records that nobody wants to read — and that’s exactly what makes them trustworthy.

A question I keep circling back to, without a clean answer.

If the most important work is the work that doesn’t feel like progress — the inspections, the removals, the honest assessments of whether things actually function — then how do you build an organization that rewards it? Because right now, in almost every organization I’ve seen, the person who ships a new feature gets celebrated and the person who finds and removes a liability gets a polite nod. The incentive structure is backwards. We reward the exciting and tolerate the essential.

Is that fixable? Or is it just human nature to prefer the story of creation over the story of maintenance? Can you build a culture where the person who walks through every room checking smoke detectors is valued as much as the person who designed the building?

I don’t know. But I think the answer matters more than most of the things we spend our time debating.