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
Hyper-Growth Done Right - Lessons From the Man Who Scaled Engineering at Dropbox and Facebook
Radical expansion must be in Aditya Agarwal’s genes. When he started as an engineer at Facebook, the company had fewer than 15 people. Within 6 years, he had risen to Director of Product Engineering, leading 2,000 employees to reach 700 million users. In 2012, when Dropbox acquired his startup Cove, the cloud storage incumbent staffed 30 engineers building for 50 million users. Now Agarwal directs an engineering arsenal of 200+ to protect the data of over 200 million people — and he just worked on yesterday's big launch of Carousel. “Most of what I’ve learned in my career has been during a period of hyper growth and change,” Agarwal says. To grow this fast, leaders need to plan day-by-day for the business they want to be in six months — not what they are right now, he says. How do you build an engineering team to constantly rotate and expand? How do you adjust a product strategy when your company transforms weekly, monthly, quarterly? At First Round’s last CTO Summit, Agarwal shared the secrets he’s tapped to keep his team aligned and productive during the fastest of sprints.
Facebook VP of Engineering on Solving Hard Things Early
January 2002. At Linden Lab, we were still referring to Second Life as Linden World, our furnace-less office was near freezing because the space heaters kept popping breakers, the Dot-Bomb crash was in full swing, DEMO 2002 was 4 weeks away, and 10 programmers were trying to duct tape everything together. Little did we know it was never going to get easier to fix the truly hard problems companies face. I talked about this, among other engineering challenges, at First Round Capital's last CTO Summit.
How Modern Marketplaces Like Uber and Airbnb Build Trust to Achieve Liquidity
In 2009, Airbnb was close to going bust with revenue flatlining at $200 a week. Since then, over 9 million people have used it to find temporary housing. Etsy was founded almost a decade ago, but doubled its valuation with its last two rounds of funding. The gradual but ultimately huge success of these entrants to the marketplace space has paved the way for Uber and Lyft’s breakout growth, and the explosion in startups with marketplace models: Postmates, Getaround, Taskrabbit, and more — quickly eclipsing the old guard represented by Craigslist. Marketplace startups are unique because they aren’t just serving one base of customers. They connect buyers and sellers, service providers and consumers. They have to make sure users are having a good experience with each other as well as their company. As head of product for fashion marketplace Threadflip, it's remarkable to me how much of this is based on our ability to inspire and maintain trust. And while "trust" sounds like a subjective term, building it is highly tactical.