Understand Before You Build.

When I started working, I was obsessed with answers. The right software, the right workflow, the right way to do a thing. It took me a while to notice that answers have an expiry date and questions don’t. “What’s the best CRM?” is an answer waiting to become obsolete. “What problem am I actually trying to solve?” still works five years from now.

So I started collecting questions instead of answers. What assumption am I making? What changed? What information is missing? What happens if nobody touches this for a year? Is this solving the problem or just treating the symptom? Those questions have saved me more time than any tutorial ever did.

This is also why experienced people often look slower than beginners. Not because they are — because they’re looking at a different problem. A beginner starts building immediately. An expert spends more time asking questions, which looks inefficient right up until you realise they’re preventing work instead of producing it. Someone asks for a solution and expects action; instead they get questions. The questions are the work. Anyone can build quickly. Building the right thing is harder, and experience teaches you that deleting unnecessary work is often more valuable than completing it. Speed is impressive. Precision ages better.

Automation makes this trap easy to fall into, because it’s so satisfying to build. Whenever a business says “we should automate this,” my next question is usually “why do you do it this way in the first place?” Sometimes nobody knows. The process has simply existed for years; people inherited it and nobody questioned it. That’s dangerous, because automation faithfully preserves assumptions — good ones and bad ones. I’ve watched businesses automate duplicate work, unnecessary approvals, confusing communication. None of those problems disappeared. They just happened faster. You end up with a very efficient machine nobody actually needed.

So I’ve become suspicious of any solution that appears too quickly, because quick solutions tend to answer the first problem that showed up instead of the real one. A client asks for automation; maybe they need a better process. Someone wants another report; maybe they don’t trust the data they already have. A team asks for more meetings; maybe the issue isn’t communication, it’s ownership. I’ve learned to ask one more question: “What happens if we don’t do this?” It’s surprising how often that changes the conversation — and how often the best outcome is discovering the original problem never needed solving. Eliminating unnecessary work is still progress.

There’s one last phrase I used to find frustrating and now rely on: “it depends.” I wanted clear rules and checklists. But experienced people don’t say “it depends” to dodge the question — they say it because they’re seeing variables. Different customers, constraints, priorities, risks. Every “it depends” has a pattern hiding underneath it. The goal was never to eliminate judgement; it’s to understand what changes the decision. That’s all a framework really is — not a replacement for thinking, but a way to organise it. So when someone tells me “it depends,” my next question isn’t “on what.” It’s “what are the variables?” That’s usually where the real lesson starts.