The Culture in tools

This isn’t a post about messaging platforms. It’s about how organisations work, or want to work. For most companies I’ve worked with, I’ve watched teams perform brilliantly, and struggle, based on something as seemingly simple as where they write things down. At many of these companies, we’ve had both Slack and Teams. Mostly based in historical dependency to Microsoft through the evolution from Windows Server and Exchange, to Office365 and Azure.

The debate over which one to standardize on has been framed as a cost issue or a tooling decision. But underneath that is a much more important question: what kind of collaboration culture are we trying to build? The tools we use shape how information flows, how decisions are made, and whether we default to meetings or documentation.

Choosing between Slack and Teams isn’t, in my experience, a neutral decision, it reflects what we value in how we work together.

So, what are we really deciding?

When we talk about Slack vs Teams, we’re not deciding between two chat apps. We’re deciding between two fundamentally different defaults in how we collaborate.

In Teams, every conversation starts with a structure: “Which team does this belong to?” Every new initiative asks you to define a group, name it, and inherit SharePoint resources you may or may not need. It’s hierarchical by design, great for known, ongoing workstreams with stable participants.

In Slack, the structure follows the conversation. You start with the topic or the task. A DM becomes a group. A group becomes a channel. A private discussion opens up. That fluidness allows collaboration to grow organically, not by asking who owns the work, but by surfacing what needs to get done.

To me, that subtle difference makes all the difference. Slack makes it easier to move fast, loop in the right people early, and work transparently. It encourages documentation over meetings. It nudges us toward async by default. None of these behaviours are tool-enforced, they emerge from what the tool makes easy.

This difference in defaults, like task-first versus team-first, async versus meeting-led, doesn’t just affect how we chat. It shapes how fast we move, how inclusive our work tends to be, and how well we accelerate decision-making.

Over time, I’ve seen the Slack vs Teams discussion map quite linearly to a broader shift in how companies evolve. From traditional IT thinking, through digital transformation (as it’s mostly called in the non-software board companies), to becoming truly software-enabled. That journey isn’t just technical or product-oriented. In my mind, it’s cultural.

Here’s what that tends to look like:

Of course, this isn’t the only perspective to consider. Most organisations already weigh the usual factors: license cost, included functionality, Office365 integration, Teams meeting adoption, and increasingly, the role of Copilot and other AI enhancements.

These are valid considerations. They’re also the ones I’ve rarely seen missing in internal discussions.

What I do see missing more often, is the cultural side. The collaboration defaults we set. The kind of behaviour a tool encourages when nobody’s enforcing rules. The shift from calendar-driven to writing-first. From predefined teams to task-first collaboration. From formal to flexible.

That’s the perspective I want to surface here. Because in my experience, it’s the one that makes the difference between tools that are used, and tools that actually change how we work.

But what about actionable steps, do’s and don’t

This post isn’t about choosing Slack or Teams. I’ve seen both work, and completely fail. It’s about recognising that these tools are not neutral, they shape how we collaborate, how decisions are made, and what kind of organisation we become. In this initial POV, I’ve focused on the perspective I see most often missing: the cultural defaults baked into our tools.

In future posts, I’ll go deeper into what I’ve seen as good collaboration culture looks like, in practice. My experience in defining clear defaults, clear expectations. How to avoid chaos without enforcing. And how to, by design, support the kind of work and the kind of culture we want to enable.

Thanks for reading 👍

/M