The Starting Situation

Recently, a new project manager presented me with his control board presentation. The initiative: AI implementation in a key business area. The slides looked professional: clear objectives, appealing roadmaps with five milestones, colorful circles visualizing the iterative approach. Everything seemed well thought out.

But upon closer inspection, a fundamental problem became visible: there was no actual content.

In the budget planning, there was a substantial line item for “Change Management.” The project manager’s justification: “AI is a massive transformation project, after all, so support is essential.” You can nod along. It sounds logical, it sounds professional.

But what does that actually mean concretely?

When Project Language Becomes Smoke and Mirrors

This is the “meta trap”: the art of speaking about a topic so abstractly that no one can disagree, but also no one knows what actually needs to be done next Monday.

Then it’s not a plan, just vocabulary.

Decision-makers don’t just need to logically understand a project, they need to be able to mentally visualize it. The test questions are simple:

• Who goes where?
• Who will they talk to?
• What happens in weeks 1, 2, 3?
• What artifacts are created: decision templates, trainings, process changes, guidelines, templates?
• What is different at the end of a phase than before, and how do we notice it?

What does “Change Management” mean concretely in this AI project?

• Does a consultant actually go into department X, sit next to a senior employee and observe their work process for two hours, then work together to figure out how an AI tool can accelerate this specific workflow?
• Or does “Change Management” merely mean that we send a company-wide email with a link to a generic video course and hope that the “culture” heals itself?

As long as these questions aren’t answered, a project remains “theater.” Not because it’s ill-intentioned, but because it’s not tangible.

And what you can’t visualize, you won’t approve either.

Why Smoke and Mirrors in Control Boards Are So Dangerous

Control boards and executive meetings operate on a simple principle: time is scarce, trust is fragile, and any lack of clarity is interpreted as risk.

When a roadmap only shows five milestones but doesn’t say what actually happens in these phases content-wise, the person across the table doesn’t get a feeling of structure, but of fog.

The problem is: when we stay on the meta level, we don’t make real decisions. We merely manage terminology. A control board that approves a budget for “strategic alignment” without knowing which levers will actually be pulled isn’t investing in the future; it’s buying itself the good feeling of having done something.

And fog almost always leads to the same reactions:

• “This sounds like buzzwords.”
• “How much of this is actually thought through?”
• “What exactly do we need budget for?”
• “What exactly are we buying here: output or hope?”
• “Can’t we just leave this to the managers (without project overhead)?”

This is the point where projects often fail. Not due to lack of motivation, but due to lack of concreteness.

The Core: Don’t Just Show Methodology, Reveal Strategy

In my experience, the most common blind spot is: you show the approach, but you conceal the content strategy.

Especially with transformation or enablement topics (AI is just one example), there are always multiple possible target scenarios that mean completely different measures:

• Is it about skills (e.g., better prompting, guidelines, catalogs, coaching)?
• Is it about tooling and integration (e.g., standard tools, IDE integration, platform, permissions, governance)?
• Is it about process redesign (e.g., how work steps are redistributed)?
• Is it about automation (e.g., agentic workflows, partially autonomous end-to-end support)?
• Is it about operating model (e.g., new roles, new responsibilities, new KPIs)?

If this isn’t made explicit, the committee ultimately doesn’t discuss the project but their own assumptions. Everyone hears the same word and imagines something different. This is the perfect recipe for delay.

It’s about identifying which variants exist in the approach, weighing them, and deciding together, not simply assuming that the intuitively chosen variant is the best one.

“Agile” Is Not a Free Pass for Not Thinking

A common argument to justify the meta trap is agility. “We work agile! In a complex VUCA world, we can’t say today what will happen in detail in milestone 3. We navigate by sight and learn iteratively.”

Honestly? That’s an excuse 80% of the time.

True agility requires more preparation and deeper thinking, not less. Agility means: clear goal, flexible path. Not: no goal, but lots of movement.

Those who can’t describe what concrete content outcome a phase should have simply haven’t thought through the topic. The escape to the meta level is often an escape from the cognitive effort that details require. It’s mental laziness disguised as modern methodology.

The Balancing Act: Why We Both Fear and Love the Meta Level

I must self-critically admit: the meta level is seductive because it’s safe. It’s a psychological defense mechanism. If I get too concrete, I make myself vulnerable.

