Management at Pivotal

Hey there! I'm Nat Bennett, and you're reading Simpler Machines, a weekly-ish newsletter about software development.

We had a conversation on the Pivotal Alumni Slack recently about how there isn't a good writeup of the Pivotal management system, which was weird and has been on my list of things to write about for a while. So– I took a whack at it.

This is very much a first draft, so I'm extra interested in your thoughts. Is this accurate? Is anything missing?

It's your first day at the Pivotal office in San Francisco, sometime in the summer of 2015. You meet your manager at 875 Howard Street at 8:45. You have breakfast (your first Pivotal breakfast!) and then he takes you to "Big Standup" where he introduces you to the rest of the office. After standup, he takes you to your team, tells you he'll meet you again at lunchtime, and leaves to go back to his team.

Wait– Your manager isn't on your team?

It gets weirder: Not only is your manager on a different team, back on his team he's just a regular engineer, pairing in with the other engineers. He's probably not even that team's lead.

Pivotal did a lot of things differently, but it did management really differently. Let's break it down.

(Note: This article describes a somewhat abstract version of the system. It applies best to the Pivotal Cloud Foundry teams in San Francisco, and best to the years between 2014 and 2018. It applies reasonably well to Pivotal Labs, and to other Cloud Foundry teams during the entire existence of Pivotal and for about a year after the VMware acquisition. It somewhat describes the teams working on Greenplum and the Pivotal Kubernetes Service. It doesn't apply at all to teams working on Spring.)

What a manager did

If you were a manager at Pivotal Cloud Foundry you'd typically have about 8 reports, and you were expected to spend about 20% of your time on management responsibilities.

Meet with your reports regularly for coaching and career planning
Represent your reports in team allocations and performance evaluations
Engage with HR on behalf of your reports
Represent "leadership" as a senior engineer

The other 80% of your time was pairing on a backlog, like any other engineer.

Who did all the other manager stuff

Processes and Peers

A lot of the day-to-day things that managers do at other companies, teams handled collectively.

For example: How do you decide what to work on without your manager telling you what to do? Easy! You pick up the first story on top of the backlog.

"The backlog" is a priority-ordered list of stories (tickets, if you must) that are ready for a pair to pick up and work on. That's Extreme Programming, baby!

Pivotal engineers worked in pairs most of the time. Need feedback on how to grow your technical skills? Ask your pair!

Anchors and Product Managers

"But Nat," you might reasonably ask, "Without a manager, how did that backlog get there in the first place?" And the answer to that is: Mostly the product manager, with help from an experienced engineer called the team's anchor.

A big part of the product manager's job is to keep at least a few weeks worth of stories ("runway") in the backlog at all times. They're also (unlike at many companies) responsible for breaking large features down into actionable pieces – what Pivotal and organizations like it call "thin vertical slices." They often get help from an engineer to "slice" stories, and to ensure that the stories are ready to be "IPM'd."

"IPM" stands for "iteration planning meeting" and what happens in IPM ~stays in IPM~ is outside the scope of this post, but it's a meeting with all the engineers on the team, and it's where stories go from "finished by the PM" to "actually ready for a pair to start working on them."

Directors (and Engineering Leads)

This doesn't cover everything that managers do at other companies. Team staffing. Performance reviews. Technical input on long range roadmaps.

Those responsibilities were mainly handled by Engineering Directors – managers of managers – and, later, Engineering Leads. Typically a team had a single Engineering Director or Engineering Lead assigned to it. (This role changed substantially over time, and was probably the least-defined management role at Pivotal.)

Why was management structured this way?

This structure was weird and it had ongoing costs. It was hard for Pivotal Cloud Foundry to hire managers, and to retain people who wanted to primarily focus on management. I think there were three basic reasons the company retained this structure until after the acquisition.

Pivotal's history as a consultancy
Allocations flexibility
Better experience for individual engineers

This system grew out of management for consultants. Consultants are inherently allocated to many different teams in a relatively short period of time. Managers for a consultancy structured like Labs can't associate managers with long-lived teams. Consultancies also have a lot of direct pressure to reduce non-billable hours as much as possible, especially for expensive specialists like "experienced engineers." But Labs still needed mentors to help develop new consultants -- so you see this very mentorship-focused management system develop.

Cloud Foundry retained this system in part because management chose to allocate engineers to teams temporarily. A typical "rotation" on a team was about 18 months, but a normal rotation could be anywhere from six months to several years. (Occasionally a rotation could be just a few months, or even a few weeks -- usually this was because an engineer was unexpectedly needed on another team.)

Through this all, you'd keep the same manager-- your consistent mentor and interface with HR. A full account of the benefits and drawbacks of this system is outside the scope of this article, but among other things, it made reorganizations much less traumatic than they are at most companies -- in fact, we did small ones so often that we didn't really recognize them as reorganizations.

While there were exceptions, in general, individual engineers really liked management at Pivotal. Your manager was usually another hands-on engineer, who didn't have many responsibilities beyond working stories off of their own backlog, and mentoring you – it was rare for managers to have leadership responsibilities on their own assigned team. There was also less tension between "manager's own outcomes" and "report's outcomes" – managers didn't have incentives to e.g. block your promotion to a leadership role because they needed your contributions on their team.

If my manager's not on my team, how do they know what I do?

The most common concern I hear from people about Pivotal-style management is whether performance evaluation could possibly work in this system. You often only talk to your manager for two hours a week, and they don't have detailed knowledge of your team's responsibilities. How can a manager who's so disconnected from your day-to-day effectively evaluate your performance?

The full answer to "how did performance management work at Pivotal" is way outside the scope of this article, but the short answer is: They talked to your pairs, and especially to your anchor. Remember that Pivotal engineers almost never worked alone – you wrote basically all production code in a pair. So the quality of your work was unusually visible to your peers.

Lots more to cover on this topic but that's all I've got for now. Let me know if there's more information like this that would be useful to have a link to – the Pivotal write ups aren't my main focus at the moment but sometimes the right prompt like this can pop me into the "1500 words in an afternoon" zone.

- Nat