"Do what works" was the hard part
Man ya'll sure like it when I write about possums. Picked up six new subscribers next week and got a lot of positive feedback, which I'm real happy about. I saw someone comment in a conversation about work that "it sounds like you work with biting possums" and I am very pleased to have been able to contribute that to the discourse.
(I think humor – lightness – is really important. I think it makes it much easier to be gentle, and to handle difficult situations with difficult people, to be bring a little bit of ridiculousness to the conversation.)
I'm Nat Bennett, and I make dubious metaphors, often about animals. You're reading Simpler Machines, which this week is also going to be about Pivotal.
Pivotal had three "corporate values":
- Do what works
- Do what's right
- Be kind
And there's this tendency amongst some of us who really liked Pivotal to think that "be kind" was the important one – the hard one, the unusual one, the one that really made Pivotal different from most companies.
And, I mean, I don't disagree with that, exactly. I just wrote 2,000 words calling the company "the island of non-biting possums."
But having seen what came after Pivotal, having worked at a few other places since, and having talked to a lot of people during and after Pivotal about it and paid attention to the people who got serious zeal-of-the-converted about Pivotal after careers at "normal" tech companies – I think what was weird about Pivotal was how the environment fused "do what works" with "be kind."
And, moreover, I think that getting "do what works" is maybe even harder for a culture to maintain than "be kind."
There are lots of companies out there that are basically pretty nice – but ineffectual. Where tech debt stays tech-debt-y, where centralized IT and facilities organizations routinely deliver systems that don't work, where teams work for years on projects that never ship.
And there are plenty of companies out there that "get shit done" but have pretty nasty cultures, because they hire people who are smart and ambitious and motivated and don't care very much about how they treat other people. Or– and I think this is more common than people who are straight up psychopaths– wish they could be nicer and kinder but think there's a tradeoff between "people's feelings" and "getting shit done" and have chosen the latter.
It's that latter kind of person who I saw a couple of times go just nuts for Pivotal. Suddenly they're surrounded by people who are actually on their level and are nice. They're getting shit done but they're actually able to relax, too. And– even better– they're realize that the kindness-cooperation-together mode is better in a lot of ways than the ruthless-brilliant-loner mode. Like a multicellular organism, it requires a lot of infrastructure, its vulnerable to new diseases, and it doesn't entirely outcompete the solo-flyers but oh, the new capabilities.
Out in the "normal" tech world – startup/VC land – I think this tends to get framed as "big companies versus small companies." Small companies are lean and nimble and ship. Big companies get bogged down in process and navel-gazing, get distracted from their customers and competitors by internal status competition.
And the size difference is definitely a factor, but I've seen tiny companies that were much worse at shipping than Pivotal at its largest. Pivots – and people of a Pivot-ish persuasion – register weirdly in this world-view, because we're team-oriented, process-loving creatures, but we also relentlessly get shit done.
I mentioned the interview process last week – the RPI and the half-day pairing interview, and how they tended to select folks who were basically pleasant to be around. The other big thing they selected for was speed. The interview on some level was, "Here are some normal, borderline-boring software engineering tasks. Can you get them done a little bit faster than average?"
A thing that almost everyone is surprised by when the leave Pivotal is how much time software developers at most companies spend not writing code.
Some of it is stuff that's necessary, that Pivotal teams tended to underinvest in. I occasionally refer to "the Pivotal Labs magic trick" because Pivotal Labs engagements could produce shocking amounts of working software in a given length of time, and some of that was due to good practices, but some of it was Labs projects tended to cut a bunch of long-term necessary regenerative processes out of teams – things like engaging with customer support.
It was an occasional source of friction between us Cloud Foundry engineers and Labs folks who were joining us for a rotation. A Labs Pivot might see me, say, spending a day on figuring out some release engineering problem for our part of the product, and try to redirect me away from something that was "not my job" and back towards writing tests and making them pass. I'd have to explain that writing software wasn't my job – my job was getting working software shipped to customers.
But, honestly, there's a good reason that Labs engineers tended to start from that frame, because developers at most companies spend incredible amounts of time on stuff like status meetings or ticket management or repetitive operational work. Every time I join a new company I'm surprised all over again how long it takes to get a working development environment set up, for instance.
This is getting long and it's 3pm on a Friday and I need to hit publish, man, even though I'm not done– but I've got one more thought on this topic before I leave you this week.
Another way to look at what I'm getting here is just the standard Eisenhower Matrix thing: Things tend to be on fire a lot at most companies because they don't spend enough time on the "important, but not urgent" things that prevent problems before they become "urgent and important," and they tend not to work on the "important, but not urgent" stuff because they're so busy with "urgent, but not important" stuff.
And one of the things that was really weird about Pivotal was that – at least a team level – people tended to actually solve "important, but not urgent" problems.
I could give a lot of examples here but the simplest is the best: Where you work right now, how many of your tests just fail occasionally? How many of your first-time test runs are red for reasons that don't reproduce? 10%? 50%? 80%?
At Pivotal that number was never zero but it was the only place I've ever worked where it was taken for granted that if you had a test that failed you would stop and figure out why and fix it immediately. Yes, even before finishing the feature. When else were you going to do it?
(We didn't always do this for "big" tests – the kind that use a whole working instance of the whole system, and are therefore vulnerable to failures from things like network errors – so those suites tended to be a little flakier. But for kinds of tests where an intermittent failure means something like "two tests are sharing state, so if they're run out of order they'll fail" folks were pretty consistent about hunting that down.)
(Personally I think this is one of the secret reasons pairing is such a force multiplier. There are a lot of dumb little paper cuts that engineers tolerate because, basically, its hard to be kind to ourselves. When we're in a pair its easier to say, "Hang on, we should take the extra minute to actually make this nice for the next person who deals with it.")
Anyway. This feels like a thousand words of just circling around the topic? I haven't really done the interview process justice yet, and I haven't touched @ask at all. I've avoided writing too much about Pivotal but the response to last week's newsletter was... heartening? Inspiring?
I wrote in this month's Mere Being about my mixed feelings on writing more about the place but I think I'm going to at least try.
Thanks for sharing, and, of course, for reading.
- Nat