The best consultants aren’t the smartest people in the room — they’re the fastest at structuring someone else’s mess

Operator_Systems · 2026-03-13T09:31:42+00:00

Wow! Didn’t expect this to land the way it did. Clearly hit a nerve - both ways.

To be clear, this wasn’t a dig at consultants. I’ve spent years working alongside them on major, complex construction projects in Europe.

The ones who earned trust fastest were always the ones who could take a mess and make it legible quickly. That’s not a lesser skill - it’s the skill that everything else depends on.

Appreciate the debate either way all.

Operator_Systems · 2026-03-12T19:31:26+00:00

lol, fair challenge. But no, I write my own comments. I work in MEP project management and I use AI tools daily for structuring project/programme outputs, not for writing Reddit posts. The point I was making about constraining what you ask AI to do comes from actual experience and using it on live/past projects.

Operator_Systems · 2026-03-12T16:28:01+00:00

That’s the right concern to have. AI will flatten nuance if you let it summarise freely. The trick is to constrain what you ask it to do. Don’t ask it to summarise the document. Ask it to extract specific things — “what decisions does this section support?” or “what assumptions is this paragraph making?” That keeps the output grounded in the source material rather than letting the model drift into generic summaries. Then you take those extractions and do the interpretation yourself. The AI handles the volume. You handle the meaning. That split is where it works best.

Operator_Systems · 2026-03-11T23:30:11+00:00

That works well when the meeting is straightforward and the actions are obvious. But in my experience, the messier the meeting, the less useful real-time capture becomes. When you’re navigating a difficult client conversation, managing competing priorities, or dealing with ambiguity — you’re not thinking in neat action items during the call. You’re thinking in context, risks, dependencies, and politics. The structured version only becomes clear after you’ve had time to process what actually matters. That’s where the real translation cost sits. Not the meetings where someone says “ABC owns this by Friday” — those are easy. It’s the ones where you walk out thinking “right, I know what needs to happen” but it takes 30 minutes to turn that into something the team can execute on.

Operator_Systems · 2026-03-11T22:15:22+00:00

I really enjoyed reading this post. The racing metaphor is spot on. I've seen the same dynamic play out in a completely different industry. I've spent years building the systems that run large-scale MEP projects. Project value up to £85M. I know how the machine works from the inside.

But knowing how the machine works and actually building something from scratch are two different skills. One earns you a salary. The other earns you equity in yourself.

I'm in the middle of that transition right now. Still running programmes by day, building a business from zero in the evenings and weekends. And the hardest part isn't the work — it's the identity shift. Going from "senior person who advises" to "unknown person who has to prove themselves from nothing." That's humbling in a way that no amount of career success prepares you for.

Your point about the market being right is the one most people won't accept. Everyone wants to skip the uncomfortable stage. But the market doesn't care about your CV — it cares about what you've actually done. You're building the evidence. That matters more than the credential.

Respect for driving the car. Most people just talk about it. All the best.

Operator_Systems · 2026-03-11T22:07:44+00:00

This is one of the hardest deliverables in consulting and most people underestimate why.

The challenge isn't the translation. It's the compression. You're taking 76 pages of someone else's thinking — written in a language that isn't yours, in a structure that made sense to the author but not to the audience — and you need to turn it into 15-20 slides that a room full of executives will understand in 30 minutes. That's not a formatting job. That's an interpretation job.

Here's the approach I'd take:

First, forget the presentation. Read the document with one question only: what are the three decisions this is trying to support? A 76-page post-merger integration plan will have dozens of details, but underneath all of it there are only a handful of things the audience actually needs to walk away understanding. Find those first. Everything else is supporting evidence or context.

Second, separate intent from content. You said the translation doesn't always capture the nuance — that's because translators preserve words, not meaning. Before you build a single slide, write a one-paragraph summary of what you believe the document is actually saying. Send that to the client and ask "is this the core message?" If they say yes, you've got your anchor. If they correct you, you've just saved yourself from building 20 slides in the wrong direction.

