Everything is more complicated than it looks
My old boss had a line she’d pull out every time I came to her complaining that something was harder than it should have been. “If it were easy, we’d have already solved it.”
It wasn’t sympathy, and it wasn’t permission to complain longer. It was a redirect. The easy version of my problem was solved years ago by someone else. What’s left on my desk is left because it’s not easy.
My team has been working on a project that’s basically analyzing groups of things to determine their effectiveness. On the face of it, it’s an extremely simple ask. Except those groups overlap with other groups. Oh, and add another dimension, and there are other things impacting how both the first and second set of groups behave. Even when you’ve controlled for that, there are sub-groups within the first set of groups that are behaving differently enough it’s messing up anything that might be clean.
“Basically” was doing a lot of heavy lifting in that sentence.
That’s not a sign we scoped it badly. It’s what the work looks like once you’re past the version of the problem someone described in a single sentence in a meeting. The gap between how complicated a thing sounds when a stakeholder asks for it and how complicated it turns out to be is the painful norm of being an analyst.
Unfortunately, nobody on the other side of that gap cares.
They don’t want a tour of the definition mismatch, the edge cases, the groups that overlap almost entirely, so you can’t find the signal. All of this on the bold assumption the data you pulled in the first place matches what you expected. They want an answer they can act on. They asked “should I do X or Y?” and they want one of those two things back, not a explanation of why the real answer is neither, both, or something you’d have to invent a third option to describe.
Delivering that answer is harder than it sounds, because your instinct is the other way. You did the work, you found the nuance, and some part of you wants credit for it. Complexity makes things INTERESTING, and when we don’t give a binary answer, we can OPTIMIZE.
Even when you explain that, people still don’t care. And even if they did, optimization past a certain point stops paying for itself, because the business can’t execute what you’re recommending.
I’ve handed over recommendations that were both correct and completely unusable. The analysis says this segment responds to one thing and that segment responds to something else, so treat them differently. Sound advice, right up until you find out the system that has to deliver it can only handle one rule. Or the process I recommended that ran to twelve steps and had to be explained to someone, who would explain it to someone else, who would hand it off again to actually execute.
The recommendation that survives the gauntlet of execution is often much blunter than the one your analysis supports. Developing the judgment to get to that blunter version faster, without spending three more weeks refining precision nobody can act on, is worthwhile work. Precision you can’t execute is like a broken pencil - pointless.
Two ways to handle it
Sometimes the right move is to build something simple on a few stated assumptions and move on. You’re not computing the exact number, you’re establishing direction: is this worth pursuing, is it roughly the right size, does it deserve more of anyone’s time? State the assumptions plainly, keep the analysis light, and don’t apologize for it being rough. Rough and fast is the correct tool for a lot of decisions.
Other times, detail is critical. If a decision is hard to walk back, sets a precedent, has regulatory exposure or is something you’ve been burned by before, those details might save your ass. As I’ve written before, trust is built in deposits and lost in withdrawals, and the moment someone catches a detail you skipped, they stop trusting the next number you hand them.
Knowing which one you’re facing before you start is what separates a useful analyst from a busy one.
Simple, but no simpler
I like Einstein’s framing of this problem. Make everything as simple as possible, but no simpler. The choice isn’t depth versus honesty. It’s finding the simplest version of the answer that’s still true and impactful. A number that’s clean but wrong isn’t simple, it’s just wrong.
Two questions can help you decide.
First, is the decision reversible? If being wrong costs an afternoon to fix, build the rough version and move forward. You can always revisit later. If being wrong locks in a commitment nobody can walk back, the extra rigor is worth the time you invest.
Second, when reversibility doesn’t settle it, ask whether the room is deciding if they should do something or how they’re going to do it. If versus how usually ends the argument I’m having with myself. When people are still deciding whether to act at all, an assumption-heavy answer is enough, because the decision might not happen. Once they’ve committed and you’re helping them execute, the details you’d otherwise skip start to matter.
Take a seasonal discount. When we’re deciding IF we should offer it, a quick look at how similar discounts performed, and whether they were incremental (in itself a deceptively hard question), gets us close enough to make the call. When we decide HOW to execute, how deep the discount goes, when it runs, whether there are restrictions, the question gets much harder and needs a deeper answer.
I still catch myself over-explaining things nobody asked about, mostly because I find the caveats more interesting than anyone else does. I suspect people just think I like the sound of my own voice, though.
A little assignment
Take a look at your list of projects and upcoming meetings. Pick one thing you’re currently over-explaining to a stakeholder and run it through the reversibility test. If it’s cheap to undo and you’re still walking people through every caveat, cut it from your next update entirely and see whether anyone notices.
Absorbing the complexity is expensive. The hours in the rabbit hole, the patience to sit with an ugly edge case until it makes sense, the discipline to leave nearly all of it out of the final answer. It costs the person reading your summary nothing, and they’ll never know what you left out.
Some of what I write about here I’ve turned into proper playbooks. They’re more in-depth, more structured, and more actionable. You can find them at the Penguin Analytics store.


Wow John this one hits so hard. It feels like you've described my own experience in painful detail, and it's so helpful to hear how you handle it. I haven't seen anyone address this topic this way before, so I appreciate it.
I've struggled deeply with this portion of the job because it didn't feel like a difference in preferences or approach, it felt like a difference in philosophy or even morality. "The data is the truth," I thought. When the stakeholder said they wanted just the cliff's notes, I thought they were missing all of the critical complexity they needed to make a better decision. Looking back, I understand now that the complexity isn't helpful at their level and in their role.