Communication lines are down

There's a storm brewing in your company. Businesses of every shape and size, at every level of success, are susceptible to standard-issue communication problems and if you don't fix them, you'll lose power.

Companies are ravaged by this problem, yet somehow they battle along despite it, lurching from one quarter to the next, flailing away, beset with fatigue and endless frustrations. There's a good chance communication lines are flaky in your company, but it's not that hard to remove the weeds, the broken branches, reinforce the cables and get the signal transmitting across your business again. You just need to identify the problem and have the strong will required to fix it.

I recently experienced a business communication failure after we encountered an internal bathroom leak in our house. It turns out, just like consumer electronics today, modern bathrooms look fantastic but they're very difficult to repair. Plumbing is boxed in and tiled over, leaving no way to replace the internals without bringing out the sledgehammer and bashing holes in the wall. Exhibit A:

A contractor was booked in to fix everything. The tradespeople who came around to assess the sitution and rip everything out seemed switched on, but the communication lines in the business were faulty. Despite a wealth of skills and trades on hand, the project was cursed by correspondence. Rather, by the lack of it.

We received a schedule of works – a project plan – before the job started. It wasn't as detailed as I would have liked but it was good enough, so we made the necessary arrangements. The schedule was pulled at the eleventh hour the night before the work was due to start.

We were left in the dark for days. Despite several emails to people in the business, along with follow-up phone calls, we had no idea what was going on. It turns out the shower unit was delayed, but nobody could tell us for how long. Two weeks later we got a new schedule, and this time the job started – just not in the order they said it would! The tradespeople turned up on time wanting to do a good job, but they were equally clueless about when their colleagues would be showing up. On one occasion, a joiner turned up to fit a floor but the shower tray wasn't on site like he assumed, so he had no idea where to drill the holes for the plumbing (I sent him home). On another occasion the plumber turned up to fit the shower, but he didn't bring the cubicle walls – nobody had told him to call into the warehouse that morning to collect it. Then, when the tiler was one small wall away from finishing, he ran out of tiles. Nobody accounted for the ~10% cutting wastage when measuring up the room.

A lot of stress, wasted time and frantic last-minute fitting could have been avoided by simple communication improvements in the business. In this case, something as simple as this would have saved a lot of headaches and frustration:

• A WhatsApp group for all the tradespeople involved, plus the project manager (apparently there is one 🤯). Send one message at the end of every day telling everyone where to go the next day, what to bring, and what to collect.
• Send an email to the client (🙋‍♂️) confirming who'll be showing up, and when.
• Actually respond to inbound email queries!

From what I've learned from the tradespeople, this company is juggling a lot of jobs across the country. It can't be easy to manage, yet I'm sure some simple but fundamental tweaks to the comms lines of the business would result in massive improvements to the experience of clients, as well as staff performance and morale.

There are parallels with this experience and how companies typically run software projects. Instead of six tradespeople, imagine you're running a development team of six software engineers. Instead of refitting a bathroom (which would be a brilliant team building exercise btw – you're welcome), they're reworking the billing code and integrating a new payment provider. This needs to be completed by the end of the financial year in two months time – no ifs, no buts.

Let's assume the scoping work has been done well. Milestones have been produced, there's flex to reduce scope in a number of places, so the developers are confident they can implement the feature in time. They'll start by tackling the known unknowns and the hardest work, getting to the epicentre of the problem if you will.

Now imagine two scenarios for the implementation.

1. Chaos

The engineers are working in isolation. They get assigned Jira tickets, but they're not fleshing out any detail beyond a card title. The project Slack channel is oddly quiet.

The team meets once a week and they do a round-the-table status update. The engineering manager and product manager have lots of questions and the meeting regularly drags from its scheduled 30 to over 90 minutes. The managers feel a bit stressed because they think more should have been accomplished. They're starting to lose trust in the developers.

Nobody thinks to update the CFO – the client – so she drops the team lead an email but does't get a response for a couple of days. The CFO reports her disgruntlement in the weekly Exec meeting, which pisses the CEO off who proceeds to give the CTO a hard time. The CTO is irritated, so piles into the engineering manager Slack channel demanding a status update. They agree to have a meeting which is delayed because the first time everyone is available is in 3 days time. And so it goes.

Two weeks before the deadline, the CFO is freaking out. The CTO is back in the Slack channel arranging emergency 1-1s, trying to understand what anyone is doing because none of the Jira tickets have been updated, and nobody tells him anything.

Communication lines are down and it's chaos.

After several late nights, prolonged code reviews, hot fixes and manual testing by engineers pulled in from other projects, the project goes live on time. There are a few teething problems, one rollback and a few emergency releases. Everyone is stressed out, trying hard not to blame everyone else. At least two engineers have been updating their LinkedIn.

Sadly this is business as usual.

2. Calm

The engineers are working in isolation. Each one owns a milestone, and when all the milestones are completed, the project will go live.

At the beginning of each week, every engineer writes a few paragraphs about what they're planning on accomplishing that week, and how it fits into the milestones. They're holding themselves to account, and they find the mild pressure of their own weekly goals motivating. In addition, at the end of each day they write a similar status update detailing what they've worked on, what blockers they've encountered, and anything they need help with. They also monitor the project Slack channel, chipping in if they can help when questions are raised.

Engineers from other teams with experience in billing occasionally chip into the comments on the status update to point out pitfalls and offer advice. The CFO reads the updates at the end of each week. She's kept informed without having to nag, in fact she's regularly pinged by engineers throughout the week about specifics, which she answers in return. Sometimes she pings the engineers with questions, all of who reply quickly.

It's all very cordial and collaborative.

At the weekly engineering all-hands run by the CTO, one of the engineers does a show and tell about a new billing abstraction layer she's developed. A few people offer feedback for improvements which she takes away to address. She also has some ideas about open sourcing the library later which people are enthusiastic about. The CTO raises the idea of a company blog post, so she agrees to draft one in the next cool down week.

There's a rush of activity in the week leading up to the launch, but it's largely stress free. The good adrenaline stress, not the bad stuff. The feature ships and the CFO is super-happy. There are a few production niggles, but they get squashed quickly and without drama with a few hot fixes that morning.

Two scenarios, the same people, the same work, yet one situation is mired in chaos and calamity while the other is calm and coherent. Why?

The answer is simple:

• Excellent communication = calm
• Bad communication = chaos

Communication is one of those unappreciated things that makes an outsized impact when done well. It's hard to visualise, so people don't put enough value on it. It doesn't get nurtured, often it goes completely ignored. This is major misstep because communication is the information current that flows through your business. It's vital lifeblood for company health, team cohesion and successful software delivery. Ignore it at your peril!

These days I work with tech businesses to improve the performance of their engineering teams, and I find that some of the highest impact work is optimising teams for better communication. Improve comms and you improve performance.

The good news is that many of these communication issues can be solved without turning the whole house upside down. The bad news is that while the solutions can be straightforward, habits are terribly difficult to change. Your team – in fact, the whole company – has to work relentlessly to improve the situation, introducing new rituals, practices and processes. Leaders have to set the example then constantly reinforce why better communication is crucial. You need buy in across the board, so you need to over-communicate this until you're bored of yourself. Only then will the message have really sunk in.

If you successfully battle through this long struggle, you'll find that your people are happier, more productive, and far less stressed. Things will ship on time, and without all that drama (there will still be drama, sorry). Calm comes after the storm.

A calm company is a happy company. If this is what you want for your business, take a good look at your communication lines and take action to ensure that information is flowing at full capacity.