As soon as you say in the control board: “We’re conducting a workshop with Mr. Müller’s team on October 12th to define the data model for the agent structure,” you open the door to bikeshedding (getting bogged down in details that are actually secondary). Then decision-makers suddenly discuss whether Mr. Müller is the right contact, whether October 12th isn’t too close to the end of fall break, or whether “data model” shouldn’t rather be called “information architecture.”

The meta level protects us from these time-consuming detail discussions about trivialities. But this protection comes at a high price. It leads to the executive level’s trust slowly eroding. They instinctively sense that there’s no foundation beneath the colorful circles.

So there’s a justified counter-movement. That’s why the goal isn’t “maximally concrete,” but clarity on two levels:

1. Meta level, but precise: target vision, principles, decision logic, priorities.
2. Concreteness, but focused: the few actions, results, and deliverables that show it’s a real plan.

Still, I would clearly set the weighting: in most realities, the dominant problem isn’t “too concrete” but “too abstract.” The pendulum swings way too far toward abstraction.

Side Effect: The “AI Slop” Problem

This meta problem doesn’t just show up in control boards. It now permeates all knowledge work.

In the market, I observe a trend toward superficial AI use: many use AI extremely simply. They throw in a simple prompt, receive a smooth but generic result, and copy it uncritically as their own work product.

The result appears professional at first glance but is weak in substance.

This is the meta trap at the task level: AI delivers the perfect surface (nice sentences, correct grammar), but without deep personal input and probing follow-up questions, the result remains worthless noise.

The solution is the same as in the control board: consistently ask downward questions, whether to the AI or to yourself.

• “What does that mean concretely?”
• “What does that look like in practice?”
• “What results emerge and when?”
• “Who does what by next Friday?”

AI can help you be faster. You still have to think.

The Antidote: Concreteness as a Thinking Tool

The solution is simply formulated but hard to implement: Describe what actually happens. So concretely that someone can visually imagine what’s going on.

• Instead of “Stakeholder Management”:

“Over the next three weeks, we’ll conduct six interviews with the heads of affected areas, 45 minutes each, to capture the top 5 barriers. The result is a prioritized barrier list and a decision template for what we solve centrally and what remains local.”

• Instead of “Piloting”:

“We select two teams with clearly defined use cases, set baseline metrics, work in a fixed rhythm for four weeks, and deliver a pilot playbook at the end including checklist, setup, lessons learned, and rollout recommendations.”

• Instead of “Change Management”:

“We do three formats: 60-minute intro session, 90-minute hands-on workshop, weekly office hours. In parallel, we define champions per area and have a communication package with concrete do’s and don’ts. We measure success through usage, time savings, and quality indicators.”

When you notice you can’t describe something concretely, that’s a signal: you need to think further.

Practical Checklist for Your Next Control Board Story

• Can I name a concrete result for each phase?

Not just “milestone achieved,” but “playbook completed,” “pilot finished,” “decision X made,” “process Y changed.”

• Are roles described as actions?

“Does change” isn’t enough. “Conducts 8 workshops, establishes champion network, implements communication plan” is solid.

• Is the strategy unambiguous?

What is the target vision, and what explicitly is not the target vision? Which options were consciously excluded? Does the strategy perhaps need to be discussed first, before talking about the project?

• Where are the uncertainties named?

Not hidden, but as hypotheses with test plans. Say: “We don’t yet know whether to focus on agents or prompting, so in phase 2 we’re investigating exactly these three criteria.”

• Can an outsider visualize this as a sequence?

Don’t just show the process roadmap, but sketch the target state. What does the workplace look like in 12 months? What exactly will someone no longer do that they still do today? If that remains unclear: keep thinking.

Conclusion: Concreteness Is Respect for Decision-Making Time

Abstractions have their place. But too often they hide a lack of deep understanding of a topic. They appear like professional project work but are ultimately façade.

Meta level is important. But meta level without concreteness is like architecture without structural engineering: looks good, doesn’t hold up.

Decision-makers see through this. And they’re right to critically question such proposals. That’s not unfair micromanagement or a signal of lacking trust culture. That’s normal entrepreneurship.

The best test for any presentation, any concept, any plan: can someone without prior knowledge visualize what will happen? If not, back to the drawing board.

This article is also a reminder to myself. I slip into this too. Words come faster than thinking. But projects aren’t decided by words, but by credible pictures of what will actually happen tomorrow.

Think it through. Until it becomes tangible. Until it maybe even hurts. Only then do you have a strategy, not a play.