How Your Culture Influences Developer Team Collaboration

A story hit #1 on Hacker News a few weeks ago titled “The Worst Programmer I Know.” The story’s protagonist, Tim, never scored any story points. Why?

[H]e never signed up for any stories. Instead he would spend his day pairing with different teammates. With less experienced developers he would patiently let them drive whilst nudging them towards a solution. […] With seniors it was more like co-creating or sparring; bringing different worldviews to bear on a problem, to produce something better than either of us would have thought of on our own.

Tim understood this (and nearly got fired for it): development is a team sport. You can only produce a significantly complex piece of software with others, and you all have to be pulling in the same direction to do so.

This thinking is an absolute in high-functioning teams. It is what Toli Apostolidis of Cinch emphasized when we talked to him about the need for developer control planes. You must find ways for your entire team to excel.

How do you build the Tims and Tolis of the world? And how do you scale them?

The Collective Power of a High-functioning Developer Team

Individual brilliance is not enough in the world of software development. No matter how talented a developer is, the magic happens when a team comes together, each member contributing their unique skills and perspectives to the project. It’s this group effort that brings out the best in projects, resulting in a more innovative, efficient, and successful outcome.

So how do we get there? We can think about it in terms of three aspects:

1. Individual responsibility — How can each member of the team contribute more beyond writing their own code? We want team members to be the coaches that Toli Apostolidis espouses, but at the same time need to accept that they are also the “people in the arena,” doing the actual work each day. Thus, we want them to be player-coaches.
2. Team responsibility — How can we make this an approach where an entire team takes accountability ? There will always be individuals like Tim or Toli who work individually hard to help others, but we need this to become a cultural shift that permeates every member of the team. To do so, we want to build communities of practice that focus on sharing knowledge within a team and across an org.
3. Organizational responsibility — Finally, how can an organization help foster a collaborative culture within developer teams? Here, the answer lies in better tooling that is focused not on the ‘story points’ that almost got Tim fired, but on a better developer experience for individual contributors and the team as a whole that is geared towards collaborating across teams and the entire organization.

We want shared responsibility, we want shared knowledge, we want diverse perspectives. But we only get all of those by working at the individual, team, and organization-level to improve developer culture.

Making Every Team Member a Player-Coach

Toli had always seen himself as a coach for each development team he was part of. But having individual coaches for each team isn’t great for scaling. People whose only job is to help others quickly find themselves given other tasks, or are seen wrongly as an anchor on productivity as their effectiveness is difficult to measure (as in the story of Tim).

But one way to start scaling coaches in an organization is to allow more individuals on each team to take a “player-coach” role. A player-coach is someone who both actively contributes to the project (the “player” part) and guides or mentors the team (the “coach” part).

Because player-coaches are directly involved in the project, they understand the challenges and nuances of the work. This firsthand experience makes their guidance more relevant and practical. When team members see that the coach is also actively involved in the project, trust is more easily established. The team knows their coach understands their challenges and isn’t just giving advice from the sidelines.

Tim was performing two common roles for player-coaches depending on whom he was working with:

1. Guided Debugging: When a teammate encounters a challenging bug or issue, player-coaches can guide them through the debugging process, helping them develop problem-solving skills.
2. Pair Programming: Player-coaches can engage in pair programming sessions with teammates. This approach allows two developers to work together at one workstation, with one typing and the other reviewing or guiding. It’s an effective way to share knowledge, improve code quality, and mentor less experienced team members.

Because they’re both in the trenches and in a leadership role, player-coaches can make more balanced decisions to consider both the broader project goals and the day-to-day realities faced by the team.

Not everyone has to be a player-coach. Newer members of the team need time to develop their own skills before coaching others. To effectively use player-coaches in a developer team, it’s important to choose individuals who are not only technically skilled but also have strong communication and mentoring abilities. This is because they need to be approachable and open to feedback, ensuring that the team feels supported and empowered.

Transforming Teams into Communities of Practice

Player-coaches need to be technically skilled, and have strong communication and mentoring abilities.

