What was special about Pivotal?

One of my favorite Presidential facts is that President Benjamin Harrison had a pet possum named "Mr. Reciprocity."

There are a couple of versions of how the President came to have this possum. The most credible is that it was given to President Harris as a gift, to eat, and that it was named by the gift-giver. My favorite is that it was the pet of the President's children, ran around the Whitehouse unmolested, and was named by the President himself, after a key plank on the Republican platform.

I am convinced that the possum bit people.

I imagine the possum scuttling off beneath some bit of overwrought nineteenth century furniture, hissing. I imagine the President asking these poor possum-bitten men what they'd done to set the possum off. "Why," he'd ask, "do you think he's named 'Mr. Reciprocity?'"

I've been thinking about that a lot lately, because I've been thinking about Pivotal, and what made Pivotal Software really special. This week the Pivotal Alumni Slack opened up to anyone who worked at Pivotal prior to the VMware acquisition, so there've been a lot of new folks joining, and a lot of folks talking about oh, yeah, that was a really special place, huh?

If you weren't there, the best way I can describe it is, it was a little bit like being a Starfleet officer. You're on a mission of peace and exploration. Your coworkers all share your values. You're kind and cooperative not because it's "the right thing to do" but because it works. You get shit done, all the time. You're proud of the work you do. You understand that in the past, and in other cultures, people still believe in things like "money" and "war" but you know you've found a better way, and that way lets you run circles around the folks who are still stuck on zero-sum competition.

I'm belaboring the point here because I've found that folks who weren't there basically don't believe me that it was as good as I say. They're very willing to believe that individual Pivots are good engineers, and maybe even that Pivotal had an unusually high number of good engineers. But the usual sentiment is something like, "Wow, Pivotal sounds like a nightmare... everyone I've ever worked with from there has been great though."

The question I'm interested in, though, is why? What was actually different about Pivotal? Why did it feel so good to be there? Why was it special?

For a lot of Pivots it was about the practices. Pairing. Test-driven development. Trunk-based development. Shared code ownership. Priority-ordered backlogs. Retros. Their story is something like, "The CEO was a benevolent dictator who mandated that everyone use these technical and project management practices. These practices work, so that's why Pivotal worked. These practices are hard to maintain, so you need someone at the center dictating them, which is why most places don't work this way."

And I don't disagree exactly. I do think this is part of the explanation, I do think those practices are effective, and I do think that having someone at the center of the company who actually understands them and expects them helps a lot.

But I think it's missing something more important, which is the experience of working at Pivotal, and the expectations that created.

I'm gonna tell you a story. This story is based on a couple of incidents. It didn't actually happen but it's also 100% true.

This story is about "Mike."

Mike comes to Pivotal with a particular set of expectations. He has been in the industry for decades and he has seen some shit. He knows, at this point, how to keep himself out of trouble. He likes Pivotal and he likes his team mates but he's not about to let himself get sucked into caring about work again, oh no.

Mike is on a team that has to take software from other teams and connect it up together. One of these teams is in another office, in another state. They only talk to each other occasionally, on Slack.

One day, this team gets up to some shit. They ship something without realizing that it's going to break Mike's teams software and cause Mike's team to do a bunch of work. Mike ends up in a conversation with someone on this team on Slack, and ends up pretty irritated. This other team doesn't understand what they've done to Mike's team and they don't care. Mike is irritated but, what are you gonna do? This is just how working with other teams is. Everyone cares about their own little corner of the problem. You just deal with it.

Some of Mike's teammates say, "Hang on, no. We should give this person some feedback. We should maybe get on a call with them. We've had friction with this team before but it's really mostly a time zone and office culture thing. They'll want to know how this is impacting us."

Mike is reluctant. He's given feedback before, at other jobs. It doesn't help. All it does is get you more wrapped up in the conflict, maybe even get you a reputation with your manager as a troublemaker. No thank you.

The topic comes up the next day, at a 1:1 with his manager. His managers says, "You really should give the feedback." Mike explains why he doesn't want to. His manager says, "I know, and everything you're saying is absolutely true, but I'm going to ask you to trust me that it'll go differently here."

