skip to content
san.is
Table of Contents

Three months into a CRM migration, we were stuck. The data transformation logic had grown into a 2,000-line Python script that nobody fully understood. Every time we fixed one edge case, two more appeared. Timelines were slipping. The client was getting nervous.

In a call with the technical lead, I asked: “What’s the actual business rule we’re trying to implement here?”

Silence. Then: “I’m not sure anymore.”

We’d been so deep in the weeds—handling null values, deduplicating records, mapping legacy fields—that we’d lost sight of what the transformation was supposed to achieve. When we went back to the business stakeholder, it turned out half the complexity existed to preserve data that nobody used or wanted. The script shrank to 400 lines. We delivered two weeks early.

This wasn’t a fluke. I’ve seen it happen repeatedly across enterprise implementations: the most valuable interventions aren’t technical insights, they’re simple questions asked at the right moment.

Why simple questions are so hard to ask

If these questions are so powerful, why don’t we ask them more often?

Because they’re socially expensive.

Asking “what are we actually trying to achieve?” three months into a project can feel like an accusation. It implies that perhaps we’ve been wasting time. It risks making the person who’s been leading the work feel defensive. In a room full of senior people, asking “can someone explain why we need this?” can feel like admitting you’re the only one who doesn’t understand—even when half the room is quietly wondering the same thing.

There’s also the sunk cost problem. Once a team has invested weeks building something, questioning its fundamental purpose feels almost cruel. So we optimise what exists rather than questioning whether it should exist at all.

I’ve learned to frame these questions carefully. Not “why are we doing this?” (which sounds like a challenge) but “help me understand the original requirement” (which sounds like you’re trying to help). The question is the same. The reception is completely different.

Five questions worth asking

1. What changed?

This is the single most useful question in troubleshooting. Not “what might be wrong?” but “what’s different from when it worked?”

I was once called into a failing HubSpot workflow that had been running fine for months. The team had spent two days checking API connections, reviewing the workflow logic, examining contact properties. Nobody had asked what changed.

Turns out, someone had renamed a custom property from “Lead_Score” to “lead_score” to match a style guide. The workflow was still looking for the old name. Five-minute fix to a two-day problem.

The question works because it narrows the search space dramatically. Instead of investigating everything that could be wrong, you’re only looking at what’s different. In complex systems, this constraint is invaluable.

2. What exactly are we trying to achieve?

This question has saved me more time than any technical skill I’ve learned.

On one project, a client wanted us to build a custom integration between their ERP and HubSpot to sync inventory levels in real-time. They’d already specced it out: webhooks, middleware, error handling, the lot. It would have taken six weeks.

I asked what they were trying to achieve. They wanted sales reps to know whether a product was in stock before promising delivery dates.

We built a nightly batch sync instead. Four days of work. The sales team was perfectly happy—they didn’t need real-time data, they just needed data that was less than 24 hours old.

The original spec was a solution masquerading as a requirement. The question revealed the actual need.

3. How would we know if this worked?

This is the question that prevents you from building things that can’t be validated.

I ask this before any significant piece of work begins. If we implement this lead scoring model, how will we know it’s working? If we migrate this data, what does success look like?

The answers are often revealing. Sometimes there’s no clear success criteria at all—which tells you the requirement isn’t well understood. Sometimes the success criteria expose that the proposed solution won’t actually achieve it. Either way, you learn something crucial before investing the effort.

On a recent project, asking this question revealed that the client’s definition of “successful migration” was completely different from what we’d assumed. They cared about preserving historical reporting, not about having every field perfectly mapped. That insight reshaped the entire approach.

4. Can you explain why we need this?

A senior engineer once asked me this about a database index I’d requested. I’d copied the pattern from another project without really thinking about it. When I tried to explain the justification, I realised there wasn’t one—we were optimising a query that ran once a month in a background job.

This question is particularly valuable for inherited complexity. When you join a project mid-flight, there’s always some component that everyone treats as sacred but nobody can explain. “We’ve always done it that way” is not a reason. Sometimes the original context has changed. Sometimes it was never a good idea. Sometimes there’s a genuine reason that’s worth understanding.

The key is asking with genuine curiosity rather than implied criticism. You’re not saying “this is stupid,” you’re saying “I want to understand.”

5. What would happen if we removed it?

This is the most uncomfortable question, and often the most valuable.

Complex systems accumulate cruft. Processes that made sense once but don’t anymore. Validation logic for edge cases that never occur. Integrations that nobody uses. The system keeps running, so nobody questions whether all the pieces are necessary.

On one implementation, we inherited a workflow that sent internal notifications to six different people whenever a deal moved to a certain stage. I asked what would happen if we turned it off. After some discussion, we discovered that four of those people had left the company, one had asked to be removed from the notifications months ago, and the sixth didn’t read them anyway.

Removal often reveals more than addition. If you take something away and nothing breaks, you’ve learned something important about what actually matters.

When this doesn’t work

I should be honest: simple questions aren’t always the answer.

Sometimes you genuinely do need to dive into the debug logs. If a production system is down and customers are affected, you don’t have time for philosophical inquiry—you need to find the problem and fix it. The questions come later, in the post-mortem.

And some complexity is genuine. Not every convoluted system is the result of unclear thinking. Sometimes the domain is inherently complicated, and the solution reflects that reality. The questions help you distinguish between essential complexity and accidental complexity, but they don’t make essential complexity disappear.

There’s also a social timing element. Asking “what are we trying to achieve?” in a crisis meeting comes across as obstructive. The same question in a planning session is constructive. Reading the room matters.

Making space for the questions

The hardest part isn’t knowing which questions to ask—it’s creating the conditions where they can be asked without social penalty.

A few things I’ve found helpful:

Ask early. These questions get harder to ask as projects progress. On day one, “what are we trying to achieve?” is due diligence. On day ninety, it’s an indictment.

Assume good intent. Frame questions as seeking to understand, not to challenge. “Help me understand why…” lands better than “Why do we…?”

Ask yourself first. Before questioning someone else’s work, apply the same scrutiny to your own. It builds credibility and catches your own blind spots.

Make it normal. In teams where these questions are routine, they lose their edge. When everyone asks “how would we know if this worked?” it stops feeling like a test.

Complex systems will always demand technical skill. You need to understand the tools, the patterns, the failure modes. But technical skill alone isn’t enough. You also need the clarity that comes from asking basic questions—and the social awareness to ask them in ways that open up conversation rather than shutting it down.

The most expensive problems I’ve seen weren’t caused by bugs or bad architecture. They were caused by teams building the wrong thing, very competently, for months at a time. A simple question, asked at the right moment, could have saved all of it.