24 Jul Method or Tool? The Distinction Most People Miss in Organizations

Most of us know the feeling. You sit through a workshop on agility, or pick up a new method that supposedly worked wonders somewhere else, and you walk out fired up. Then reality hits. Whatever looked so simple in the slides just doesn’t hold up with your own team. And you start wondering if you did something wrong, or if something’s wrong with your team.

I see it in almost every organization I work with: shelves full of methods, or “playbooks,” as some call them. Scrum, OKRs, whatever format came out of last quarter’s offsite. And yet the same problems keep resurfacing, just under new names. The reason is rarely the wrong method. It’s a mix-up that almost nobody names directly: the difference between a method and a tool. Method or tool, that’s the real question. How you answer it matters more than which method you pick.

Contents

What a Method Really Is: The Recipe That Promises Certainty

What a Tool Really Is: It Delivers Execution, Not the Decision

Method or Tool: A Question of Red and Blue Problems

Why a Tool Turns Into a Method So Easily

Method or Tool in Practice: Two Examples Worth Tracing

Conclusion: Why Method or Tool Is a Central Distinction in Everyday Organizational Life

What a Method Really Is: The Recipe That Promises Certainty

The basic idea

A method is, at its core, a recipe. It takes knowledge that has proven itself over time and packages it into a fixed sequence of steps:

1️⃣ Do this
2️⃣ Then this
3️⃣ Then that

That’s the appeal. A method takes the decision off your hands. You no longer have to judge what the situation calls for. You just follow instructions someone else already worked out for you.

Where it works well

This works brilliantly as long as a situation repeats reliably. Think of a manufacturing process with known failure points, bookkeeping governed by clear legal rules, or an onboarding process with a defined sequence. In cases like these, a good method replaces years of experience with instructions anyone can follow, no judgment required.

Where it breaks down

The moment a situation is new and catches you off guard, that same strength turns into a weakness. A method can only offer the answers it already contains. Faced with a problem it’s never seen before, it doesn’t just lack an answer, it offers the illusion of one. And in practice, that’s often worse than having no method at all.

Why this keeps happening more often

These situations aren’t getting rarer. They’re getting more common. Dr. Gerhard Wohland, a physicist and management consultant, has been tracking this for decades. Companies used to grow mainly through globalization: new markets, new customers, without much needing to change about the underlying business. Today, global markets are largely saturated across most industries. Growth comes less from new markets now and more from companies out-competing each other on better ideas for the same customers. That produces a dynamic where competitive advantages wear out faster, and problems repeat less often in exactly the form you’ve seen before, which is precisely where pure recipes are bound to fail.

Not a knock against methods

None of this is a knock against methods. Good consulting, coaching, and organizational development work method-agnostic. They reach for a method when a situation is genuinely known and repeatable, and switch to a tool the moment that’s no longer true. The real problem isn’t the method itself. It’s the assumption that one method can cover every situation equally well.

What a Tool Really Is: It Delivers Execution, Not the Decision

The basic idea

A tool works differently. It stays silent. It doesn’t tell you what it’s for, it waits for you to bring an idea, or a problem that needs solving. That’s why a tool carries no authority of its own. The authority stays with the person using it. And that’s the fundamental difference from a method.

The hammer objection

Here’s an objection worth taking seriously: a hammer is for hammering, isn’t it? Doesn’t a tool have a built-in purpose after all? Yes. But only on one level.

A hammer tells you:

✅ How to swing it, by the head, not the handle

What it stays silent on:

❌ Whether you should be hammering at all
❌ Where the nail should go
❌ Whether a nail is the right fastener for the job
❌ What you’re actually building

Where the decision really sits

Those questions stay with the person deciding whether to pick up the hammer in the first place. A tool handles the operational how. But whether an action even makes sense in this situation, that decision stays with the person holding it, someone with enough experience and judgment to weigh it.

Skill, not knowledge

Wohland calls this ability skill, or expertise, as distinct from knowledge, the kind you can write down in a manual or a checklist. Skill can’t be written down the same way. It only shows up in the doing. A skilled practitioner is not defined by a certificate or formal training, but by the ability to develop a workable response in a situation they have never encountered before. That’s what sets them apart from someone who has simply memorized a method.

A Closer Look at the Three Levels

This can be pinned down more precisely, as the hammer already showed. The operational how is fixed for a tool, exactly as it is for a method, so that’s not actually where the difference lies. The real difference starts at the two levels after that: the situational whether-and-when stays open and sits with the user, and the strategic why stays open too, sitting with the skilled practitioner. A method, by contrast, claims to know both of those levels as well. It doesn’t just say how something gets done, it also says when to do it and why it’s the right call.

