Why Every Startup Should Pair Program
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.
Read These Next
Top Hacks from a PM Behind Two of Tech's Hottest Products
Todd Jackson was in a small conference room with a handful of designers, engineers and Mark Zuckerberg. The topic at hand: the Facebook News Feed redesign, intended to declutter the Facebook experience and make it even more engaging. They went over the latest mockups, discussing photo sizes, text density, and the redesigned website navigation. Then they honed in on one seemingly minor point: turning people’s names from blue to black. Jackson, the product manager in the room, knew this was more complicated than one might think. In fact, Zuckerberg had a simple philosophical stance on the matter — that people’s names should remain bold and blue because people are at the center of Facebook. The people are what all the content pivots around, and they should stand out, he said. Jackson’s team had a different contention: in order to more deeply engage its audience, Facebook needed to evolve to showcase content first. In this conversation, Jackson had to wear multiple hats. He needed to absorb Zuckerberg’s argument. He needed to advocate for his designers and engineers. And he needed to think through all of the other pieces and people these changes might touch: internal user operations, external news publishers — not to mention the site’s users. This usually boils down to two sides of the same fence: founders or executives pushing for product changes, and the engineers and designers trying to build them. Such is the plight of the product manager. And Jackson knows better than most. As a PM on Gmail during his time at Google, and on News Feed at Facebook — and now as the CEO of his own, newly-launched Android startup, Cover — he’s worked through tough problems with some of tech’s luminaries. If anyone knows how to balance multiple interests, it’s him.
What You Want in a VP Eng from the Recruiters Behind Twitter and Zappos
Years ago, real estate success story and $1.4 billion company Trulia was in its infancy and on the hunt for a VP of Engineering that would take the site to the next level. It wasn’t going to be easy. The initial team was a close-knit group of hardcore developers led by a pair of seasoned founders, and they weren’t going to let just anyone lead the technology organization.