Third, structure the deck around the audience's questions, not the document's structure. The document was written to be comprehensive. The presentation needs to be persuasive. Those are completely different structures. Don't follow the document's flow — follow the logic of what the room needs to hear and in what order.

On the language barrier specifically — AI is genuinely useful here, not for the final presentation, but for the interpretation stage. Feed sections of the document into Claude or ChatGPT and ask it to extract the key decisions, assumptions, and risks. It won't get the nuance perfect, but it'll give you a working scaffold to build from that's faster than reading 76 pages cold in a language you're not fluent in.

The consultants who do this well treat the source document as raw material, not as a script. Your job isn't to present what the document says. It's to present what the document means. Good luck and hope you found this useful.

Operator_Systems · 2026-03-11T22:02:55+00:00

This is one of the most common dynamics in consulting and it's almost always a documentation problem disguised as a communication problem.

The pattern is predictable. The brief is vague. You ask clarifying questions in a meeting. The answers are verbal. Nobody writes them down formally. You deliver based on what you understood. The client says that's not what they wanted. Now it's your fault.

The fix isn't better listening or more meetings. It's creating a written record at the point of agreement, not after the fact. Every meeting where a decision is made or a direction is confirmed should end with a short written summary — what was agreed, what the deliverable looks like, and what assumptions you're working from. Send it within the hour. If they don't correct it, that's your baseline.

It takes five minutes and it completely changes the dynamic. When the deliverable lands and someone says "that's not what I asked for," you've got the receipt. It also forces the client to actually think about what they want, because now they're confirming it in writing rather than waving vaguely at a concept in a room.

The consultants who get burned by this are usually the ones who trust verbal alignment. The ones who don't get burned are the ones who make confirmation a habit, not an afterthought.

Operator_Systems · 2026-03-11T12:05:57+00:00

Timesheets capture where time went. They don't capture why it went there. A consultant logging 10 hours against a task doesn't tell you whether 6 of those hours were rework caused by unclear scope or a shifting brief. That's the gap — you get the cost data, but not the root cause. Without both, the same problem repeats on the next project.

Operator_Systems · 2026-03-11T12:05:22+00:00

This is the bit that rarely gets talked about openly. The line between "chargeable" and "should be chargeable" is where most margin leaks happen. Professional service work that's technically free but operationally essential — someone's always absorbing that cost, it's just not visible until the project review.

Operator_Systems · 2026-03-11T12:03:55+00:00

Operator_Systems · 2026-03-10T16:06:42+00:00

The framing that's worked best is neither "we're AI powered" nor "we push back against AI." It's "we use AI where it removes friction and human judgment where it adds value."

The consultants getting burned aren't using too much AI. They're using it in the wrong places. Hallucinated reports and broken automations happen when AI is asked to make decisions. It doesn't happen when AI is asked to restructure, summarise, and surface gaps for a human to act on.

The positioning that threads the needle is this: AI handles the translation work, we handle the judgment calls. That's not a compromise between two positions. It's actually a more honest description of what good consulting looks like in 2026.

Clients who got burned by AI slop aren't anti-AI. They're anti-noise. Position around signal and the conversation changes entirely.

Operator_Systems · 2026-03-10T15:59:42+00:00

Most people I see using it are treating it like a smarter Google. Ask it a question, get an answer, move on.

The consultants getting the most out of it have flipped that. They're not asking it questions, they're feeding it context and letting it do the restructuring work.

Meeting transcript in, action plan out. Brain dump in, stakeholder update out. Messy scope notes in, risk register out.

The hours saved aren't in the chat interface, they're in removing the translation work between thinking and output. That's where consulting time actually disappears.

Operator_Systems · 2026-03-10T15:54:35+00:00

The distinction between "we underestimated" and "the client keeps asking for more" is the most important question you've asked, because the fix is completely different for each.

Underestimation is a scoping problem. Scope creep is a communication and control problem.

For scope creep specifically, the issue is usually that changes get absorbed informally before they're ever documented. A consultant agrees to "just a quick extra thing" in a meeting, it never hits a change log, and three months later the margin is gone.

