Pivotal: Why It Works

April 26, 2012 Will Read

My name is Will, I’m 30 years old, and I’m a Pivot. In my three year tenure here at Pivotal Labs, I’ve found that it may be easy to see the parts that make us successful consultants, but that forrest is hard to see for all the trees. Everything from breakfast to keybindings plays a part in making us one of the top software consultancies and the greatest place I have ever worked.

My story starts with breakfast and ends with trust. Each piece plays in to another, and the result is an environment where teams are autonomous, culture and knowledge spread quickly and organically, and communication is never a secondary priority. Our clients see the results in the way which we interact with them to deliver exactly what they need. My coworkers feel it when they realize they control their own destiny and have all the power to make their situation better. You hear it when you listen to pivots like myself or others who appear at conferences across the globe. What we have here is special.

Breakfast – The Most Important Meal of the Day

We have breakfast prepared for us by an outstanding catering staff. It is delicious and you should be jealous if only because it means that there’s one less thing I have to do in the morning. It isn’t just food though, and it isn’t a ploy to eek out more hours from pivots like other companies that might provide dinner in hopes that you don’t leave till midnight. No, breakfast is much deeper than eggs and bacon – it’s a time to cross pollinate, to talk to the pivots who aren’t on your team to share in things both work and non-work related. It also gets us to the office at the same time, which makes it easy to pair together for eight hours, then we all go home together at six, and breakfast leads us right in to our all company standup.

Standup – You’re Not Alone

Yes, the whole body of developers participate in the biggest, most high value standup you’ve ever seen. At pivotal you’re never alone, and company standup is just one of the ways we assure that is always true. When you have hired the best (more on that later), why wouldn’t you want them all to be on every team all the time? Since mitosis of humans hasn’t left science fiction yet, we have to settle for osmosis. We go over who is new or visiting the office, who needs help, and what interesting stuff has come up that might be relevant to other teams. You can read our standup notes right here at pivotallabs.com/blabs. Culture starts here too. Company jokes develop over time as we all gripe about the bumpy release process a particular tool is going through. Company standup also makes it clear that it is okay to not know things. Let me say that again: It is okay to not know something.

Another pivot, Davis Frank, shared an analogy that resonated, but since my Bruce Lee knowledge leaves most wanting, I have adapted it to a much geekier Star Trek take. Being a pivot is akin to being a senior officer on the bridge of the Enterprise. We hire people who will speak up and collaborate, people who will work to make exploration sustainable. We all come to Pivotal Labs with our own expertise like Jordi with his engineering skills, and Beverly the medical doctor, but the very nature of working with startups and our other clients means that we are always going “where no one has gone before” with respect to code, and sometimes the ship’s councilor has to hot wire a tricorder. There is no manual on how to build Twitter or Groupon. Pivotal never gave me the answers to those problems, that’s not how we work. Instead, Pivotal, like Star Fleet, exposed me to a lot of problems all the time and gave me the resources and teams to help me solve them as I encountered them.

Pair Programming – The Trust Builder You’re Already Doing

After company standup and our own team standup, we pair program. That means two people, one computer, all day. It isn’t half as radical as it may seem at first glance. Has anyone at your standups ever asked for help? Did someone then go over and sit with that person at one computer? I suspect they did. Do you do code reviews? Then aren’t you really asking your team to share coding knowledge and culture? Think about it. This is what pairing is all about, we’re just set up to do it a lot more often. And getting back to trust, pairing turns a potentially threatening code review process in to a co-ownership process.

Pairing builds trust in all directions. It builds trust between the pair and the client accepting the user stories because I know that two people have thought about this problem. I also know that any cultural nuances that one pivot has picked up are being shared inline with the other pivot. Pairing builds trust between devs. If you talk about code with someone for eight hours a day you can’t help but understand how he approaches problems. That said, you may not always agree, but at least you understand, and you can have much deeper, more meaningful collaborations when that understanding is in place. Pairing develops trust between the team and the individual because I know that if a feature fails, I am not alone in the failure, and if the feature succeeds, I will have good company to celebrate the success.

Talking about code for an entire work day is hard, I won’t pull any punches there. Think about the last time you were in a long white boarding session. I might have been needed, and possibly energizing, but I bet you also needed to decompress for at least fifteen minutes after. Pairing is like that, so we find other ways to communicate that also happen to feed in to the trust: Test Driving. Write tests first; that way, as your pair, I know what we’re about to work on for the next five to twenty minutes. Writing tests first is a great way to enhance your pair’s understanding of how you’re thinking about a problem and the potential solution. Once you have the test, it has the added benefit of speaking to future devs who might work on this code and communicate what it was meant to do so they can make an informed decision whether you’re available or not. Speaking of which, since we rotate between projects, someone not being there is more than just a possibility, it’s just a matter of time.

Rotate your Pivots Every Six Months or 10,000 Spec Runs

The average pivot is on a project for 3-6 months, some stay longer, some are shorter if their leadership is needed elsewhere, but in general you can count on seeing a good number of projects in three years’ time. On one project you might make a JSON API, and on the next you’re up to your eyeballs in JavaScript, HAML, and CSS. Then it might be off to help a company scale and tune performance. We swap people around and expect them to be adding value on a new project day one. We do that by standardizing on a few things about our workstations. For starters, every computer is basically the same minus the project code itself. Our ops team has done a great job of having an updatable workstation image that is under test so they know when it breaks. After many holy wars, we’ve also come to an arrangement about which IDE and keybindings to use. The choices may not always be “the best” when getting down to specifics, but it is one less hurdle to jump when you find yourself on a new project with new faces, new clients, and new domain – at least your computer feels like the home you just left. It also means I don’t have to think about how to set up a machine when starting a new project, the collective knowledge of Pivotal workstation config is captured in our machine image.

