Managing at Light Speed: What I Learned Along the Way
I started working for Pivotal Labs as a developer in 2009. In 2012 I moved to our Cloud Foundry team just as it was outgrowing its status as a science project. The following year, I took on the role of Director of Engineering on Cloud Foundry, along with two other colleagues (David Stevenson and Elisabeth Hendrickson, both amazing coworkers I’m grateful to have gone on this journey with).
The changes and growth we’ve experienced, from both a business and a team aspect have been remarkable. Here are some things I’ve learned that I wish I’d known then, as I went from managing the code to managing a team that manages the code.
Chaos
Chaos is a necessary component of growing a team as fast as possible. The goal has to be to keep this chaos at a manageable level. It shouldn’t be to eliminate it. I think of this as an internal combustion engine. Small contained explosions keep everything moving and going in the right direction.
APIs
When we want to go faster, we add developers to teams. When a team is small, we see a near-linear increase in productivity for a team with new each developer. When the team gets above a certain size (usually around eight or ten staff), adding developers no longer has the same impact. Having observed this many times, we now look for seams where we can divide a team into two halves. The best divisions are where clear APIs exist between two components, and the worst are where two separate concerns are entangled in the same codebase. In the beginning, we stumbled onto APIs. Now we look for places to insert a clean API, as a mechanism to grow our teams in the future.
Continuous Integration
The Cloud Foundry team has invested countless hours in continuous integration, and we actually spend more time building out CI now, not less. This is only because it has become more central to simplifying our process. Concourse is our 3rd-generation CI system for Cloud Foundry, and this time we built it ourselves because we’d tried everything else out there, and knew we could do better.
Thanks to CI we now have the ability to ship an upgrade to any piece of code, or to package it into software in 48 hours, with the confidence that all tests pass, and that new releases will install cleanly on every infrastructure we support. Even more impressive, is how it upgrades cleanly from any supported previous release. This is great as a development tool, but it’s also a huge feature for a customers who count on us to keep them patched and up to date.
It’s a Marathon, not a Sprint
Every day can feel like a sprint, but the key to success is going faster in a sustainable way. On every occasion where we’ve prioritized ‘getting things done’ in the short run with the idea of cleaning them up later, it’s taken far more effort than expected. Doing things sustainably doesn’t mean doing things perfectly, but you have to have a plan for the next year or two as well as for the next week.
Our team will continue to learn, and stumble here and there. But the above practices have proven to be good bedrock upon which our team scales and thrives in the new code cycle.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced and incorporated continuously through development and innovation, because good software is never finished.