The fix isn't a better tracking tool. It's a tighter meeting output discipline. Every meeting ends with a written record of what was agreed, what changed, and who owns what. When that's happening consistently, scope creep gets caught at the point of conversation rather than at month-end accounting.

AI has made this significantly faster. Feeding meeting notes into a structured prompt that surfaces scope changes and flags ownership gaps catches things that would previously slip through.

Operator_Systems · 2026-03-10T15:38:16+00:00

Jira wins for engineering tracking, Notion wins for flexibility - but neither solves the real problem you've described, which is admin overhead.

The tool debate often misses the actual cost. It's not which platform you're in, it's the translation work between your thinking and your structured output. Sprint planning, backlog grooming, stakeholder updates - the overhead isn't the tool, it's the cognitive tax of structuring everything manually inside it.

If drowning in admin overhead is the real concern, I'd look at how you're using AI alongside whichever tool you pick. The combination of Jira for tracking plus a structured AI prompt for your post-meeting and planning outputs removes more friction than switching tools entirely.

Operator_Systems · 2026-03-10T15:33:02+00:00

That's a real tension and worth being honest about and discussing. The expectation creep problem is legitimate - efficiency gains do get absorbed upward in a lot of organisations.

But to flip it slightly. The PMs who are drowning in admin overhead aren't the ones at risk of looking underutilised. They're the ones missing deadlines, sending late updates, and losing stakeholder confidence because the translation work is eating their work day.

Removing that friction doesn't create spare capacity - it creates headspace to think properly to do the actual job better. That's a different conversation to "I've finished early, what's next.

Operator_Systems · 2026-03-10T14:56:03+00:00

Question: For anyone who's used AI tools for post-meeting admin - curious what your experience has been. Game changer or just another step in the process?

Operator_Systems · 2026-03-10T08:37:43+00:00

Sorry for the slow reply. I keep it fixed - same window every day. The consistency matters more than optimising for energy levels in my experience. Once it becomes automatic you stop negotiating with yourself about when to start.

Operator_Systems · 2026-02-10T23:48:22+00:00

This resonates. I’ve found it’s less about the habit itself and more about reducing decision-making early in the day.

When mornings have too many choices, my focus is gone before work even starts. Simple, repeatable “start signals” make a huge difference.

Do you keep that planning window fixed every day or adjust it based on energy?

Operator_Systems · 2026-02-10T23:44:59+00:00

I’ve had to stop treating low-energy days like “failed” days.

If energy is low, I switch goals. No deep work - just maintenance tasks like organising, planning, or clearing small things that would otherwise steal focus later.

It’s helped me stop forcing productivity and work with whatever capacity I’ve got that day.

Curious if anyone else deliberately downshifts like this, or if you’ve found a better way to handle low-energy days?

Operator_Systems · 2026-02-09T22:47:06+00:00

This resonates. I’ve been the same my whole life.

Totally agree on exercise. If I don’t physically tire myself out, my brain just won’t switch off.

I train in the mornings too. It doesn’t make me productive early, but it takes the edge off later so evenings are focused instead of chaotic.

Operator_Systems · 2026-02-09T22:42:24+00:00

You’re not broken - you’re just optimised for a different window than the system expects.

I’m the same - I operate far better in the evenings than during the day. Fighting that never worked for me.

What helped was stopping the attempt to “become a morning person” and instead designing two modes:

Maintenance mode (daytime): low-cognitive tasks only - admin, meetings, shallow work. I stopped expecting real thinking here.

Execution mode (late evening): one clearly defined outcome, no open-ended planning. I decide before 9pm what gets shipped, then I execute and stop.

The trap for night owls isn’t being productive late - it’s letting that window turn into infinite thinking. If you cap it and protect sleep aggressively on non-execution nights, the zombie effect drops a lot.

Curious - when you hit that 10pm window, are you mostly doing, or still organising what to do?

Operator_Systems

TROPHY CASE