Relentless Collaboration
Last year, I started rock climbing as a hobby. I didn’t know much about the sport or how competitions worked, but when I saw that my gym (boulderkeskus) was holding its annual bouldering open comp, I decided to go along and spectate. As someone who watches a lot of different sports, I have found the commonalities between them to be pretty much universal. Competitive bouldering, however, has a unique element that was entirely novel to me: Collaboration. In the final round of a boulder competition, the finalists have an observation period to look at the boulders they’ll need to climb ahead of time. While they are not able to discuss things with their coaches, they can and do talk with each other, exploring possible approaches on how to solve the boulder. This happens at every level, I started watching old streams of previous years bouldering world cups and it happens exactly the same. It got me thinking about when and where we collaborate, where we don’t, and crucially, why not?
Finalists from the 2023 Salt Lake City World Cup discussing the W2 boulder
A comparison that seemed stark to me is that of Formula 1, where teams hold their secrets as close as they can. Drivers can often be seen sneaking glances in each other's cars, attempting to glean some insight but it is never freely offered. Now for each F1 team it makes sense to hoard their secrets, they want to maintain a competitive edge, but if they were to collaborate the advancement of the cars overall would most likely improve dramatically. My experience within software development has had plenty of chances for collaboration, but also many moments where it was considered non-optimum. I wanted to explore whether collaborative efforts might have a place in more situations, maybe even all situations.
Pair programming is something I have long been a fan of. It is a widely used practice where two developers work together in real time on the same piece of code, typically with one person typing while in constant discussion with the partner on what they are doing. Mob programming extends this concept to involve a bigger group of people. Over the years I’ve used both pair and mob programming in many teams and companies, and I have seen a consistent pattern emerge. Those unfamiliar with the practice are deeply reluctant beforehand, but after taking part, the vast majority see it as a great exercise and want more of it. So why the reluctance? And why the turnaround after giving it a go.
In my experience, the reluctance principally stems from a fear of looking stupid or making mistakes in front of our peers. When I am coding I constantly have to google the basics of syntax in whichever language I am using at the time. We all suffer from imposter syndrome to some extent, so the idea of letting someone else in on those moments is scary. I think that is also precisely why it is worthwhile. It shatters that illusion of perfection and reminds us we are all fallible, while also showing us that we have insights to contribute.
As for why so many developers are swayed to loving pair and mob programming, I think it gives you a full hit of all the benefits of collaboration in one go. In collaborative coding, the first thing you get is instantaneous knowledge sharing and learning. Working independently in coding, your focus is generally on getting things to work. There will always be a more elegant solution, but we don't have the luxury to exhaust every approach posted on Stack Overflow in pursuit of perfection. But when working with a group or partner, you will just get this back-and-forth of sharing ideas and suggestions for improvement that you wouldn't even have looked for by yourself.
In every team I work with, I push for integration of development and design. I believe that the output you get from having front-end developers and designers working in unison will always surpass what you get in the traditional flow of a designer building a lifelike mock-up for a developer to then build again in code. This comes from the exchange of knowledge; a developer will see constraints that a designer won't have foreseen, and a designer will notice issues in the real product that wouldn't surface in a mockup. This isn't unique to design and development; any collaborative environment will give rise to increased productivity through the combination of different perspectives.
Another significant benefit of collaboration is the building of trusting relationships between team members, which is why I am fond of finding ways to collaborate outside of the normal working duties. Developers might have very few occasions to work together with members of the marketing department, but finding opportunities for them to do so can create bonds throughout a company. One memorable example that sticks with me is the Halloween party we had at the office a few years ago. We decided to build an escape room. There were 5 or 6 of us involved in the planning, coming up with puzzles, setting up the clues, getting the room ready. This kind of creative project was hugely enjoyable and was the genesis of relationships with people who I likely wouldn't have interacted with meaningfully had it not been for that project.
When we founded Better Goals, we wanted to facilitate collaboration wherever we could. In the simplest instance, we built the assignment of tasks to allow multiple assignees. This is a fairly trivial implementation detail but something that has frustrated me in the past when working together with someone else and being unable to have us both visible on the ticket. A more involved functionality that we have been building is pair programming suggestions, which would match people with skills or expertise in one area with someone keen to learn those skills on a work task requiring the use of that skill. This would promote collaboration and knowledge sharing in a way that aligns with the goals of the organization.
When I first had the idea for this article, it prompted me to think about how I could bring more collaboration into my working life. There were a few things that were straightforward to just start doing and some that will need a bit more involvement. The first and simplest thing I started doing was to start my days with unblocking. Rather than wait for people to come to me asking for help, I spend the first minutes of my day proactively looking for other people's problems that I might be able to help with. Often there are straightforward things like configuring access to a system or reviewing PRs that are just sitting there waiting for action. By putting this first on my agenda every day, it keeps things from stagnating and puts me in a mindset to look for ways to help out and work with others.
In a similar vein, I have asked all the developers in my team if they would be happy to do periodic pair programming days with me. This gives me the chance to understand firsthand what their work is, get to know better how they think, and how I might be able to aid them in their career development, all in a fashion that doesn't detract from their normal work, hopefully even the opposite.
The last and most laborious idea to come to me stems from the thing I miss from the pre-COVID days when working in the office was the norm. That is being able to bounce ideas off the people sitting around, ask them questions, get them to take a quick glance at a piece of code as a sanity check. So, I started to think about hosting collaborative coding days, reserving a space somewhere, and inviting people to come along and work on whatever their current project is but with the intention to workshop ideas with the other people in the room. I floated this to a few people in my circle to a very mixed response, some feedback that could be taken into account, such as trying to choose a narrow enough theme that people would feel able to contribute. So, I am currently leaning towards language-specific events. For example, a Kotlin collab day, where anyone working on a Kotlin project could come. That way, there would be enough shared understanding to be able to have those insightful conversations. I am really keen to try this out but really need more people outside of my immediate circle to validate the concept, so I will use this article as a callout to any developer who would be interested in attending such an event. If you are in or around Helsinki, then email me at nathan.holland@bettergoals.io, saying which languages you are working with. As a bribe to drive participation, I will also throw in 3 months' free use of the Better Goals app for anyone attending a collab day.
In exploring this topic, I have come to see vast potential for increased collaboration within work to produce more innovative, efficient, and enjoyable workplaces. Embracing this potential requires a conscious shift in mindset, which in business is always fraught with risk. We need to create supportive and nonjudgmental spaces where we can foster an atmosphere that produces collaboration and empowers people to learn from one another.