Most of the project messes I’ve been pulled into weren’t caused by bad code. They were caused by the right information not reaching the right person until it was too late. Since stepping up as project lead at work, I’ve been keeping notes on how I’d want to run communication if I ever end up in the CTO seat. Here they are.

Decide who needs to know what

#

The unglamorous foundation is a communication plan: who needs to be informed, what they need, how often, and through which channel. I’d push for one at the start of every project, with names attached — communication that’s everyone’s job ends up being no one’s job. The same goes for stakeholders: work out who actually cares about the project, learn how each of them prefers to be updated, and don’t send the CEO the same update you post in the dev channel. Finally, set a few explicit protocols — expected response times, what counts as urgent, which channel is for what. Most “communication problems” are really just unstated expectations.

An example communication plan for a software project

#

This is the plan I’d start with and then adjust. Each row is an audience, not a meeting:

Underneath the table go the protocols, written as plainly as possible: urgent means it blocks a release or a customer, so call rather than message; questions go in chat, decisions go in the tracker; replies within a working day. For the decision log I use decision documents, kept as GitHub Issues so they sit next to the work.

Two things make a plan like this work. Every row has a name in the last column, and the leadership update is written rather than spoken, so it can be forwarded without losing anything.

Tools and rhythms

#

Tools matter less than people argue about them. Slack for chat, Trello for tasks, Zoom when a conversation needs faces — pick what fits the team and move on. Rhythm matters more: daily stand-ups if you’re working agile, weekly updates on longer cycles, and actually holding to them. And write things down. Decisions, changes, action items — into Notion or Jira, as part of the process rather than an afterthought. Six months later, the doc is the only memory anyone has.

The soft parts are the hard parts

#

Everything above is mechanics. The harder work is asking the team whether the communication is actually working, and changing it when it isn’t. It’s training people up, too — teams come from varied backgrounds, and not everyone has seen a well-run project before. It’s listening properly instead of waiting for your turn to talk, and dealing with conflict early, while it’s still small. None of it stays solved, either: what worked last quarter quietly stops working, so keep checking.

Working as a distributed/asynchronous development team

#

This talk is worth your time if your team is remote or async-heavy:

I don’t do all of this perfectly — nobody does. But every project that went smoothly for me had most of these in place, and every one that hurt was missing at least three.