If there’s a company out there that knows “software development,” it’s Pivotal Labs. Edward Hieatt and his colleagues at Pivotal come from the agile school of development, and in their client work have noticed many startups begin to experience an erosion of their development culture as they grow in size.
Most of the over 100 companies Pivotal works with every year come to them because they think they just need more development support to ship faster or manage their growth. But more often than not, Hieatt believes the problem is actually related to the broader issue of development culture. In particular, for early-stage VC-backed founders, the growing pains affect the culture of software development to the point where shipping schedules and innovation are materially impacted — almost bringing companies to a halt.
The solution, which Hieatt put forward at the First Round Capital CTO Summit, is bold: A culture built completely around pair programming.
Usually, when engineers talk about the benefits of pairing, they typically think of writing code faster or better, but Hieatt actually believes it's one of the keys to great culture. Additionally, the concept of pairing evokes a range of emotions and counters conventional wisdom about how teams form and work today.
For instance, today’s culture within early-stage teams often allows developers to work in autonomous silos, or to work in sprints, to make their own hours, and a host of other norms, which stifles software development culture. In addition, engineering leaders are worried that pairing will actually slow the team and reduce developer output, or at the very least, bother their engineers who are used to sitting alone and coding by themselves all day.
Defining Strong Software Culture
Ask most founders and engineers what a strong engineering culture is and their answers invariably revolve around tools, hiring processes, technical choices, strong coding and review standards, exceptional team leads, and so forth. In Hieatt’s eyes, however, these are not elements that define a strong culture.
Software development culture is really about a set of behaviors and interactions — how decisions are made, who is involved, and which decisions enforce accountability on the business side of the operation.
It is the ultimate manifestation of a company’s day-to-day culture and teamwork.
Teamwork is Undefined in Our Industry
For companies to build and maintain a durable software development culture, we must first define what “teamwork” means. In the eyes of Hieatt, “teamwork” as a concept in software development is decades behind despite all the platitudes surrounding team culture.
The reality is that in the world of software and startups the rockstar mentality is still rewarded and encouraged — where folks work all night, and contributions are not balanced across teams. Furthermore, technical startups are generally afraid of management and imposing structures on teams too early, even if teams aren’t working well together to ship things on time. To consider pair programming, then, one needs to also first rethink what teamwork means for their company.
Why Consider Pairing?
Software development is really about people and is a social activity. Because of this, the concept of pairing becomes the core unit of teamwork to build a software development culture upon, and provides infinite benefits when teams start to scale quickly. At Pivotal Labs, for instance, engineers are pair programming all day, every day.
The benefits of pair programming accrue:
- Engineers leverage shared knowledge of the codebase and have better discipline, communication and performance since they are accountable to a colleague.
- It makes new-employee onboarding significantly easier, makes feedback loops become quicker and it allows for cross-pollination within larger organizations that have disparate teams.
Here, pairing is the key culture builder.
How to Implement Pairing
Often, engineering leaders think there will be massive resistance in their organization when there is a shift to pair programing — but most of the time, if it's implemented correctly, it's actually embraced.
Those who do resist often do so out of fear that they're going to get shown up or a fear of having to talk with someone throughout the day, every day. But, if you make engineers realize it's really just geeking out together, they often start to come around to it rather quickly.
When your company is ready to jump to pair programming, here are tactical tips from Hieatt on implementation:
- Teams should be physically together and keep common hours.
- Machines should be communal, not assigned to individuals.
- Pairs should rotate daily (mixing up pairing equalizes across teams).
- The company should give autonomy at the “pair level,” not the individual level, which gives the team overall more power over time.
- Get buy-in from management for a pair programming approach.
- Institute regular check-ins for feedback loops to make sure the approach is working.
- In cases where the team isn’t sure of committing to pairing, start within a smaller team first and then go all-in if it feels right.
- Set the teams for the next day the night before so teams show up on time.
Possible Outcomes of Pairing
Once pair programming is in place at a company, Hieatt notes that feedback is usually improved significantly, and the feedback becomes even more accurate because the number of data points is increased as a result of more frequent interactions across all team members. Committing to pairing is certainly not a trivial decision. It takes time to adjust, but Hieatt believes that the change is worth it and might just be the key to a true engineering culture of teamwork.