8 Surprising Secrets From the DevOps Team Behind Twitter, AirBnB, & Uber

Enjoy greater productivity, better product, and fewer fails.

By Lisa Calhoun

Remember when Twitter used to stall? You knew you were sunk when you got the blue whale of death. 

Jack Dorsey, CEO at Twitter, wanted to slay that fail whale, Paul Reese told me as we toured the Chicago location of Pivotal Labs. “His team at Twitter was busy fighting the front lines, so he took a risk and brought in a small team—us.”  Back then, Pivotal Labs was a small development company in Silicon Valley led by Rob Mee. They re-coded the social behemoth. The whale fail was harpooned.

Impressed, Dorsey took the Pivotal approach and platform to Square. Similar success followed. Since then, Pivotal has been trusted with code work on AirBnB, Uber, and enterprises like GE, Ford, and Home Depot.

How do you do software for Silicon Valley and Wall Street?

The answer is, disruptively. Many of Pivotal’s firmly held practices are in stark contrast to how software development often runs. Changing the culture of development is where they find the wins.

Recently, Pivotal rewired the AllState software experience, and now development processes that used to take 100 business days take minutes. Humana shared a similar experience, as related in the Wall Street Journal.

It’s all about empathy and the pace of disruption, says Paul, who works as an enterprise disruption specialist at Pivotal, based in Atlanta. 

Here’s the Pivotal devops playbook:

Hire for empathy.

Yes, Pivotal hires developers for emotional character first. Paul is crystal clear that, “the number one trait we look for when we’re hiring developers is empathy. Two people paired, working on one line of code, code faster than 3.3 people working alone.  With far fewer errors.” 

Pivotal also has a strong preference for diversity—part of the commitment to empathy and communication skills. When I walked through the Pivotal Lab’s Chicago office at 1871, there was a refreshing mix of race and gender at work.

Behavior test job applicants (instead of skill test). 

Paul says, “We’re not looking for the lone eagle or the rockstar.”

Pivotal pairs a potential new developer with one of their developers for an hour working in a software language that isn’t on the applicant’s resume. They look at how the applicant handles learning, lack of fluency, lack of control, and challenge.  

Hiring for adaptive intelligence and verbal communication abilities, not hard skills in a specific language or coding environment, keeps teams learning and engaged. Paul says their coding teams have 80% fewer errors than industry norms.

Work on 2% improvement cycles per week.

Legacy development cycles use a product road map that executes episodically—say quarterly or every six months. These kinds of cycles show 10-25% improvement on the code per cycle, often fixing bugs along the way.

“For too long, our industry has been satisfied with this kind of growth pattern—but it’s not fast enough to build a market leader,” says Paul. Pivotal works on a 2% per week continuous improvement approach.

Check out what episodic vs. continuous looks like when you graph it side by side:

Pivotal slide_32409

Hear the roar.

When you spend time in a Pivotal Labs environment, there’s a hum. Each developer is paired with another developer, working on the same computer and looking at the same screen. They are not “heads down, head phones on.” Paul credits the team approach with not only de-risking the product by sharing the context of the code, but also with improving product development from episodic to continuous.

Enjoy small doses of daily risk.

For your executives leading the product’s development, Paul recommends transitioning from over-analyzing risk to taking a small daily dose of it—in line with a commitment to 2% weekly improvement.

Kill the project mentality model.

For product managers, Paul says Pivotal teaches companies to focus on the business product being created, and they learn to focus on the product management by metrics or analytics instead of relying on a “project by project” delivery model.

Write the test before you take it.

Known as Test Driven Development, Pivotal requires that tests are written before functioning code, focusing on the user experience rather than specs or requirements.   If code passes the test, it’s ready to go live. Usually that day. So each service, each call, each tidbit of code gets its own meticulously written test—first.

Get the best data science you can afford.

“We identify data sources, look for new ones, and ask ourselves how to operationalize it. Too much data science dies on a slide deck,” says Paul. He says the biggest failure he sees around data is quitting the hunt for new sources too soon.

Faster, smarter

“We recently did a transformation project for Warner Bros. which was already an accomplished app dev shop already before trying our approach. With our approach, they saw $1.1M hard cost savings per app. And their development cycle for a new app went from from six months to six weeks,” Paul shared.

While Pivotal, with some 2,000 developers on the team, is a market leader in the extreme/paired coding model, they are by no means the only one. In Atlanta where I live, for example, minimum viable product development experts like Geoff Wilson’s 352 and boutique shops like Toolbox 9 use many of the same approaches and see similar results.

What’s interesting to me is, as “software eats the world,” many companies are pivoting to a tech-driven, data-enabled model. As software development commoditizes, new approaches that build community, service, and consensus like Pivotal’s are coming to the fore. 

This article first appeared in Inc.com


In this article