So– reluctantly– against his better judgement– Mike gives the feedback.

And a strange thing happens.

The person he got into an argument on the other team listens. He gets on a call. He thanks Mike for the feedback. It turns out this person has problems with miscommunications on Slack sometimes and is often frustrated because people don't give him feedback. He really appreciates Mike taking the time to tell him what he did that annoyed him.

The other team fixes the problem. The incident comes up later as an example of Mike's leadership.

This isn't always how it went at Pivotal. But things happened this way enough that it really did change people's expectations about what would happen if they co-operated – in the game theory, Prisoner's Dilemma sense. Pivotal was an environment where you could safely lead with co-operation. Folks very rarely "defected" and screwed you over if you led by trusting them.

People helped each other a lot. They asked for help a lot. We solved a lot of problems much faster than we would have otherwise, because we helped each other so much. We learned much faster because we helped each other so much.

And it was generally worth it to do a lot of things that only really work if everyone's consistent about them. It was worth it to write tests, because everyone did. It was worth it to spend time fixing and removing flakes from tests, because everyone did. It was worth it to give feedback, because people changed their behavior. It was worth it to suggest improvements, because things actually got better.

There was a lot of reciprocity.

But like, the good kind. Not the biting possum kind.

I don't know how Pivotal got this way. A lot of it was how the organization grew, the living system that was Pivotal. "Things are the way they are because they got that way."

Some of it was hiring. Some of it was firing. Some of it was how IT and the administrative functions worked – they reported to R&D, rather than being centrally run and managed primarily on cost.

But a lot of it was this weird, ineffable Pivotness. We had an egregore. It was pretty nice and it liked to get things done.

On hiring–

Pivotal had a very structured interview process. For engineers there were two stages: The technical screen and the full-day pairing interview.

The technical screen was called the RPI, which stands, depend on who you talk to, for either "Remote Pairing Interview" or "Rob's Pairing Interview." It was a scored exercise, it was developed over decades, and it generally took months for new interviewers to be trained to deliver it consistently.

The RPI was designed to look for a handful of things. Ability to understand the difference between test and production code. Ability to explain your thoughts and write code incrementally. Raw input speed. But, also, crucially: Ability to take correction from a pair. You had to be capable of being pleasant and co-operative for at least an hour to pass the RPI. We screened out a lot of folks who thought that being a good engineer meant being capital-R Right all the time with it.

The second stage was the full-day pairing interview. This varied a little bit from office to office and from organization to organization but generally we'd ask you come to a Pivotal office – in 2014 Pivotal flew me across the country and put me up in a hotel for a night to interview me – and pair with one person in the morning and a second in the afternoon. We'd usually pair on a story from an actual working background; sometimes it would be a story that the team had already finished but had identified was a "good interview story." Sometimes it would be actual work that the interviewer hadn't yet done.

There was also a technical evaluation component to that second interview but a huge part of it was just, "Do you, interviewer, want to work more with this person? Do you want them to join your team?" That interview was also an important part of the candidate's ability to evaluate Pivotal. Do they like sitting next to another person and talking all day?

So we hired basically sociable, basically co-operative people. Not always – absolutely not always – but a lot.

Basically what I think is that a lot of companies are just big piles of possums running around and biting each other. Maybe they don't start out that way, but sooner or later they hire a biting possum, and the other possums bite back, and pretty soon whenever a new possum joins holy shit there are all these possums biting me.

If you're lucky, they're smart, motivated possums, and they spend more of their time writing code than biting. Like most possums, they'd rather be writing code than biting people. So they form little cliques to watch each other's backs and talk about which possums are okay to bite and which possums will leave you alone.

But none of these possums can just relax and solve problems. They've gotta be at least a little bit ready to bite, because other possums are out there.

And then you arrive at the island of non-biting possums. It takes you a minute to realize you can calm down – that you don't need to be ready to bite anyone, or defend yourself from getting bitten, or form little cliques and strategize about the other possums over there that you know are planning on biting you, maybe not today, but soon.

And suddenly you can get some real work done.