Method Talks 001: Why managers lose time joining the dots (and how to stop it)

“Joining the dots” is when a project doesn't move forward on its own and somebody has to glue it together by hand: gathering feedback from several places, comparing file versions and reconciling contradictory comments. You recognise it when the number of calls and revisions goes up while the deadline keeps slipping. In practice the manager acts as glue between departments and suppliers instead of managing an outcome. In this episode I show how the mechanism builds up and how to cut it off with a few simple rules.

Because the work goes round in circles: people are doing things, nobody closes a decision, and feedback arrives through several channels in several versions. Add file chaos (“final_final”) and too many people weighing in at the last minute. The result is simple: a lot of activity, little progress. In Method Talks I break this into seven specific causes and show which are usually the most expensive before a launch.

First: one person has the final word and closes decisions, not a committee. Second: feedback goes to one place and takes one form (comments on the file, not WhatsApp plus email plus a call). Third: there is one “RELEASE” package, so everyone knows which version goes out. This isn't a revolution, it's order — and it saves hours a week. In the episode I explain how to put it in place even in a company currently held together with glue.

One specific person who is accountable for the outcome: the project owner, the marketing lead or a director on the company side. Everyone else can advise, but nobody should be able to block indefinitely, because then the project never ends. The worst case is “a meeting of eight people a week before opening”, where everyone adds their two pennies. In the episode I explain how to set this up without politics and without firefighting.

Set clear roles: one person approves, at most two comment, everyone else simply has visibility. Open a window for comments early instead of allowing a “sudden board review” at the last minute. Most of the sulking comes from there being no rules, so everyone feels part-owner of the decision. In the episode I show a simple way to gather the team's feedback without turning it into a parliament.

Set one route: feedback in one place only, ideally as comments on the material itself (a board, Figma, a document with comments). Whatever comes up on a call has to end up in the same place, otherwise you're running parallel lists of revisions. Scattered feedback is the classic reason a manager ends up joining dots rather than delivering. In the episode I explain how to set this up so it's comfortable for people and workable in practice.

The most expensive thing in a project is working on the wrong version, because you end up revising revisions and losing time hunting for “the right one”. The fix is simple: one place for the final and one “RELEASE” package before publication. Add plain file names (date, version, owner) and you know immediately what's current. In the episode I explain why this small thing can save a launch and the team's nerves.

First: who closes yes/no decisions up to launch day. Second: where the “RELEASE” package with the final material lives (one link, not twelve threads). Third: where the last round of feedback goes and what is already closed, so nobody touches it in a panic. A launch is a test of the organisation, so these three make the biggest difference. The Method Talks episode gives you the whole context: where the fires come from and how to stop them.

Because each supplier delivers their own fragment and nobody is accountable for the whole or for consistency, so it all starts to look like a patchwork. The manager then becomes the integrator, explaining, tying up loose ends, correcting and settling conflicts of interpretation. It can be prevented: either you have one integrator role on your side, or you work in one system with a clear brief and standards that apply to everyone. In the episode I show how this chaos builds, especially at launch, when it “needed to go live yesterday”.

If you keep producing more material and it still isn't clear who approves, where the feedback lives and which version is final, the problem isn't the material — it's the absence of rules for delivering. New “pretty things” can even make it worse, because they add more threads and more versions. The real test is the launch: can you pull it all together without an all-nighter. In the episode I explain why companies confuse these two problems and how to check quickly which one you have.