How team assignment worked at Pivotal (at least on Cloud Foundry)

I've been working on updating that Management at Pivotal post and realized that one of the things that I want to include – or at least be able to reference – is a description of "allocations," Pivotal's system for assigning engineers at teams. Pivotal's unusual approach to management was partly a response to its even more unusual approach to team assignment – the basics of this system predates Pivotal Labs having managers at all – so I don't think it's possible to make sense of management without talking about team assignment.

How unusual was this approach to team assignment? I worked at Pivotal for five years. In that time I was on between eight and ten teams, depending on how exactly you define a team. (A few of these assignments were 1-pair or temporary teams.) This was a relatively high number for a Cloud Foundry Pivot but a relatively low number for a Labs Pivot.

(I'm going to focus on describing the Cloud Foundry because I think it's weirder relative to similar engineering organizations, but even Labs was extreme for a consultancy – at one point Labs Pivots changed team assignments daily.)

A typical tenure at Cloud Foundry was eighteen months. It was rare for an engineer to stay on a single team for longer than two or three years. A few people left Pivotal specifically because they wanted to be able to continue to work on a specific technical area, and if they stayed at Pivotal they were going to be moved off of the only team that worked in that area.

Switching teams was called "rotating" and a period of time on a team was called a "rotation." On your typical two-and-a-half to three-pair team, at any given time one person on the team had probably joined in the last month or two.

This was less chaotic than it sounds like. Remember that we paired a lot – so on your first day you'd be joining a pair on a story in flight. And because we rotated so much, teams were standardized. When you "rolled onto" a new team, you could expect to find

• An onboarding checklist to get you all the accounts you needed
• A backlog in Pivotal Tracker
• A team-managed workstation built from a base image and a provisioning script
• A "boxes and lines" introduction to the team's architecture
• A well-tested codebase that was probably organized in a way you recognized, with scripts for tasks like build and test
• A CI system and other tooling using common technology that you were already familiar with

We treated team rotation as an "if it's hard, do it more" problem, like integration testing and refactoring. Every time a new person joined the team it was an opportunity to update our onboarding checklist. Team rotation was also the main force that standardized our tooling. Pivots would bring ideas and tools that had worked well on other teams to the next team they joined.

As a line engineer being allocated, the process typically looked something like this:

During 1:1s with your manager, you spend some of your time talking about how things were going on your current team, where you might want to go next, and how soon you might want to rotate. Were you still actively ramping up? Effectively contributing? Starting to get bored?

Then one day your manager would come and tell you that you were going to a new team – usually in a few weeks, but sometimes much sooner than that. On more than one occasion I saw a final allocation decision get made on Thursday afternoon before the rotation happened the following Monday. Friday allocation decisions were rare but they did happen.

On the Monday that you joined the new team, you'd attend "Big Standup" for the whole office, and then join your new team's standup and sit down to start working with them. You'd probably spend the first hour or two working through the onboarding checklist with your pair, and then work on a story with them through their accounts while you waited for e.g. your Github account to be added to the team repos.

Crucially: You would keep your manager. This is one of the main reasons that managers weren't associated with teams – so they could stay consistent through team allocations.

On the "backend" – managers and Directors figuring out who goes on what team – things were more complicated. The process changed over time and varied between offices, but at a high level it looked something like this:

Once a week, the office's Director(s) and managers would meet and go through a list of all the upcoming team moves that they needed to happen. The process was usually driven by "hard" team moves that were tracked on a calendar, including:

• An engineer is leaving the allocations pool (changing offices, leaving the company, going on leave) on a future date, so their team needs a backfill on that date
• A team is below its assigned headcount (either because it unexpectedly lost an engineer, or because its headcount increased) and needs a backfill ASAP
• A new engineer is joining the pool (coming from another office, joining the company, returning from leave) on a future date, and they need a team assignment

But team assignment changes could also be triggered by things like:

• A team needs a particular skillset that they don't currently have
• An engineer has been on the team for a long time, or has asked specifically to be moved

Each team had a headcount allocated to it, and an Engineering Lead and a Product Lead who were responsible for making it was staffed correctly – with the right mix of seniority and skills. Managers generally didn't move one person at a time and leave a hole behind – it was more common for a two way or three way swap. Sometimes you'd get a large multi-person chain that was unlocked by a new engineer joining the office, like this 1-way kidney donations that unlock a dozen reciprocal donations.

In smaller offices, the Engineering Lead was the same for all the teams – the office's Engineering Director – and there were only a handful of managers, so it was possible to work out all the details in the meeting.

In San Francisco circa 2018, the "allocations pool" included three offices (SF, Seattle, and Santa Monica), something like half a dozen different Engineering Leads, and several Product Directors. In the "West Coast Allocations" meeting instead what usually happened is that a change would be proposed in a meeting and then folks would go out and get sign-offs from all the relevant stakeholders for a particular change. This was one of the reasons that changes sometimes got made suddenly and at the last minute from the perspective of individual engineers – sometimes you rotating was an attempt to rescue a three-way swap that had been in the works for weeks but had lost one of its legs at the last minute.

"Finalizing" a change might also require "selling" the engineer being moved a bit on the new team, especially if it was one of the less, well, "cool" teams. (I picked up a bit of a side gig building pipeline for a few teams that I thought were important but unpopular – the Release Integration and Release Engineering teams – by identifying people I thought would be good fits and selling them on the idea long before the team needed them. i.e. "If you really want to master Concourse you should go to RelEng, they have some massive pipelines.")

This was largely a pull system. A team would have a need, and that would trigger a series of other changes to make that change possible. There was a little bit of a "push" aspect in that sometimes engineers would want to move to specific teams but this rarely dominated.

This was expensive. It took a lot of time and effort from managers and directors. It was weird. It constrained who we could hire and who we could retain. It imposed a lot of constraints on other parts of our organizational design.

Was it worth it? I think so!

I really liked rotating, and rotating frequently. I got to see knew things, and work on lots of different technology without changing jobs. It's one of the things I miss most about Pivotal.

The system also meant that we never had to reorg, because we were always re-orging. When the organization needed to start a new team, split up a team, or combine a team, it wasn't dramatic or traumatic – it was just another team allocation change.

I think it's also an underrated reason for why Pivots were and are so damn fast. Every time you joined a new team you'd pick up all the command-line and IDE tricks that everyone on the team knew – and then take them with you to teach to everyone on your next team. So anything that was easy to teach via pairing spread rapidly through the organization.

There was also this subtler effect where – all this rotation and pairing bound the whole organization together into a "six degrees of Kevin Bacon"-like web of people who had paired together. For any given component your team's component depended on, there was probably someone on your team who used to work on it – or had paired with someone who was now on it. There was a lot less of the "those people over on that team are just strange" thing that I've seen happen at other companies. While this did still happen at Pivotal, when it did there was a straightforward solution: Swap two people between the teams!

This is another one where I'd like to ask – what's wrong with this picture? What's missing? Got any especially good allocations stories? It's been a few years and I'm working mostly from memory, so I'm sure I'm missing some important pieces.

Thanks

Nat