Once in a blue moon or maybe a few times a year, there’s the strategy retreat, the company-wide event, the collaboration day or the cross-functional workshop. The marketing is all about the benefits of getting together, sharing knowledge and collaborating cross functionally. Perhaps that day will be the first time you hear about what’s going on in marketing or sales and how it relates to your projects, or the news about the future company plans. The day comes, the event’s a success, everyone got together and collaborated, exchanged or brainstormed ideas. Tomorrow will be a brave new world! Tomorrow you’ll pick a new ticket and get your head down, and the next day, and the next one, barely talking to anyone in order to maximise building efficiency. Collaboration sure was fun.

Collaboration doesn’t get solved by a one-off event or workshop. Camaraderie doesn’t appear in a day. The most effective way to improve collaboration and camaraderie is by doing good work together and often.

A basketball team doesn't become a better and more cohesive team by just having one meeting a year when they collaborate. Only by playing, learning, practising and going through challenges together, they can build the reps and know each other. If every member of the team would work alone, looking only for their own interest, or wanting to only play 1-on-1 with their defender, that would only be five different individuals doing their own separate things, not a team.

If there’s one thing that characterises a real team is that there are shared goals. Everyone rows in the same direction. Unfortunately, even when we think we row in the same direction, more often than not, we aren’t. We might be divided, split by functions, or we might not have any other goal than to produce artefacts—code, UI designs… The designer’s over there with the designers doing designer things, same with the product manager, and we are here doing our own thing. Meanwhile, nobody—or just a few chosen ones—have talked to a customer, learnt anything about them or the business or know why we’re doing what we’re doing. There might be a shared objective, but it's spread across many people and communication borders. Ultimately, we end up rowing in so many directions that cancel each other out or that take us through sinuous routes to some place we didn’t want to go.

The work is not to produce artefacts. The meetings are the work, the work is the conversation.

When a developer codes, unless they code for themselves, they are taking stories, narratives, ideas that go from human to human, mind to mind, crystallising them in software. In that endeavour, building and refreshing continuously our shared knowledge and understanding about reality is at the core of the matter. If we focus too much on the artefact, the software, as a reflection of our understanding—or lack thereof—will integrate our misconceptions, assumptions, biases…

Humans communicate with stories and narratives, as seen by the importance of oral tradition through the ages. Working in isolation, without talking to one another for hours or days, or in silos, where the information doesn’t flow, makes the narrative disjointed and out of sync… The more isolated, the farther our stories diverge as we fill in the gaps in our individual understanding with assumptions of our own.

Because working solo causes our narratives to diverge over time, it’s not uncommon to see that once it’s time to deliver, it’s already too late or that more effort is needed to recalibrate our understanding and the software. Working solo and in silos tend to favour long stretches when no sync happens, as we’re too busy building the thing, while work accumulates in queues (handoffs between teams, work stagnates in phases, work not being released, etc.). Communicating and collaboration take time away from building and, since they’re not considered “real work”, they’re only done in the minimum required amount of time, and the less time we dedicate to them, the better.

Even if we could avoid talking to each other and only use asynchronous means, we’d still need to get to a shared understanding of reality. We would need to go back and forth, ask clarifying questions, confirm that what I have in my head it’s the same thing you have in yours, even though we could be using the same words. There are no requirements perfect enough. We can’t escape the conversation, synchronous or asynchronous, unless there’s only one person here: you.

Getting a team to collaborate is not an easy task. Many people work together for years without actually collaborating towards shared objectives, without having any sense of camaraderie or belonging, or feeling safe to have open conversations. A team that collaborates well requires not only shared goals (no competing agendas, no silos, no competing for resources) but also a safe space—psychological safety—to be able to embrace healthy conflict and comfortably criticise ideas. There has to be a change in behaviour, a willingness to listen more than talk, a willingness to ask rather than having all the answers.

When I write team, I’m thinking of a team of people with different skills, backgrounds, and points of view, mainly a stream-aligned team, not only a developers’ monoculture. I’m not saying that a developer only team is an antipattern, there are valid scenarios for it, but if we’re trying to create products that people will use, we need more skills and perspectives—and definitely the customers’ feedback.

Collaborating well comes at different levels. The developers should collaborate to design, build and manage the complexity of the system. Designers, product managers and developers—and everyone else that could be involved—should work to build shared understanding about reality and learning about said reality. The shorter the feedback loops, the better the learning and the sooner we discover when we’ve diverged or need to change direction.

Instead of waiting until the end or minimising the value of collaboration, build shared understanding frequently. A team that starts together creates shared stories that have a better chance of being crystallised in the code. Starting together means discovering together, researching the problems together.

Ultimately, the artefact—the software—will be the source of truth for our conversations and our shared understanding. Once we are no longer in the team or, like the Ship of Theseus, the team has different people, the software will be what’s left. If our conversations were lacking, worked in silos or didn’t have a shared reality, all of those will manifest in the system we leave behind, and, more importantly, the human on the other side of the screen will notice. Sometimes it will be a slight annoyance, sometimes it could be inhumane, sometimes it could be deadly.

Interesting links

• Why I’m yet another woman leaving the tech industry

• Confronting Mythology. “When employees say they want ‘transparency’, that does not mean they want to hear from executives more. It means is that employees want to be privy to the dominant hidden transcript. Any attempt at transparency that fails at this is bound to backfire.”

• Power Causes Brain Damage