Dear leaders,
The race to “AI nativity” goes on. Most of us feel the disruption is coming and keep thinking about how to transform into an (extremely) fast-paced environment.
When you read one of the playbooks, like Anthropic’s AI-native SDLC playbook, FOMO hits hard:
Traditional: An idea passes through backlog entries, user stories, story points, and refinement meetings before anyone can act on it.
Sounds great, no?
But for many companies, reality is still on the Traditional end.
We do have sprints, estimate the work, and run refinement sessions. Not because we stick to “bad practice,” but because it still works.
I also want to go against the current and jump off Jira. But what if we can’t? What if the better future hasn't been invented yet?
Instead of dreaming about how we will work in 2030, I've been asking myself: given we all have the same environment, what’s the difference between a high-performing team and a regular one?
In an organization of >200 engineering and product people, we still do time-boxed sprints, agile ceremonies, close tickets within the same flow, and use similar templates across the company.
But one thing varies widely: how our teams use Slack. That's where my investigation started.
For context, I’ve used Slack for over a decade. I read >30 channels per day, following probably 5x-7x more. Most of them are already silent—either dead from the start or on an exhausted topic. Our teams are spread across countries and continents, with half the individuals working fully remotely. Basically, we are remote-first.
If your environment is similar, you surely know the rule: have a dedicated channel per team, initiative, or project. Yeah 😎, I also created dozens of them: <project>-kickoff, <initiative>-sync, <subject>-lets-do-quick-poc, <yet-another>-taskforce.
There were a few successful ones, but the majority didn’t take off. 🤷 And I wanted to understand the mechanics behind the ones that did. The channels that push high-performing teams forward.
Here’s what I learned from the one led by a highly diversified remote-first task force that combines multiple highly specialized domains. They've coordinated the company’s critical project for months in fast-paced iterations. From the outside, it looks like a never-ending crunch, but the people there stay highly motivated, with no signs of exhaustion.
What principles drive them?
Here are the takeaways from my investigation (quotes are anonymised):
1. The Empathy of Project Memory
The channel is not just a chat room. It reflects a group’s collective mind in real time. The project's history accumulates in one place, rather than disappearing into standups or private messages.
A team treats this place as a durable, externalized brain for their work. For example, when a team lead wraps up the week with a highly structured summary, it is less an act of bureaucracy and more an act of empathy.
This discipline extends to how they treat data. When facts are needed, they post dashboards and metrics directly in the channel, never describe them secondhand. Bigger topics or initiatives keep to their own threads. Decisions made arrive with described reasons.
“can we stick to discussing [the feature] in the thread above?“
I’ve come to think this matters less as efficiency and more as ethics. It’s like: we owe each other an account of what we are doing and why.
Memory, in this sense, is a form of respect for the people who weren’t in the room, and for the future selves who will forget.
2. The Clarity of Explicit Ownership
There is a big difference between throwing a request into the void and handing it directly to a person. When a problem is a generic “can someone look at this?”, it’s an invitation to the bystander effect—everyone assumes someone else will pick it up. Sometimes we wait patiently for an “👀” emoji below our question, but it never arrives…
“Hey @Mirek, I understand [team member] is already on vacation. We need you to represent Infra...”
High-performing teams use names. Explicitly tagging individuals isn’t micromanagement; it's the simplest form of accountability. By doing so, the team ensures critical momentum isn’t lost in the assumed responsibility.
3. The Courage to Admit
Perhaps the most defining trait of a mature team is how it handles vulnerability. The strongest teams aren't afraid to look unsure or ask for immediate help in front of the group, which is exactly how risks surface before they become production incidents.
This same radical transparency applies to failure. In the channel, the team explained a production incident without defensiveness. Not just the fix, but the uncomfortable part: “our own tests hadn’t caught it, and neither had the review. The safety net had a hole”. It’s nothing but Westrum’s generative culture at its best.
Most incident reports end at the repair. This one went on to admit the limits of the team’s vigilance. That maturity treats failure as shared information rather than private shame, and it makes the next failure less likely because everyone owns the lesson.
Read more:
4. The Agency of the Proactive Pause
In environments lacking trust, it is natural to appear in control or to hide blockers, waiting for leadership to ask for a status update. In this team, a realization that a proposed infrastructure solution was flawed resulted in an immediate, self-directed stop:
“I ask my team to pause work on this functionality... It seems that the proposed solution does not meet the legal requirements and we need to review that with the infra team.”
The engineers halted the work, documented the reasoning, and tagged the stakeholders—proactively, not defensively.
In the healthy culture, there is a freedom to say, “we were wrong, stopping now,” without fear of looking foolish.
That feeling of safety is science, by the way. Read more on Neuroception in leadership 👇
5. Recognition as a Living Narrative
High-performing teams understand that work is inseparable from the people doing it. When a complex new feature ships, they don’t just announce the technical win. They celebrate the engineer who built it:
“Hey guys, [A person] built end-to-end—backend, orchestrator, frontend—by [team member], on his own. A great example of his shift from QA into a software engineer role.”
This is more than praise. It is attention. It tells everyone watching that growth goals are being noticed here.
The work is a story about a person, not just a closed ticket.
The Mechanics Behind a Shared Memory
None of this is mystical. Here is how this team translates trust into their own playbook:
1. Single source of truth per workstream
How: The PM or leaders post a recurring weekly status with progress and blockers in a single consistent thread.
Why it works: Anyone can scroll back and reconstruct the full history without pinging people for context.
2. Thread discipline
How: Each distinct topic (a compliance review, a product flow, a UX change, bugs) gets its own root message and thread rather than mixing in the main channel.
Why it works: Parallel conversations stay untangled, and searching one topic doesn’t surface unrelated noise.
3. Role-based cross-functional tagging
How: A lead loops in Product, R&D and other stakeholders by name on the dedicated threads.
Why it works: Ownership is explicit when work is raised, so items don’t stall waiting for “someone” to notice.
4. Real-time blocker and incident reporting
How: An engineer flags a production bug within minutes of discovery, with full context, instead of saving it for standup.
Why it works: It shrinks time-to-unblock. Nobody is silently stuck for a day waiting for a meeting slot.
5. Visible wins with attribution
How: Shout-outs name the engineer and the concrete deliverable, such as an internal support tool.
Why it works: It reinforces ownership and morale, and creates a searchable record of who built what.
6. Data shared in place, not secondhand
How: The analytics dashboard and traffic reports are attached directly in the channel.
Why it works: Decisions can be traced back to the actual data later. No “I saw it somewhere” ambiguity.
7. Decisions and pivots documented with reasoning
How: Pausing work because the proposed approach didn’t meet a regulatory requirement is posted with the reasoning and relevant stakeholders tagged.
Why it works: Future readers understand why the direction changed, not just that it did, avoiding re-litigating settled decisions.
Anti-Patterns to Watch For
To audit your team’s communication, check out the critical project’s channel for these warning signs:
No single thread of truth: Status lives in people’s heads or goes through private DMs, making it impossible to reconstruct the “why”
Delayed transparency: Blockers surface only in scheduled standups instead of in real time, actively delaying unblocking
The bystander effect: Vague “can anyone fix it pls?” is dropped without tags, leaving ownership unclear
Opaque execution: Wins or hotfixes are announced without attribution or technical detail
Hearsay data: People reference dashboards and reports verbally (“I saw a report somewhere”)
A bet worth making
Let me be honest about the limits. This is one channel, one task-force team, and a few months of messages. It’s quite possible that strong teams write like this because they are strong, not the other way around.
But I can’t unsee it either. Nothing I found needed a new tool, a new framework or a reorg. It needed people to write things down where others can find them, to name an owner, to say “I might be wrong,” and to stop when something isn’t working.
There must be something in it..
P.S. Writing with clarity is one of the signs of high-performing people.
Read more:
