The Screwdriver Thought

I keep coming back to this idea that we don’t really have a tooling problem. We haven’t had one for a long time.

Tools keep getting better. The pace of change over the last 20–30 years has been wild. Faster machines, better frameworks, smarter IDEs, and now AI assistants. If the only question were “can we build this faster?”, the answer would almost always be yes.

But every time I hear that framing, I think about a regular screwdriver versus a power tool.

A power tool can absolutely get certain jobs done faster—and often better. But you wouldn’t use it for every screw. You still have to understand the job in front of you. You still have to know what you’re trying to do.

The tool isn’t the decision. The need is.

---

What Hasn’t Improved

What doesn’t seem to improve at the same rate is our ability to:

• Identify the real need
• Articulate the problem preventing that need from being met
• Explain both clearly enough that someone else can help

We can have the most powerful tools available, but if we don’t know what we’re solving for, the tools don’t matter. They just help us go faster in a random direction.

I’ve seen this pattern before.

There was a time when writing code was the bottleneck. So we attacked it:

• Code generators
• Frameworks
• Libraries that removed boilerplate
• Abstractions that hid complexity

And it worked. We got faster at producing code.

But explaining what problem the code is meant to solve? That part didn’t get the same investment.

---

Speed Without Direction

This is where things get tricky.

If you don’t clearly understand the need, and you can’t articulate the problem, speed becomes a liability. You can build the wrong thing very efficiently.

That’s why I’m less interested in tools that help me write code faster, and more interested in tools that help me:

• Define the problem sooner
• Explore multiple ways to frame it
• Pressure-test my assumptions
• See options I hadn’t considered

This is one place where AI tools can be genuinely useful.

Not as “code writers,” but as thinking partners.

If someone can explain what they want and what they’re not getting, a conversation with an AI can help:

• Surface hypotheses about what the real problem might be
• Ask better questions
• Offer alternative perspectives
• Suggest different paths forward

The value isn’t in the final answer. It’s in getting to a clearer problem statement faster.

---

It’s Not Just a Stakeholder Problem

This isn’t only about stakeholders or customers. We’ve always known that people have a hard time articulating their needs.

But developers struggle with this too.

I’ve watched many developers try to explain a problem by jumping straight into code. As if the programming language itself will somehow clarify the issue.

But that raises an uncomfortable question:

If you can’t explain the problem in plain, natural language, do you really understand it?

Code is a solution expression. It’s not a substitute for understanding.

When we skip the step of clearly articulating the need and the problem, we’re not being efficient—we’re just hiding uncertainty behind syntax.

---

Slowing Down to Go Faster

So yes, once the problem is clear, by all means:

• Write code fast
• Use powerful tools
• Automate the boring parts

But only after we know what we’re solving.

The real leverage isn’t better tools.

It’s getting better at naming the need, defining the problem, and having the patience to sit with that uncertainty until it becomes clear.

That’s the part worth practicing.

Because once that’s in place, almost any tool will do the job.

---

📘 Related: The NPS Playbook

This way of thinking—slowing down to notice the need, naming the problem, and resisting the urge to jump straight to solutions—is the thread that runs through my NPS Playbook.

The book isn’t a how-to manual. There are no step-by-step instructions or universal formulas. Instead, it’s a series of real stories—moments where I noticed friction, paused long enough to understand what was actually going on, and experimented my way forward, often with AI as a thinking partner rather than a shortcut.

Each chapter follows the same simple arc: need → problem → solution. Not as a method to apply blindly, but as a lens for reflection. A way to stay grounded when tools get more powerful than our clarity.

If this post resonated, the book goes deeper—not by telling you what to do, but by showing how paying attention changes what becomes possible.

👉 The NPS Playbook is available now.