Accountability Among Peers Is What Makes Great Development Teams
How to spot a culture of accountability, what makes it work, and how not to muck with it if you have it
I don’t want to overcomplicate things, so let’s ease in with some astrophysics.
A two-body problem in physics describes the motion of two massive objects in space interacting with each other (and only with each other) - two stars orbiting each other, for example. If there are no other objects or forces in play, the math needed to describe the interactions of two bodies is straightforward for physicists. Add a third star to that system however, let alone trillions of them, and the math gets so complicated that interactions can only be approximated, not solved.
I liken that exponential jump in complexity to the challenges of building an high-performing team. Hiring a single great employee requires lots of things to break in your favor, as any experienced hiring manager knows. You have to find someone with the right skills and experience whose personality fits your culture at a time when they’re willing to making a move and for a pay package that fits your budget. Doing it once is hard. Doing it multiple times is harder still.
But assembling a team of great individuals who are even more effective as a unit? That’s exponentially more difficult. It’s so uncommon that the teams that pull it off can become legendary: Think of Oppenheimer’s Manhattan Project team, IBM’s famous QA Black Team of the 1960s, the PayPal Mafia, Disney’s Nine Old Men…and, obviously, the ’92 Dream Team.
What is it about these teams that makes them so formiddable, even unstoppable? In a nutshell, it’s when the usual ingredients - talent, maturity, chemistry, etc. - are operating within a culture of accountability among peers.
What Does a Culture of Accountability Look Like?
Here are some of the tell-tale signs that a team has developed a strong culture of accountability:
Team members demand commitments from each other about what they’re going to deliver within a set timeframe
Everyone trusts each other to keep the commitments they’ve made — they’re not viewed as stretch goals
Team members are comfortable pushing and challenging each other
The team takes pride in their reputation for getting things done, and they’re protective of it
Team members are even more motivated by their peers’ expectations as their bosses’
Shared ownership of results makes team members glad to help one another (as long as the recipient isn’t chronically unreliable)
What’s key, and what makes teams like this so special, is peers holding each other accountable.
The most enjoyable development team I’ve ever worked with also had the most impressive culture of accountability I’ve encountered in my career. At the start of every sprint, I sat with the team for story grooming and pointing. As stories were assigned to owners, the team’s manager would get each team member to commit to what they’d deliver by the end of the sprint. If he thought someone could do more, he’d push them on their reasoning. If he thought they were being too ambitious, he’d do the same. His goal was committing to the maximum velocity his team could realistically deliver without burning them out, and he was good at it.
There’s a military saying that the true test of your leadership is how your unit performs without you. This team had a strong manager in charge, but even more important to their success was the way peers pushed each other. The team members often wagered a number of push-ups or paying for others’ lunch if they could/couldn’t complete something. Rather than being a source of stress, making and keeping commitments was a source of pride.
(If that sounds like typical bro-culture stuff, I’ll note that this team was far from all-male, that the female engineers were enthusiastic wagerers of push-ups, and that as a group the women had better push-up form.)
That competitiveness and accountability didn’t get the way of collegiality either - quite the opposite. There were a lot of close friendships among that team. Most of them regularly hung out with their team members outside of work. Many of them even took weekend trips with each other to see concerts or go camping, which is what made their culture all the more: It’s not unusual for colleagues to become close friends, but it is unusual in my experience is for close friends to still challenge each other as effectively as this group did.
“Friendships founded on business are superior to businesses founded on friendship.”
- Henry Flagler, Standard Oil Company Co-founder
Finally, while I don’t celebrate an employee not working out for whatever reason, the first time I observed someone getting fired from this team cemented my appreciation for the culture they’d built.
One of the engineers on the team had a track record of not delivering on their commitments. Over time this person proved to be a consistent drag on other team members’ time. They gave this engineer several chances to improve and helped as much they could, but when things didn’t get better they didn’t hesitate to let the person go. It was the manager’s decision, but the team’s feedback and assessment made it a no-brainer.
I was sorry things didn’t work out for the employee, a perfectly nice person, but I respected how protective the team was of their culture. And I was impressed by how the strength of the team’s “immune system” prevented them from letting their standards slip.
Managers are expected to get the best out of their teams and hold their direct reports accountable, even when that requires difficult conversations. For peers to do the same with each other takes more individual courage, but its also requires a level of chemistry and respect amongst the team to keep things light and avoid unbearable tension.
“[I]magine yourself delivering a tough performance review to your friend. Do you cringe at the thought? If so, don’t make friends at work. If your stomach remains unaffected, you are likely to be someone whose personal relationships will strengthen work relationships.”
- Andy Grove, former CEO of Intel
Lots of teams can have fun together at happy hour. Fewer teams still enjoy each other’s company afer demanding the best from each other month after month.
When You See It, Don’t Mess with It
Working with a development team like this is a blessing for lots of obvious reasons. They’re self-motivated and don’t need you or anyone else coming in to crack the whip. You’ll insult their sense of pride and integrity if you try to, so don’t - and don’t let anyone else.
I remember while I was working with this team, one of our executives was peeved that the estimated development timeline for a milestone release meant it wouldn’t be delivered before the end of the fiscal year. He wanted me to put the hammer down on them and demand delivery before the end of Q4. I knew we’d done all the scope management and phasing delivery we could, and more importantly I knew that the team’s estimates weren’t padded and that they wanted to meet the business’s goals. If they said it wasn’t possible, I knew it wasn’t. This executive was a classic driver who prided himself on his ability to push teams hard, and I practically begged him not to. There was no point in taking that tack with this team, I warned. Don’t mess with what we have with this group by telling them you don’t think they’re working hard enough.
It’s also important to recognize that the source of the development team’s motivation may be different than yours as an executive or product leader. In their classic book on software development management Peopleware, authors Tom DeMarco and Timothy Lister share a story about that illustrates how easy it is to de-motivate a jelled and motivated team despite your best intentions as a manager. This unnamed manager’s anecdote carries an important enough lesson that it’s worth directly quoting at length:
I once ran a telecommunications project for a large consumer finance company…Increasingly, the company’s already huge profit was not something the average worker could easily identify with but management seemed to think it was. A management delegation came to talk with me one Friday afternoon. The company’s chances for the best second quarter in history were in our hands, they said. They asked me to share this fact with the rest of the team, “to focus their efforts.”
I had never worked on a more focused team in my life, but I dutifully passed the word on the next morning. (They were so fired up that the whole team was in, even though it was a Saturday). The energy went out of the team like wind out of a sail. The chief programmer summed it all up, “Who gives a rat’s ass about their second quarter?” Half an hour later, they’d all gone home.
It’s not that you shouldn’t explain the business rationale and opportunity behind your product initiatives — you should. What you shouldn’t do is assume that’s their motivation for doing good work. When the team is already sufficiently focused on meeting a goal and motivated by pleasure of meeting a goal together, trying to replace that motivation or augment it by stressing the company’s business interests won’t help, There’s nothing more discouraging to an employee then the sense that their own motivation is inadequate.
Having a team with a strong culture of accountabiliy at your disposal is like having a Ferrari in your garage. You’re more likely to screw something up than make it better if you start tinkering around the edges. Just focus on driving the car well. If you’re in Product or Design, that means doing everything in your power to ensure they’re building valuable things that are going to be used. Hold yourself to the same rigor of making and meeting commitments that they do.
Some good ideas here! I added a link from my related post on setting OKRs.
https://buildtoscale.substack.com/p/setting-and-measuring-objectives