Rotation is a razor sharp double edged sword. Your average dev working for a product company might switch teams once in three years. Meanwhile at Pivotal Labs, I’m seeing new problems and new solutions at a rate 3-6 times that. It means that I can demonstrate loyalty by staying at one company, but the experience of working for ten companies in that same timeframe. Rotation makes our best pivots that much better. The downside of course is that someone who demonstrates loyalty but possesses the experience that is characteristic of a senior pivot soon finds himself being invited to take on lucrative and dazzling roles elsewhere. I can’t begin to explain the sadness and frustration I feel when a pivot leaves the company, but we also can’t afford not to train up our employees. It is the same high quality that makes pivots hirable that brings in the steady stream of clients to Pivotal Labs. If we stunted or slowed that growth any way, it would weaken our offering in a way that would undermine much of what is good about Pivotal Labs.

Hire the Best

We are unwavering when it comes to hiring. When you come in for an interview, you write code on real product because that’s what we’re expecting you to do when you’re here everyday, not solve brain teasers at some white board. We want to know if you can communicate, and we want to know if you can learn and adapt. Pivotal throws pivots in to uncharted waters a lot and we expect pivots to swim. They always do because we hire great swimmers. Hiring great people means we don’t have to spend a lot of time with formal training, or managing, because people are good citizens within the company. Also, hiring great people who raise the average and are put in a place where they pair and rotate means that the average really does go up for everyone. This has an awesome effect on morale, and serves to give us all the confidence that we need to takle new problems. Having the best means that teams can be autonomous and we can trust them to interact directly with the client eight hours a day. We don’t have any need for the “heros” or the “ninjas” who can strap on headphones and have a caffeine-induced flow session. We hire largely for technical aptitude and ability to communicate which is not most developers. When you’ve hired the best for this business, delivering features comes naturally.

Focusing Priorities with Pivotal Tracker

The real magic of Pivotal Labs that you might not notice at first is Pivotal Tracker. It may look like an ordinary project tracking system, but it does two things very well that most software fails to do: 1) Tracker forces clients to prioritize the work we do for them, and 2) it serves as a central communication piece. The former is very important to the success of the project. I’d like to think that because of all the other things we do, we produce more features period, but that’s not the whole picture. Because everything is prioritized, we produce the right features, or at least the features the client wants the most. It is hard for a client to be dissatisfied when we’re always working on the most important thing. We know it is the most important thing because we’ve talked about it. Tracker is the main talking point in our short, weekly meeting so we know that our client wants these features first, we talk about any technical needs we have on our side, and discuss the story details beyond what is typed in Tracker. Remember how I said it all plays in together? Well since we all sit together, and we all trust each other, it greatly reduces the need to spec out every last detail – most of the time we have enough context to make well informed decisions, or we can turn around and ask our client for clarification, or baring that we deliver a story and get some great feedback in the form of a rejected story. At Pivotal, you’d have to work really hard to not deliver what the customer wanted.

Feedback – Always, Everywhere

Being an Agile shop means we’re always gathering feedback and looking for ways to do our job better. Each project is different, so we have regular retrospectives to help us surface and adapt to those differences. This exercise is focused on getting better, and depends on honesty and therefore builds trust in a team. This goes hand-in-hand with hiring the best, because the best speak up and the best aren’t afraid to say something scary or controversial. The best lay their ego aside in order to improve a team, project, or a company. I strongly believe that, if left alone, the right people with retrospectives would arrive at a process that looks a lot like Pivotal Labs does today – in fact I would argue that’s what happened when the idea of Agile was first put to paper by Beck, Fowler and the rest of the Agile work group. Get and give feedback, act on that feedback, that’s the core. Action however, doesn’t always lead to success at first try.

If at First…

In fact, taking action leads to failure a bunch. Since the set of problems, both human and technical is huge and enormously complicated, it is reasonable to assume that most guesses at actions would end in failure. But guess what, we fail, get feedback, take action, and over time, those actions lead to successful actions. Often times the success is very different than it was originally pictured. We also have the benefit of having that experience that can now be applied to a future project. Pivotal Labs is good about making it safe to fail. Read that again, it is safe to fail here. Why? Because we start with the best, then we give them a lot of experience, and we trust them to make the best decision given the information and experience they have. And because we’ve hired for it, teams own their failures, and they’re intrinsically motivated to do better. No one has to sit over their shoulder and tell them it went wrong. They know, and as a matter of pride they’ll fix it. Most importantly, they have the skill set and the resources to fix it.

Greater Than the Sum of its Parts

By now you should be hearing it in your head, that it all feeds in to itself. The whole thing works because it is complete. Each part, start time, pairing, test driving, hiring, clear priorities, and feedback contribute more to the system than just its stand-alone value. The pieces are all obvious, but how they interrelate and build trust across the organization is what makes Pivotal an outstanding company. My name is Will, and this is why I’m a pivot.

If you’re looking for developers, and you want to get the most important things done, I hope you’ll consider becoming one of our clients, we do web and mobile work and you can drop us a line at sales@pivotallabs.com. If this resonated with you and you’re looking for a job as a developer, please send your resume to pivotallabs.com/jobs.

About the Author


Cloud Foundry Roadmap: Below the Water Line
Cloud Foundry Roadmap: Below the Water Line

Earlier this month we moved to a new open source contribution process for Cloud Foundry. As part of the ne...

Cloud Foundry Powers Data Sets for Mumbai
Cloud Foundry Powers Data Sets for Mumbai

This is the third post of a series of guest blogs by application developers. We are featuring a use case by...

SpringOne. Catch all the highlights

Watch now