Reduce Friction: Every Required Message Is a Process Failure
By Darryl Brown
Our communication problem wasn’t too many meetings. It was Slack, our internal messaging platform.
More precisely, it was the fact that our process required Slack interactions to function. For many common stages in our process — a priority shift, a handoff, a release request — someone had to message someone else. The work couldn’t progress until a person intervened. And so people intervened, constantly, because that’s what the process asked of them. Nobody was doing anything wrong. The system just ran on human nudges, and Slack was where those nudges lived.
The specific friction points were familiar to anyone who has managed a software team. A project manager needed to communicate a priority change and that meant finding the right developer and messaging them. QA finishing a piece of work didn’t automatically signal anyone; someone had to notice and act. Releasing a feature required requesting it of the team member who held that responsibility, which cycled between team members. Every one of those moments was an interruption for both the sender and the recipient. Multiply that across a team of twenty people and dozens of active work items, and the noise adds up quickly.
The deeper issue was that each of those interruptions represented a gap in the process — a place where the system couldn’t carry information from one stage to the next on its own, so a person had to carry it instead.
We moved from Pivotal to ClickUp, but the tool change was almost beside the point. What mattered was how carefully we defined the process inside it. We built a Kanban board where all active work lived, prioritized and visible to everyone. But the more important work was defining the states a piece of work could be in at any given moment. We spent real time thinking through what each state meant, what triggered a transition, and critically: who needed to know when that transition happened.
Let me give a concrete example of what that thinking produced.
One of the most important states we introduced was “Merged.” When a developer merges code to the main codebase, the work is in a vulnerable position. It exists in between intention and reality. The code is committed but not yet in production. That moment deserved its own state, its own visibility, and its own automated response.
In the new process, the developer follows four steps:
- Merge changes to the main codebase.
- Test, if needed.
- Mark the work item to “Pending Deployment” in our board.
- Release the code by typing /release into Slack.
Within those steps, a lot of automation occurs in the background, giving the developer all the information they need to move through each step and release to production confidently. Notably, there is no communication with anyone else required. The developer does not need to reach out to a single person. The result was that everyone on the team received both the power and the responsibility to release code.
To appreciate why that matters, it helps to know what we replaced.
Previously, releases were a significant event. Over the course of a month, and sometimes up to three months, developers would merge work into a shared codebase. When the team decided enough work was ready, QA would test the entire batch together. Spreadsheets tracked names and versions by hand. A person was specifically assigned to each release, responsible for preparing and executing a lengthy set of release instructions. As often as not, something would go wrong mid-release, pulling in various people to troubleshoot. The release was a staged production itself.Now a developer types /release in Slack. That’s it.
Early on, there was hesitation about whether something that simple could really be trusted. I answered that question one afternoon when I took some time off to go mountain biking. In the middle of my ride, I pulled out my phone, typed into the Production Launch channel that I was doing the next release, tested the new command via Slack, and sent an irrelevant selfie from the trail. The release went fine. If the CTO can release code from atop a mountain bike, the process has genuinely changed.
The wider goal of reducing communication was simple in principle and harder in practice: a developer should be able to look at the board and know exactly what to work on next without anyone messaging them. QA should know when something is ready to test without being pinged. A priority shift should be visible to everyone the moment it happens, without a broadcast message.The process should carry the information, not people.
Another change I’m pleased with is one we built with n8n to address the code review problem.
Anyone who has worked on a software team knows the notification problem. The volume is extraordinary — review requests, comments, approvals, automated assignments. It becomes a firehose of information. I turned off all GitHub email notifications some time ago. They stopped being useful precisely because there were so many of them.
A little context for non-technical readers: when a developer completes a set of changes, those changes must be peer reviewed before they can be tested or released. A second set of eyes catches problems before they reach customers. Those review requests get assigned to another developer — and developers, reasonably given the noise, weren’t always responding quickly. Work sat waiting. There was no clear picture of where things stood.
Rather than creating a new reminder process or a policy about review turnaround times, we built an automation. At the start of each day, it looks at all open review requests, checks their status, and sends a single targeted Slack message to each developer summarizing everything pending — both requests waiting for their review and their own changes waiting on others. It also shows how long each has been waiting.
Here’s what that message looks like in practice:
Aldo Rojas — Outstanding code reviews
0 days old — reviews to complete:
- Fix form search field bug — IN REVIEW
- Add ability to restrict assets via cabinet menu — IN REVIEW
Reviews needing attention:
- Adding quarantined assets to quality checks — CHANGES REQUESTED
Your changes in review by others:
- Removing Missing Image / kept Missing Stencil Image — waiting 10 days
- Applying changes to traceability dashboard — waiting 11 days
We have a one business day expectation on review responses. The automation didn’t enforce that rule. It just made the current situation visible to the person who could act on it — specifically, clearly, and at the right moment.
That’s the principle I keep returning to, and it connects to something Rory Sutherland explores in his book “Alchemy,” which I’d recommend to anyone who thinks seriously about how behavior actually changes. Sutherland’s core argument is that humans are not rational optimizers. We respond to context, framing, and environment far more than we respond to incentives or explicit instructions. Small changes to what people see and when they see it often shift behavior more reliably than rules or consequences ever could. We didn’t tell developers to review faster. We just made it impossible not to notice when they hadn’t. The behavior changed because the visibility changed. Sutherland would not be surprised.
There’s a pattern in all of this worth naming.
Every place in our process where someone had to send a Slack message to make something move forward was a gap. Sometimes those gaps required human judgement to fill — context, relationship, nuance. More often, they just required the right information to arrive at the right place at the right time.
If your pipeline feels heavier than it should, it probably is. Start asking what actually needs to be there.
We didn’t try to reduce communication. We tried to make communication less necessary and less driven by people. When someone did reach out, it was because something genuinely required a person, not because the process had failed to carry information on its own.
Next: we took this further. Once we’d reduced the communication our process required, we turned to automating the repetitive tasks that were left. That’s what the next post is about.