Such people are hard to find. As Kelsey Hightower, former principal engineer at Google, says, you, “…don’t want a 10x developer… what you want is someone that can come in and make 10 other developers more productive.”

Part of an organization’s responsibility isn’t just to find these people, it is to grow them. One such way is by developing “communities of practice”. A community of practice is a group of people who share a common interest in a specific area and come together to learn, share, and improve in that area. In the context of software development, communities of practice are about bringing together developers with similar roles, challenges, or technologies to help each other.

When developers come together in these communities, they can share what they’ve learned, what’s worked for them, and what hasn’t. This shared learning can save time and help avoid common pitfalls. If one developer is facing a tough challenge, someone else in the community might have faced it too. Discussing together can lead to solutions faster than tackling it alone.

This can go deeper than just dealing with coding issues. As the expertise of the community improves, they can help develop and codify best practices, standards, methods, and tools within an organization. They become the de facto Working Group for their domain. For this to happen, the community of practice has to engage in specifics–it could be kubernetes, it could be the latest JS framework. It could be something more esoteric. In fact, in some ways the more esoteric the better. You want your team to really get involved in the intricacies of a topic.

To build these communities, you can take the lead from the most esoteric thinkers–academia. “Lunch and Learns,” “Tea Time Talks,” and “Whiteboard Sessions” are all ways these communities can come together. To make communities of practice effective, it’s important to create a welcoming environment. Everyone should feel they can ask questions, share their experiences, and offer suggestions without judgment.

The idea is to make these gatherings informal so that more people can participate, and thus not only grow their knowledge of, for instance, Kubernetes, but also their communication and mentoring skills. This makes them better all-round player-coaches.

Regular interactions and discussions can lead to skill improvement, new insights, and even innovative ideas that one wouldn’t have thought of alone. Over time, as members actively participate and the community grows, its collective knowledge and resources become invaluable to both newcomers and experienced developers alike.

How Tools Shape Culture

The above is about how the members of your developer teams can organize better for learning and collaboration. But this is shifting the burden to a potentially already overburdened team. Your team can only become player-coaches or build communities of practice with the help of the organization, who are “helping make developers more productive, reducing cognitive load […], and sharing knowledge more efficiently and effectively.”

Organizations can do this through choosing the right tools for their team — tools that are native sharing tools. Player-coaches and communities of practice rely on sharing, from sharing esoteric knowledge during a lunch and learn to literally sharing a keyboard during pair programming. The more tools the team has that allows them to share knowledge, insight, code, and ideas, the more productive they can be.

The first example might be better documentation tooling. This is exactly the kind of tool that gets forgotten, but is critical to long-term success for a team. They provide paved paths for every developer to follow. These type of tools:

• Allow developers to document their work, making it easier for others to understand and learn from. When knowledge is shared, it creates a culture where everyone can grow and improve.
• Help maintain coding standards, or practices, to ensure that everyone is on the same page. This consistency can lead to a culture of clarity and understanding.

The second example is tooling that lets developers collaborate on projects. A concrete example here would be Telepresence. Typically, it is challenging to develop directly on a remote kubernetes cluster, with most tooling making it nearly impossible for teams to collaborate. With Telepresence, developers can share personal intercept URLs with their team members to show them their code changes interacting with dependencies in the remote cluster in real time.This means that developers no longer need to crowd around a single monitor to see code updates or share feedback. Instead, they can all see the changes being made directly from their respective laptops through the secured intercept URL, leading to faster development cycles, fewer bugs, and a better developer experience.

Both of these tools (Telepresence and documentation) should be available within a developer control plane, offering a single source of truth to give devs everything they need to be successful.–knowledge, tooling, and discovery.

Better collaboration leads to more productivity

Unless you want every developer to be siloed, working only on their own code without the gestalt knowledge of the whole team,

Team collaboration is the path to success. This is how successful developer teams work, by building out the right tooling and the right culture for sharing knowledge. For organizations, this means giving your developers the freedom to organize as needed to learn, and allowing learning to come from anywhere in the organization. The best way to do so is to give them the tooling that reduces their cognitive load and allows for more space for learning–then the pace of production can increase as all your developers become better and better as they learn from each other.