When I came to Atomic nearly five years ago, I joined the largest development team I had ever known. We had four developers from Atomic and two from the client working directly with us, as well as the client’s QA staff, an operations engineer assigned to our team, and the client’s software architect checking in.
It was an eye-opening experience, especially as up until that point, I’d mostly worked on small teams where everything was owned by a single person, with collaboration only around the edges. Thankfully, Atoms were happy to practice Teach and Learn, helping me see how I could Own It in a space like this.
1. We Own It, Together
On this team, we had a mix of senior and junior Atoms along with the client’s developers, all at various skill levels. In a team shaped like this, the temptation to sink into an “us vs. them” mentality is strong, especially as development styles and practices diverge.
At one point, we found ourselves in our office discussing problems with a recent feature implementation and what we could do to improve it. I was talking through the changes and said, “And here, so-and-so created this problem…”
A senior Atom who had lots of experience on large teams at Atomic and elsewhere suggested a better way to frame the issue. “This isn’t that person’s code—this is our code. We have a problem, and we are going to fix it.”
It’s so easy to don blinders and say, “That’s not my problem”, especially when developers gravitate toward specialization in specific areas or technologies and we feel justified in doing so. But that approach builds animosity and further drives us apart when we should be working together.
The code belongs to all of us, and the responsibility to make it good does, too. When we all own that, the rising tide lifts all boats.
2. We Step Up
Another problem that rears its head all too often, especially when we distribute larger teams instead of colocating everyone, is that nobody really wants to stop what they’re working on to help someone else far away, especially if they feel like it’s not their place.
When we experience a dynamic like this, problems can stagnate, block, and frustrate. People located in one place can resent people elsewhere, feeling like they have somehow not anticipated unspoken needs.
It’s everyone’s job to take care of these kinds of issues. Watch the rest of your team to see if someone’s handling the bulk of the problems, and work to spread that load around. Own the whole project, not just your corner. Actively investigate ways to make sure people have the tools they need to solve those problems in the future.
We also need to communicate that help is happening, using the same communications medium that carried the call for help. If we just turn our attention to something without letting everyone who saw the problem know, we create assumptions. If it’s quiet, team members may assume that either nobody or someone else is working on something, leading to duplication of effort and frustration on the part of the person who had the problem.
If your team assigns someone to delegate, make sure that person is delegating quickly, effectively, and fairly—and especially make sure that they’re not taking everything on themselves. Don’t let them delegate forever, either—spread that responsibility around, too.
3. We Address Issues when We Need To
Sometimes, even when we do our best to make sure that everyone has equal responsibility for a codebase, it becomes evident that some people may need extra help or just aren’t a good fit for the team. No amount of collective owning it can fix this—we need to address this problem with surgical precision.
This is not a job for the entire team. This is a job for someone who is (or possibly a pair of someones who are) calm, collected, and can articulate the problem clearly. Have these conversations in as small a group as possible, bringing in either the person in question (if it’s safe) or someone who is responsible for them.
We Succeed
Owning it on a large distributed team looks different than on a small co-located one. It’s critical to use inclusive language, to communicate, to step up even if it’s outside your comfort zone, and to make sure you’re addressing problems promptly.
By bringing together people who all effectively and collectively own a project, we ensure that we deal with problems efficiently, share knowledge and responsibility, and deliver better software quickly.