There’s usually a fourth open question too, and it’s easy to overlook: the what, meaning the actual content of the solution. Take a carpenter using that same hammer to build a shelf. They’re using it exactly as intended, and yet they still make a fresh call on every single nail: where it goes, and why. That same hammer can just as easily prop open a door, serve as a paperweight, or, in a pinch, work as a lever. Which of those makes sense is entirely up to the idea of whoever is holding it, not the tool itself. The tool doesn’t prescribe that content. Whether the idea existed beforehand or takes shape only in the doing makes no difference. What matters is that this decision never sits inside the tool, it always sits with the person using it. That’s exactly where decision-making power shifts from the person to the rulebook, the moment a method claims that territory too.

The advantage when things get surprising

That’s also where the advantage shows up when a situation catches you off guard. A tool doesn’t break when reality departs from expectation, because it never claimed to know the answer. It simply offers the means for a skilled practitioner to work one out.

At a glance

The Scrum example

Scrum illustrates this well. Scrum as a method says: sprints run two weeks, the daily stand-up runs fifteen minutes, every sprint ends with a retrospective. Scrum as a tool says something different. A rhythm of short iterations and regular reflection can help in certain contexts, and the team decides for itself how often, how long, whether at all, and above all, what actually comes out of it.

Together, these tables make one thing clear: the difference isn’t about how good a concept is. It’s about who ends up carrying responsibility for the decision, whether that’s a CIP board or a Scrum rhythm. Almost any of these concepts can be either, tool or method, depending on how an organization actually puts it to use.

Method or Tool: A Question of Red and Blue Problems

This distinction becomes even more concrete when you look at it through the lens of red and blue problems, because both describe, at their core, the same logic from two different angles.

Blue problems are complicated but known. Knowledge already exists to solve them, you just have to apply it.

Red problems are complex and new. The answer doesn’t exist yet. It has to emerge, through ideas, through skill, and through collaboration.

What follows from that

A method is built for blue problems, because it runs on knowledge that already exists. A tool, on the other hand, is made for red problems, because it doesn’t bring a ready-made answer, only the means for a skilled practitioner to develop one.

Where this goes wrong in practice

Most organizations don’t fail because they picked the wrong method. They fail because they try to solve a red problem with a blue recipe, or, the other way round, leave a blue problem to the open-endedness of a tool, when a clear method would have gotten there faster. And because it’s usually leaders who decide which method gets rolled out to a team, often freshly inspired by the last conference talk or the newest management bestseller, it’s worth their while to take a closer look at this distinction before introducing the next one. Whoever asks first whether a problem is actually new ends up looking for the right answer, not just the nearest available instructions.

Why a Tool Turns Into a Method So Easily

How it happens

The mix-up tends to happen the same way every time. Someone notices a tool working well in one organization, writes up the steps it was used in, and packages them as instructions. What was a tool becomes a method: fixed order, fixed roles, fixed time slots.

Why that fails

The real problem isn’t the write-up itself, it’s the claim that comes with it. The original situation was specific. The tool worked there because someone adapted it precisely to that context. The new method, by contrast, claims to work everywhere, regardless of context. And that’s exactly what it can’t deliver.

Not an isolated case

The same pattern shows up across plenty of leadership concepts that promise more than they deliver, whenever a principle from one successful company gets declared a universal blueprint for everyone, losing exactly the flexibility that made it valuable in the first place.

Method or Tool in Practice: Two Examples Worth Tracing

The CIP board

Roll out a Continuous Improvement Process board as a rigid method, complete with a fixed template and fixed steps, and it gets repurposed fast. Employees who resist the method start using the board as a kind of complaint wall instead, pushing through purchases that would otherwise have been blocked, because the real situation was more complex than the recipe assumed.

Culture change

Nowhere is this clearer than here. Culture can’t be changed with a method, no two culture problems are ever quite alike. Anyone who promises to change culture in three steps is treating a red problem as if it were blue. Culture is made up of patterns that settle in over countless decisions, but were never explicitly decided in the first place, as Niklas Luhmann described it. That’s exactly why it can’t be ordered into place directly. Culture doesn’t need instructions, it needs skilled practitioners who work on the right structures. That’s the only way culture changes indirectly, the same logic behind leadership development built on structure, not behavior training.

Conclusion: Why Method or Tool Is a Central Distinction in Everyday Organizational Life

Before rolling out a new method, a new template, or a new framework tomorrow, ask this one question first: is this a known, repeatable problem, or a new one that doesn’t have an answer yet? In the first case, a method is perfectly fine, with fixed instructions and a clear structure. It’s still worth adapting it to your own context rather than adopting it wholesale, though, because even a known, repeatable situation is rarely identical to the one the method originally came from. In the second case, you need a tool and a skilled practitioner, someone who leaves the decision where it belongs: with the people who can actually read the situation.

The real job for leadership is keeping that distinction alive on the team, instead of quietly handing it over to the next set of instructions.

Get in Touch

Most organizations only spot this pattern once the third or fourth method fizzles out the same way. If you want to find out whether your team is actually working on a red problem or a blue one, and which tool or method genuinely fits, it’s worth a conversation.

In an initial conversation, I look together with you at where the real leverage points are in your organization. No charge, no pitch, no obligation.