The Automator’s Dilemma

Automation is not to blame for all the job destruction and wage stagnation. But you can still do great harm if you build it for the wrong reasons.

We’re told that automation is destroying jobs, that technology is replacing people, making them dumber, less capable. These are lies, with just enough truth to confuse us. You can have my robot washing machines when you pry them from my cold, wet hands.

I’m not some Pollyanna, thinking tech is only ever positive. Its potential for abuse and hurt is visible across the centuries, and especially so today. But I’m more optimistic about the upside than I am pessimistic about the down, and I’m uninterested in scaremongering screeds against it.

And yet. Technology and automation are not forces of nature. They’re made by people. By you. And the choices you make help to determine just how much good or bad they do. Even with the best of intentions, you might be doing great harm. And if you don’t have good intentions at all, or you don’t think ethics are part of your job, then you are probably downright dangerous.

I’m here to convince you that you have a role in deciding the future impact of the technology you build, and to provide you — especially you founders, tool builders, automators — some tactical advice on how to have the best impact, and avoid the dark timeline.

As I was building Puppet, explaining that I was developing automation for operations teams, execs and sales people would think they got it: “Oh, right, so you can fire SysAdmins!”

Ah. No.

When prospective customers asked for this, I offered them a choice: You can keep the same service quality and cut costs, or you can keep the same cost, and increase service quality. For sysadmins, that meant shipping better software, more often.

Their response? “Wait, that’s an option?!” They only knew how to think about their jobs in terms of cost. I had to teach them to think about quality. This is what the whole DevOps movement is about, and the years of DevOps reports Puppet has published: Helping people understand what quality means, so they can stop focusing on cost.

And those few people who said they still wanted to reduce cost, not increase quality? I didn’t sell to them.

Not because they were wrong. There were real pressures on them to reduce costs, but I was only interested in helping people who wanted to make things better, not cheaper. My mission was completely at odds with their needs, so I was unwilling to build a product to help them fire their people.

This might have been stupid. There are good reasons why a CEO might naturally build what these people want. The hardest thing in the world to find for a new product is a motivated prospective customer who has spending authority, and here they are, asking for help. The signal is really clear:

You do a bunch of user interviews, they all tell the same story of needing to reduce cost, and in every case, budgets are shrinking and the major cost is labor. Great, I’ll build some automation, and it will increase productivity by X%, thus enabling a downsizing. The customer is happy, I get rich, and, ah, well, if you get fired you probably deserved it for not investing enough in your career. (I heard this last bit from a founder recently. Yay.)

This reasoning is common, but that does not make it right. (Or ethical.) And you’ll probably fail because of your bad decisions.

Let’s start with the fact that you have not done any user interviews. None.

The only users in this story are the ones you’re trying to fire. Executives aren’t users. Managers aren’t users. It seems like you should listen to them, because they have a lot of opinions, and they’re the ones writing checks, but nope.

This has a couple of consequences. First, you don’t understand the problem if you only talk to buyers, because they only see it at a distance. You have to talk to people on the ground who are doing the work. Be careful when talking to them, though, because you might start to empathize with them, which makes it harder to help fire them.

Even if you do manage to understand the problem, your product will still likely fail. As much as buyers center themselves in the story of adopting new technology, they’re largely irrelevant. Only the people at the front line really matter. I mean, it’s in the word: Users use the software. Someone, somewhere, has to say: Yes, I will use this thing you’ve built, every day, to do my job.

If you’ve only talked to buyers, you have built a buyer-centric product, rather than a user-centric one. Sure, maybe you got lucky and were able to build something pretty good while only talking to managers and disrespecting the workers so much that you think they’re worthless. But I doubt it. You’ll experience the classic enterprise problem of closing a deal but getting no adoption, and thus not getting that crucial renewal. Given that you usually don’t actually make money from a customer until the second or third year of the relationship… not so great.

Users aren’t stupid. Yes, I know we like to act like they are. But they aren’t. If your value promise is, “Adopt my software and 10% of your team is going to get fired,” people know. And they won’t use it, unless they really don’t have a choice. Some of that is selfish — no one wants to help team members get fired, and even if they’re safe today, they know they’re on the block for the next round of cuts. But it’s just as likely to be pragmatic. You’re so focused on downsizing the team that you never stopped to ask what they need. Why would someone adopt something that didn’t solve their problems?

What’s that you say? You ignored their problems because you were focused on the boss’s needs? This is why no one uses your software. Your disrespect resulted in a crappy product.

Call me a communist, but I think most people are skilled at their jobs. I am confident that I can find a learned skill in even the “low skill” labor. I absolutely know I can in most areas people are building software.

I was talking to a friend in a data science group in a software company recently, and he was noting how hard it was to sell their software. He said every prospective buyer had two experts in the basement who they could never seem to get past. So I asked him, are you trying to help those experts, or replace them?

He said, well, our software is so great, they aren’t really necessary any more.

There’s your problem. You’re promising to fire the only two people in the whole company who understand what you do. So I challenged him: What would your product, your company look like if you saw your job as making them do better work faster, rather than eliminating the need for them?

It’s a big shift. But it’s an important one. In his case, I think it’s necessary to reduce the friction in his sales process, and even more importantly, to keep those experts in house and making their employers smarter, rather than moving them on and losing years of experience and knowledge.

The stakes can get much bigger than downsizing. In his new book, Ruined By Design, Mike Monteiro has made it clear that designers and developers make ethical choices every day. Just because Uber’s and Instacart’s business model requires that they mistreat and underpay workers doesn’t mean you need to help them. While I don’t think technology is at fault for most job losses, there absolutely are people out there who see the opportunity to make money by destroying industries.

This is not fundamentally different than the strip mining that happened to corporations in the 1980s, except back then they were making money by removing profit margin in companies and now they’re making money by removing “profit” margin in people’s lives. Jeff Bezos of Amazon has famously said your margin is his opportunity, and his warehouse workers’ experiences makes clear that he thinks that’s as true of his employees as it is of his suppliers and competitors.

Just because they’re going to get rich ruining people’s lives doesn’t mean you have to help.

I think your job matters. I think software can and should have a hugely positive impact on the world; not that one project can by itself make the world better, but that every person could have their life improved by the right product or service.

But that will only happen if we truthfully, honestly try to help our users.

When, instead, we focus too much on margin, on disruption, on buyers, on business problems…. we become the problem.

My Losing Battle with Enterprise Sales

I’ve hated enterprise sales since long before I started Puppet. I just didn’t know why.

Photo by Tim Trad

You can either be a good example or a horrible warning. When it comes to enterprise sales, I had two horrible warnings before I started Puppet.

In 2000, I worked at Bluestar, a business DSL startup in Nashville. Pretty much everything that can go wrong with a startup did with this one: Founder was pushed out the week I started (I swear it wasn’t my fault), they raised too much money ($450m) and then spent it badly (e.g., on hardware that didn’t work and on salespeople that didn’t sell), they brought in a big business CEO who had no idea how to run a growth company, and then the regulatory framework shifted to highly advantage monopolies again so they all went broke. But in the meantime, I got to learn a lot, both about the problems that eventually resulted in my starting Puppet, and also about what does and doesn’t work in business.

At one point, the company decided to buy a new product. I honestly can’t remember what it was for. Something related to asset tracking? Or maybe some kind of operational monitoring software?

I don’t know. I just know I shifted from being a sysadmin to responsible for making it work. I wasn’t part of the team that decided whether to buy something, and if so, which one to buy, I was just designated to put their decisions into action. In the months I worked on it, I don’t think we ever even got it installed anywhere except on a test server, and at some point we just, ah, decided we didn’t need it any more. The project went away, so I returned to my old job. The executive who had made this horrible decision had the gall to say my moving back to my old role was a strike against me, and it would reflect on my tenure at the company. No worries, he was gone the next month.

This wasn’t just a software problem. While the company was slowly dying, they had an argument with EMC over a storage array they never should have purchased. A million dollars of hardware sat in a receiving warehouse for almost a year, because we would not accept it, and EMC would not take it back.

The second warning was during my brief stint at Bladelogic. I worked there for less than six months, but I learned a lot. Again, mostly what not to do. I was ostensibly a product manager, but in practice they just wanted me to maintain their lab and maybe write some justifications for how their product worked. Certainly they did not want to listen to me. My most memorable experience is being in an all-dev-team meeting when the most senior engineer said something like, “What does it matter what the customer thinks? They already bought the product.” Astoundingly, the CTO did not fire him on the spot, and instead just moved on, ignoring the comment entirely.

It was clear Bladelogic’s business model enabled them to just not care what their customers thought. Onlyprospects mattered. Once the deal was closed, meh, they got paid, no biggie. You literally could not upgrade their software without losing all of your data — you know, the stuff you’re using to build and deploy your whole infrastructure — and doing any real work with the system required that you do everything twice, once to deploy and the second time to update. But you’d never discover that unless you actually used the software, which would be long after their salespeople left, so who cares? Not them.

You can maybe see why I lasted less than six months. It didn’t help that I was commuting between Boston and Nashville, and I’d managed to rent an apartment at the center of a cold vortex in Boston where my roommate collected Grateful Dead grape juice.

So when I started Puppet, I didn’t know much, but I at least had some anti-patterns. I knew we had to care more about our customers successfully using the product than we did about closing the initial deal, and that selling to people who would not use the software was a bad idea.

It turns out, that’s not quite sufficient to develop an effective sales strategy. Who knew?

I was lucky enough to hire the best sales leader in Oregon, who was not only incredibly skilled and experienced, he was also used to entrepreneurs and found me relatively sane compared to bosses he’d had in the past. Where a bunch of our engineers complained every time I opened my mouth, this guy quietly soldiered on. That made our years-long argument much easier to manage.

Early on, I didn’t know enough to break down what I wanted and what I didn’t, or how to talk about the individual behaviors, so I just wrapped up everything I hated and called it “enterprise sales”. We weren’t doing that. Ironically, our sales leader agreed with most of my concerns, so it wasn’t a real fight in the normal sense, but there were multiple areas he was convinced we needed to change, and it’s hard to do that when your ignorant CEO just puts up a ward against the evil eye and changes the subject.

Within a couple of years, he wouldn’t even say the word ‘enterprise’, because I would jump down his throat, proverbially speaking.

In the first few years of building Puppet, I tended to focus on preventing sales from skewing our product plans. I wanted to be sure we built products to be used, not sold, and I didn’t trust myself or the team to be able to tell the difference. I think this was basically right, but today, I would know that you should treat ideas from sales like you treat those from customers:

Always listen to what customers tell you, but never do what they say.

The sales team has a limited lens into the product world. They are smart and highly educated about your customer, but that doesn’t automatically translate into good solutions.

This is a general risk at any company with sales teams, but you have an even more pernicious variant with enterprise sales teams: Being confused on who your customer is.

Are you building the product for the person who buys it, or the one who uses it?

Remember back to that product I tried to set up at Bluestar. It was purchased to solve a business problem, and the person who decided to buy it did so based on discussions with sales and, probably, looking very closely at a grid of check marks comparing it to its competitors.1 Actually using it was someone else’s problem.

In fact, I was not going to be the user either — I was supposed to be its administrator. Some other team (support or installation, probably) was going to actually use it. So they were even further from the buying decision.

If you’re selling to the enterprise, getting a deal done requires that you convince the buyer that your product is a winner. That makes them the most important person at the customer. Now, a quality company would also involve users, administrators, and many others in a buying decision, but in the end, buyer decides. Two or three decades ago, these decisions were mostly made on the golf course, so schmoozing was the most important feature. Today, it’s a lot less corrupt, but not a whole lot more functional.

This brings us to the other problem in this separation between user and buyer: Enterprise sales is a team sale, not selling to one user. Suddenly you succeed based on your ability to manage the interpersonal relationships of warring sub-teams at your customer, instead of the strengths of your product. I distinctly remember a dinner with tens of customer employees, and there was almost a flashing DMZ between two teams, who had differing opinions on whether our solutions was the right one. Salesperson quality and experience begin to matter more than anything else, because you’re basically managing internal politics to get a deal done.

Where did the focus on our product go? How do we stay focused on building something our users love?

We don’t, really. It’s hard to sustain an effective a feedback loop that includes sales if they’re focused more on people and politics than products. Not impossible. But hard.

At a big company, you can begin to navigate this kind of cognitive dissonance — listen to your sales team, but don’t build the products they demand. But in the early days of Puppet, I knew I couldn’t handle it. I am not good at dissonance in general — I’m a bit too fond of the idea that there’s just one truth — but I especially knew my organization could not handle it. We needed to be 100% aligned, and that meant sales needed to be working on the same problems as our product teams. Thus, no enterprise sales.

As we got bigger, the other big problem with enterprise sales starts to show up: Wow is it expensive. Lew Cirne of New Relic told me the primary reason he sold Wily when he did is because he needed to $150m just to build out the sales team and it wasn’t worth it.

If you’re doing inside sales, you’ve probably got someone who can talk through most of the product, they can talk to ten or more customers a day, and only once in a while will they pull someone in to help get a deal done. Once you go enterprise, you have field reps who might be covering thousands of square miles of territory, so if you’re lucky they’ll do three meetings a day on average, and they need a sales engineer on almost every visit. They pull in an expensive executive for meetings as often as an inside rep would pull in a cheap sales engineer.

Yes, you can get much bigger deals done this way, but think about the disruption to your organization: Essentially everyone on your leadership team is taking time away from running the business, not to learn from customers but just to make them feel loved enough to write a big check. Your deals start taking nine months to close instead of six weeks, and getting a check signed begins to look more like a challenge level in a video game than a partnership to solve customer problems. And the boss fight of that game is the worst part of enterprise sales: Procurement.

I’m not in the habit of disrespecting roles or teams, and I think procurement is often staffed with experts who play a vital role in their company. But they are generally paid based on how much money they “save” the company. All that discounting that you have to do for enterprise clients? It’s because procurement’s bonus is based on how much of a discount they force you to give. Absolutely everyone knows this is how it works, and that everyone knows this, so it’s just a game. I offer my product for a huge price, you try to force a discount, and then at the end we all compare notes to see how we did relative to market. Neither of us really wants to be too far out of spec; I want to keep my average prices the same, and you just want to be sure you aren’t paying too much.

But because companies compensate procurement based on saving money rather than making good decisions about what to buy, we can sell crappy products at a steep discount but not good products at list price.

It’s a helluva boss fight.

There’s often a miniboss, too: Legal. They just want their pound of flesh, and often this seems more like a puzzle level than a direct fight. I recently saw a deal that had been in legal for a year. That’s too much puzzle for me. (Incidentally, I worked on that same customer more than 4 years ago. Talk about long sales cycles.)

So now you begin to see why I fought against enterprise sales: It encourages you to build the wrong product for the wrong person and then sell it the wrong way at the wrong price.

Why, then, is it so popular? Or rather, why is it so hard to avoid that despite my best efforts we ended up in an enterprise sales motion, which I then ran away from?

Well, first and foremost, if it works it’s incredibly lucrative. For all that Lew Cirne built New Relic in response to his experience at Wily, and pointedly avoided enterprise sales for years, once they went public they went through a dramatic transformation and added it in, because the money was just too appealing. The biggest companies buy the most software, and, well, the biggest companies want to be sold a specific way.

In many cases, you just can’t avoid it. That’s a lot of what happened at Puppet: Our products were built to solve problems that big companies have. Heterogeneous environments, every operating system and application known to man, complex networks, and heavy compliance needs. Turns out it’s rare that a company has all these problems but buys large software products like you buy toilet paper.

Our first deals at companies did tend to look very consumer-like. But once they wanted to expand to other teams, and especially if they wanted to cover the whole company, the relationship naturally switched to a team sale, where we’re having to work with legal, procurement, executives, and then reps from three or four other teams. Ideally someone inside the org is an advocate for our product, so it’s more facilitation than direct selling, but the problem still stands: This is a clear enterprise sale.

But when it works… wow. You start closing $100k deals, then $300k, then $1m, then $10m. This starts to add up.

And for all that I’ve said this is hard… it’s actually the easiest way to sell.

What’s actually hard is having the best product, and only ever winning based on merit. Enterprise sales is the default motion, and in many cases it’s chosen to paper over weaknesses in the product. After all, only the user would actually notice those; in a meeting with the CIO, procurement, legal, and project management, no one’s going to install the product and give it a runout.

We’re still super early as an industry in our understanding of how to build a product that doesn’t rely on enterprise sales. For all that Atlassian relies more on sales than it has said, there’s no question that they managed to avoid an enterprise selling motion. I’m hoping the next generations of software companies will learn from them instead of Workday.

In the meantime, hopefully this story of how I fought enterprise sales, and why, will help you make better decisions about how to build your own teams. At the least, maybe I can just be a horrible warning.

  1. These feature check lists are bad ideas. Don’t trust them as a user, don’t make them as a product marketer.

Follow your weird

To really win, you have to seem strange to your true peers, not just the world at large.

Photo by Elias Castillo

Look, I have to say it: You’re weird. Even if I don’t know you, I’m confident: Somewhere, maybe lurking deep inside, something about you is just not right. I don’t know what, specifically. For all I know, you might be one of those weirdos whose particular strangeness is just how authentically normal you are. *shudder*.

This might be insulting to you, calling you weird. It happens a lot: I think I’m complimenting someone and they get all huffy. Conversely, people are often afraid I’ll be hurt when they shyly let me know that I, ah, don’t really fit. Don’t worry; you’d need to know me a lot better to successfully offend me.

Society is not a huge fan of weirdness — I mean, the definition is pretty much, “does not fit into society” — and it trains you away from it. We’re social animals, so you probably do what you can to conceal, or at least downplay, anything different. It makes sense. It’s a basic survival mechanism.

I know I do it. I can’t hide everything — some stuff just can’t be covered up — but I can usually skate through a conversation or two before people back up a step and give me that funny, sometimes frightened, look. Being on the west coast helps; I’m a little less weird here than I was in the south. It probably also helps that I cut my mohawk, and the spiked leather jacket and knee high boots stay in the closet now.

I’ve written a bit about my struggles to balance authenticity and fitting in. I think it’s important to call out it out, because those who experience this struggle rarely have the luxury of admitting it. I’m lucky enough in multiple ways that I can be up front about it now. But resolving this conflict matters for more than psychological reasons. Our own goals usually require that we learn to embrace our weird. Not just grab on to it, actually, but really live in it. Inhabit it.

That weirdness is how we win.

This is easiest to show in investing. We have a natural tendency to do what is proven to work, but that is only assured of getting “market” — in other words, mediocre — returns. If you study the best investors, they’re all doing something that seems weird. Or at least, it did when they started. The first people who paid to string fiber from NYC to Chicago to make trades a couple milliseconds faster were considered pretty weird, but they knew the truth: Normal behavior gets normal returns, anything more requires true weirdness. (Well, or fraud. There’s always that if you’re afraid to stand out.)

It’s the same way in life. You can’t say you want something different, you want to be special, but then follow the same path as everyone else. “I’ll embrace what makes me special just as soon as I get financial security via a well-trodden path to success.” Oh yeah. We definitely believe that.

There’s a nice sleight of hand you can do, where you can say you’re doing something different, but really you’re a rare form of normal. The first few doctors and nurses were really weird. Those who recommended you wash hands before surgery were literally laughed at, considered dangerous crackpots1. But now? Most people become a doctor in pretty much the same way. Being a doctor is normal now, even if it’s not common. That’s probably good.

But what if your job is innovation? What if you’re whole story revolves around being different? Can you still follow a common path?

Because that’s what too many entrepreneurs today are doing: Trying to succeed at something different, by doing what everyone else is doing.

I mean. Not literally everyone else. But close enough.

It starts out innocently enough. There aren’t many people starting tech companies at first, and boy howdy are they weird. Someone makes a ton of money, all their weirdness gets written up — “hah hah, see how he has no sense of humanity but is somehow still a billionaire?” — and now we’ve got something to compare to. Hmm. Well. We can’t consistently duplicate Jobs, Gates, Packard. But if we tell enough stories enough times, we find some kind of average path through them. Ah! Enlightenment!

Now that we know what “most” people do, we can try it too. I mean, we have no idea if the stories about those people have anything to do with why they succeeded, but why let that get in our way? Conveniently, every time it works we’ll loudly claim success, but silently skip publishing any failures. Just ask Jim Collins: He got rich by cherry-picking data in Good to Great to “prove” there was a common path to business success. It turned out to have as much predictive value as an astrological reading, and is just business garbage dressed up in intellectual rigor, but that doesn’t seem to have hurt him.

The business world keeps buying his books. They need to believe there’s a common path that anyone can travel to victory. Otherwise, what would they sell? What would they buy?

Obviously this doesn’t work. There is no standard playbook to winning an arms race. Once there’s even a sniff of one, people copy it until it doesn’t work any more. This is pretty much the definition of the efficient market hypothesis: There’s no standard way to get above-average results. Once Warren Buffet got sufficiently rich as a value investor, so many people adopted the strategy that, well, it’s hard to make money that way. Not impossible, but nowhere near as easy as it was fifty years ago.

Of course, you can go too far in being weird. There has to be something in your business, in your strategy, that makes you different enough that you just might win. But adding a lot of other strangeness for no good reason worsens already long odds. The fact that Steve Jobs did so well even though he was a raging asshole, even to his best friends, made his success just that much less likely. Most people are a bit more like Gates and Bezos: Utterly ruthless in business, and caring not a whit for the downsides of their success, but perfectly capable of coming off as a decent person whenever required.

I’m rarely accused of being a world-class jerk, but I don’t pass the smell test as normal for very long. Jim Collins might say maybe if I were more pathological I would have succeeded more. With Jobs and Musk as examples, it seems reasonable, right? In truth, it’s just as reasonable that I would have done better by dropping out of Reed College, like Jobs did, rather than foolishly graduating from it. Think it’s too late to retroactively quit early?

Yes, you have to learn to love your weird, but it shouldn’t be arbitrary. You can’t realistically say that you’re going to rock it in business because you’re addicted to collecting gum wrappers from the 50s. I agree that that’s weird, but is it usefully so? Being a jerk is weird, and bad, but it’s not helpfully so. And really, dropping out of college isn’t that weird for someone in Jobs’s financial position at the time. It’s only if you have a bunch of money that it seems so.

I recommend you take the time, think deeply on what opinions you hold that no one else seems to, what beliefs you have that constantly surprise you by their lack in others. What do you find easy that others find impossible? What’s natural to you, but somewhere between confounding and an abomination to those who notice you doing it?

Those things aren’t all good. And in many cases, you’ll need to spend your entire professional life managing their downsides, like I have. But somewhere in that list is what sets you apart, what gives you the opportunity to truly stand out. They’re the ground you need to build your future on.

Unless you just want to be normal. In that case, I don’t think I can help you.

  1. This is an amazing example of sexism. The doctor’s wards had three times the fatality rates of the midwife wards, but of course, they were doing nothing wrong at all.

Great advisors reveal your truth, not theirs

Giving answers is easy, and usually worthless

Photo by Blake Cheek

Being an advisor to other founders is a contradictory affair: Be helpful, but do not give advice. That is, I want to help you do your best work, but I don’t think I can or should do it by telling you what to do or think.

I obviously think I have value to add or I would not sign up to help. Well, maybe it’s not obvious; our industry is rife with advisors who attach their names and little else to projects. It’s true I’m motivated to join partly by the possible long-term reward, but mostly I’m helping because I enjoy it and am learning a lot.

While running Puppet, I was constantly confronted with a classic leadership struggle: How do I simultaneously help people improve their own answers, yet get them to do what I want? There are many who will say this is a false struggle, that I could have avoided it by focusing on empowering people instead of trying to get them to do what I wanted. Pfft. The literal definition of leadership is providing direction and getting people there, and that’s doubly so for a fast-growing startup where alignment is critical to execution. I spent a decade slowly, incrementally, getting better at this, but felt my incompetence as keenly at the end as I did at the beginning.1

Advising companies allows me to practice the empowerment-half of this skill without the other complications. Unlike when I was a CEO, I know I should not be setting direction or making decisions. My job is not to provide answers, but to help people do their own best work.

My only explicit training for this was when I was an organic chemistry lab tech in in college. My primary task was repeating questions back to the students: “I don’t know, which layer do you keep?”2 When I started dating my now-wife in college, she told me her friends were bitter that I would not give them answers. I knew my job. I was there to help them get an education, which required they did the work on their own. This has also been helpful experience for being a parent: “I don’t know, what is 12 times 9?”

Advising CEOs has similar constraints, but it’s a lot more open-ended, and has no answer sheet. In the lab, there was one right answer, it was always the same, and you could reason it out with the information at hand. Labs were also usually a day of work, maybe three days, and mistakes were pretty cheap, in the grand scheme of things. I don’t expect one of those students to track me down later in life and lay at my feet all of their struggles or successes. Most importantly, we were studying an objective space that I did actually know more about. When push came to shove, I knew the answers, and I could reason out anything that wasn’t obvious.

Helping CEOs is considerably harder. I’m rarely asked about questions that have a single right answer. No competent CEO would bother getting advice on an easy question, or one whose answer wasn’t important. Wrap into this the fact that I can’t possibly know the company as well as the person asking me the question.3 It’s inconceivable that I would often have answers available that the expert in the seat doesn’t.

That simplifies the challenge: Prod the questioner into getting to their own answer, no matter how much they complain. And they do sometimes get upset: I had a CEO exasperatedly demand what I would do, after a long session of forcing him to work through what he cared about, what he saw as the right answer. When I relented — only after he had already done all the hard work — he could see how thin and useless my answer was. By the time he’d decided what to do, he saw that what he learned from the process was at least as important as the answer, and my just providing a solution could never give that.

There is still some risk. I’m by no means a master of this technique. I know I have at times presented people’s options in stark ways, which sometimes felt like no choice at all. My own predilections, such as toward a consumer-style sales model, are hard to separate from any guidance I might provide. It’s honestly just hard to know sometimes whether you’re successfully getting someone to express their own implicit belief or leading them to agree with one of yours.

It’s a skill I expect to spend the rest of my life trying to master. But it’s worth doing, and I’m enjoying the learning process.

Helping CEOs instead of running my own company provides a kind of repeatable laboratory environment. I get to learn at the same time, though, because it’s much harder than being a lab tech.

It’s not enough to just parrot questions back. I spend my time listening closely and drawing out more information, then replaying back what I heard. Listening is a woefully underrated skill. I’ve been loving the opportunity to practice really hearing what people are saying, and trying to differentiate between the words they use, the meaning behind them, and their intent in saying it at all.

As you look for advisors, be sure you demand the same discipline from them. Don’t accept answers. They should hear you, understand your dilemma, and be able able to point out where you haven’t thought completely, or clearly.

A great advisor should provide light, not direction.

  1. If this whole definition of leadership annoys or offends you, I’d ask how you differentiate between leadership and management, and also how you expect a company to align around a direction without someone picking the direction.
  2. Nearly every experiment in organic chemistry involves using liquids to separate chemicals, where part of the solution ends up in an aqueous (watery) layer, and the other ends up in another layer, like separated oil and vinegar in salad dressing. One of those layers is now waste, and the other one has the chemical you’re working on. Don’t throw away the wrong one!
  3. This is another big difference from when I was the leader; I knew Puppet itself better than anyone, even if I could not know your specific area as well.

Hold on to your why

Founders need to retain their own mission while they build out the company’s.

Photo by Sharon McCutcheon

Managing a high-growth company is the hardest thing I’ve ever done. One big reason is that I only received problems that no one else could figure out. Some were organizational problems that should naturally route to the CEO, but a lot were functional issues that I was no more capable of solving than anyone else.

I eventually discerned a repeated pattern in solving these problems. At first I would just get a few issues. I’d muddle through — do a bit of research, ask for help, and sort things out. As we grew, more and more of my time would be spent on this one kind of problem. I’d become better and better at handling it, and just about the time I’d start feeling like I knew what I was doing, I’d realize, “Oh: There are people out there who specialize in this”. I could just hire someone to do it full time, and they’d be better at it than I ever would. Duh.

I’d then spend three months, or six, or twelve, hiring for the role, and bam, suddenly my time is freed up and I’ve got an actual expert in charge. Well, kind of. At this point I’m a self-taught semi-expert who does not buy into the orthodoxy of the role, and we’ve got a year of my weird solutions, so there’s a lot of friction as we sort out just how to add this new skill set to a growing org. But the point is, my time spent on this problem drops precipitously, and I no longer have much opportunity to put my new-found skills into practice.

Usually just in time for something new to come into focus.

This pattern — gain just enough expertise to hire someone — played out again and again, for me and for other founders I’ve talked to.

In some ways it’s thrilling. You get experience with all of the key areas at the company, and you’re always learning something new.

In other ways, though, it is soul-crushing. Over the eight years I managed Puppet while in fast hiring mode, I rarely got to spend time doing anything I was good at. Humans have a psychological need to feel competent, to feel like they are in control and know what’s going on. I don’t need this all the time, but please, just a little? Sometimes? Nope. Pretty much the second I started to feel like I understood something, I had to hire for it, and my problem changed from doing to managing.

After years of this, I knew just enough about everything to suck at it, but not enough to actually be useful to anyone.

Only as my tenure as CEO came to a close did I begin to see what I uniquely added to the organization. I began being comfortable not delegating certain problems, and felt justified in spending hours on something as an individual contributor, rather than seeking leverage in everything I did.

Only once this happened did I start to feel comfortable as a CEO. I wasn’t just routing problems, I was actually solving some of them. I was not spending 100% of my time in areas I was incompetent; just most of it.

I know the advice as well as you: Great leaders delegate, they empower. If you’re doing the work yourself, you’re not a real leader.

Bullshit.

Yes, building and running a team absolutely requires that you empower the team. But that doesn’t mean you don’t get to do anything yourself, that you hand everything off and have nothing left.

Just like everyone else, you, too, need a reason to show up, to stay engaged. You have to hold on to your own why.

If you don’t remember why you, personally, are in the job, then you’ll look up in a few years and realize it’s not there any more. You’ve moved too far from what gets you up in the morning, and suddenly you can’t do it. Or worse, the company has developed but you haven’t. You’re no better at the thing you want to master than you were when you started, because you haven’t been spending time on the problems you care most about.

Some of this is that you need a place of safety. I am a highly fireable person, and raising venture capital made for downright tenuous tenure. The less confident I was about my own strengths, my own value, the less safe I felt. And humans need to feel safe to do great work.

More than that, though, I needed a platform for learning. I was pursuing mastery, but of what, exactly? Of not mastering things?

I know other leaders really are master delegators, hirers, organizers, etc. But that was never going to be me.

I had to peel things back, really understand why I was there, what I cared about, what I wanted to be the best in the world at. And, really, what I was good enough at that I ended up in this place, running this company. Then, as the problems rolled by, I could be sure to push that forward just a little bit, even if my focus was on the organization’s needs, not my own.

The times I lost this sense of why I was there and what I was getting better at were some of my most depressing days. But the days where I could connect what I felt good at, what I spent my time on, and what the company needed from me were the best days.

I don’t think that’s any different for me, or for other founders, than it is for anyone else.

But all the discussions of leadership I hear leave this bit out: You’re a human, too. You have to provide the why for the whole organization, but every individual deserves to be able to translate that into what they do every day. Even you.

How to Neg a Founder

Is that a compliment, or an insult?

Photo by John Salvino

My experience growing and fundraising for Puppet was full of inspirational-sounding phrases that cut like a knife. Aggressive goals got praise for wanting to “build a real product” and “really scale this thing.” These are some of my favorites. And when I say “favorites,” what I mean is, I hate them. Deeply.

The one that I heard most often made me want to walk out of the room. I’d pitch an investor while fundraising, and he (always he) would say: “So you’re going to try to turn this into a real company, eh?” As if being my full time job for years was somehow not real. As if you are the arbiter of truth, not my customers. Or me.

If you want to make an entrepreneur feel small, you really want to piss them off, try to inspire them this way. I assume most people who used it thought they were complimenting me, impressed that I was taking this big step or something. But it was a sure fire way to trigger my defenses. When you diminish the work I’ve done so far, it’s hard to see you as a potential partner. I quit my full time job five years ago, and have missed out on hundreds of thousands of dollars of earnings, but asking you for money is what shows I’m serious?

I’m convinced at least some investors did it on purpose, as a form of negging — trying to position themselves as an authority and me as someone who needed their help and wisdom. “That’s pretty cute. Why don’t you get some help from the professionals?” I’m good, thanks.

I know most people didn’t mean it that way, though. Their worldview is just so skewed that if you haven’t raised a ton of money, you’re not really trying. They can only conceive of success if it looks a specific way. You literally cannot succeed unless you do what they do, what all their friends do.

If you’re an investor, advisor, or executive, take a deep look at how you talk to founders. Are you truly complimenting them, or actually diminishing their work? Are you presenting yourself as the arbiter of success, even while you think you’re saying the other person has done so well?

If you’re a founder, know that you don’t have to take it. No one else gets to define success for you. There’s always an in-crowd, but by definition the best results come from being outside of it. Even if you decide you need their money, you don’t have to accept their framing.

Owning my writing

It’s the message, not the medium

I did more writing in 2017 than I ever have before, probably more than I had done in my entire life. I stated at the outset my desire to write in order to learn, and publishing regularly has delivered. More importantly, it forced me to capture and share many of the results of my R&D. The writing topics were primarily venture capital, the software startup ecosystem, and founder optimization, but one of my weaknesses is a drive to the meta, spending time on the tools and systems rather than the work itself. Unsurprisingly, this ground is as fertile in prose as it is in code.

I have done all of my writing on Ulysses, which has been a good tool. I do miss much of the power of Vim for managing text, but the usability trade-offs are usually worth it. Plus, Vim is not exactly strong on wrapped text. Ulysses’s most important capability for me is that it transparently syncs between my phone , both of my iPads, and all three of my computers (yes, I know). I can open any document on any device with no worries (given my iPads are on LTE, and thus can always download updates). Second to that is the ease of getting data out. I was able to text a 5k word document directly from Ulysses on my phone to two different people, because it converts anything to PDF and can send out via the share sheet. It publishes directly to most platforms, so I used it to post everything to Medium. I do wish its backend storage was more visible, so I could version control everything in git, but you can’t have everything.

The only time I ran into troubles was publishing my travel writing — I was copy/pasting photos from Apple’s Photos app into Ulysses, then publishing into Medium, and it turned out that no part of this process downscaled the photos, meaning each was about 20MB. This is fine when you’re on solid wifi, but not so good from a campground in Yellowstone. The primary reason I did not write during the second month of my trip is it was just too painful to publish. Ulysses really fell down here, because when it works, it works great, but when it fails it is miserable. I’d just sit and stare at my iPad for ages, with no visibility of failure or success until the very end, and it would often manage to upload the text but not the photos. The only fix for this was to delete the draft from Medium and try again. Not so great.1

Over the year I became concerned, though. I heard about Andrew Chen, who built a following on successive publishing platforms (e.g., Blogger), each popular and well-funded, only to have the companies disappear (because that’s what Silicon Valley does to most companies). He eventually realized that the only way to consistently reach those who were interested was via email; it’s never going away, subscriber lists are easily portable, and of course everyone knows how to use it. He had to move from letting a platform own his audience to taking control directly, and email was the only real way to do that.

I think Medium is pretty good, and at least for now it has no shortage of funding. Even last year, though, it made well-publicized efforts to retool its business, a clear sign that whatever it was doing before wasn’t working. It seems unwise to bet that a follower on Medium will have any meaning in a few years.

It just so happened that I ended the year with an experiment in their new business model. My series on Venture Capital, in partnership with NewCo, was published behind Medium’s paywall. While the experience was positive overall, and I got paid more for those pieces than I have for, um, all of my other writing ever, earning money isn’t my real goal in writing. Yet, paying writers is exactly what Medium has to figure out in order to attract the content and audience it wants. I appreciated the extra attention working within their paywall provided, but I came out thinking it’s unlikely to be the right path for me in the long term. My goal is to maximize the reach of my writing, and it’s more about the arc of all of it rather than a couple of heavy-hitting pieces getting the most attention, which means our respective goals are orthogonal at best, and in direct conflict at worst.

While I have not written about it, I spent a lot of last year fascinated by email, inboxes, and how we consume content. I’ve been a deep fan of RSS from the Bloglines days (Unread is my reader of choice these days), but RSS is mostly dead (thanks, Google!). The kinds of sites that produced great feeds back in the day grew too big for a hobby. They became either wildly profitable for a small team and thus got destroyed with ads and shitty content (hi Boing Boing!) or people had to back away because it was just too much. Mainstream publications like the NYTimes might still publish RSS feeds (I literally have no idea), but RSS is a poor fit for how much content they produce.

When I look around, it seems that the RSS feeds of ten years ago are now awesome newsletters. See how often your favorite sites talk about their newsletters vs their feeds. I’m pretty confident I’ve never heard a podcast ask me to sign up for a feed, but many casually mention their newsletters. (Well, to be fair, podcast feeds are just RSS, so in that sense it’s survived, but I think we can agree it’s a very different use case.) The market has moved.

This shift is not all peaches and cream. The superiority of email as a publishing mechanism has not brought with it a superior reading experience. Long form content from writers I follow does not belong in the same inbox as requests for coffee meetings, yet that’s where we are. (I asked the Feedly CEO if they would please please add newsletter subscriptions to their platform, and he could only say they were considering it. If you want to build the newsletter reading app, hopefully with an index of great letters to subscribe to, count me in as an early contributor.)

Even with its downsides, I’ve decided to move my writing to my own site via a newsletter-first publishing model. From now on, everything will be published first to that site and the newsletter (sign up now!). There will be exceptions, when publications offer enough exposure that I give them some period of exclusivity. I will also indefinitely duplicate each piece to Medium on a delay, to take advantage of the audience I already have there.

There are enough examples out there that I’m pretty confident this is the right long term answer, but it’s early enough that it feels like an unstable experiment. Like most, I love and hate email, and I am a bit bummed about the extra infrastructure involved in this system.

If you’re still an RSS person at heart, you can always just subscribe to the feed, and if Medium is your bag, at least for now you’ll be able to see everything there, too. Of course I can’t promise how this plays out in the long run — else it would not be much of an experiment — but you can bet I’ll work hard to find the right way to talk with the people most interested in what I have to say.

One note before I go: I could not have made this transition without the help of Mike Julian. He helped set up each of the services, mediated the hiring of a consultant to modify the site, and connected all of the services together. He’s got a great book on monitoring, and is available for consulting on monitoring and observability. I can’t recommend him enough.

Thanks for following on so far. I’m excited about another year of writing.

  1. It’s worth noting that Apple’s iCloud Photo Library did wonderfully here; I could upload every photo to my iPad, and it would sync when it had good data, and sit quietly when it did not. I love asynchronous protocols.

Great design is ruining software

The arrival of the smartphone has convinced the world of the value of great software design, but it’s not all good news

The smartphone has reached more people and delivered more value faster than any technology ever seen. Much of the world has had to adapt to this arrival, but software design suffered the greatest reckoning. As the smartphone ascended, developers finally adopted reasonable design principles, realizing that they could not pack every feature ever seen into the smartphone experience. This recognition of the value of design — and especially, minimal design — is a good thing. Mostly.

I could not be happier that the industry finally accepts that there are principles of design, and there is a practice and discipline behind building great software. It’s great that we’re seeing more focused software that does little, but does it very well, rather than the previous age of the GUI when software attempted to own large parts of our lives by doing anything and everything. For a long time, Microsoft Word was used by nearly everyone who had a computer, and their strategy was to ensure no one ever had a reason to choose something else by building every feature anyone might ever need; their toolbar was the canonical example of never saying no.

The smartphone changed all that. Those rows of icons would fill the screen on a phone and leave no room for typing, and of course, no one would use them anyway because of how different the usage patterns are. As people realized they could no longer just throw in the kitchen sink, they began hiring (and listening to!) actual designers, and those designers have been steeped in the culture of Dieter Rams and the minimalism of the Bauhaus movement, which is awesome. Mostly.

Unfortunately, the phone caused everyone to focus on the final design principle of Dieter Rams (“Good design is as little design as possible”), without apparently remembering the nine that came before it, or why they were earlier in his list. I get it; the design constraints in a phone are intense, and it might not be a good idea to minimize everything, but it sure is easy.

The consequence of this mobile brutalism is a new movement building simpleton tools: Software that anyone can use, but no one can become an expert in.

Trello is a great example. I adore Trello. I think it’s great software, and it’s clearly a success by any measure. However, for all that I’ve relied on Trello daily for years, I feel no more an expert than I did just after starting to use it. It’s not because I haven’t tried; it’s because there’s no depth. You can pretty much plumb the product in a couple of days.

That’s fantastic for getting new users up to speed quickly, but deeply frustrating after a couple of weeks. Or months. Or years. Compare that with Vim, which I still use for all of my code editing, yet it’s so complicated that most people don’t even know how to quit it, much less use it. I’m not going to claim its lack of user friendliness is a feature, but I will defend to the death that its complexity is.

Apple’s Notes is the ultimate expression of this trend in text editor form. It’s a fine text editor. I know some people have written huge, impressive programs in similarly simplistic editors like Notepad on Windows. But I personally could not imagine giving up keyboard navigation, selection, text munging, and everything else I do. The fact that complicated work can be done on simplistic tools speaks to the value of having them, but in no way invalidates the need for alternatives. Yet, on the current trends, no one will even be trying to build this software I love because they couldn’t imagine two billion people using it on a smartphone.

I think it’s fair to say that that’s an unfair standard, and even a damaging one.

I miss the rogue-esque exploration that tool mastery entails. It’s not that I want tools to be hard; I want them to be deep. I want to never run out of ways to invest in my tools. I don’t want to have to swap software to get upgrades, I want to upgrade my understanding instead.

But I look around my computer, and everything on it was designed for the “average” user. I was not average as a CEO with 40+ hours of meetings a week while receiving more than 200 emails a day, nor am I average now as someone who spends more time writing than in meetings. There’s no such thing as an average user, so attempting to build for one just makes software that works equally poorly for everyone.

It is a rookie mistake to conflate the basic user who will never plumb the depths of their tools with the expert user who will learn every nook and cranny of your software. It is a mistake to treat the person who sometimes has to solve a problem the same as a person who spends 80% of their time working on that problem.

I don’t want to be an expert in all of my tools — for all that I take thousands of photos a year, I don’t think I’m up for switching to Adobe Lightroom — but for those tools that I spend the most time in, that most differentiate me, I want the opportunity for true expertise. And I’d happily pay for it.

Back in the days when computer screens were tiny, there were plenty of stats that showed that paying for an extra screen would often give people a 10% or more boost in productivity. I know it did that for me. As a business owner, it was trivial to justify that expense. Monitors cost a lot less than 10% of a person’s salary, and don’t need to be replaced every year. Heck, the whole point of the automation company I built was to allow people to focus their efforts on the most valuable work they could do.

Yet, when it comes to software being built and purchased today, to the tools we use on a daily basis, somehow our software ecosystem is failing us. There is no calendar I can buy that makes me 10% better, no email client available that I can spend five years getting better at.

It’s great that people are finally making software that everyone can use, but that’s no excuse to stop making software for specialists, for experts, for people who could get the most advantage from that extra 10%.

Please. Go build it. I know I’ll buy it.

Putting OKRs Into Practice

The true story of trying to put Google’s planning system into use

When Google was less than a year old, they began using a planning system presented by legendary venture capitalist John Doerr of Kleiner Perkins. When I went to put it into practice at Puppet in the early days of growing the team, things were not as easy as they appeared. Success involved creation of a complete solution, not just a description of the documents you need to create.

When I went to try to use the system as described by Doerr, I had multiple questions it didn’t answer. Just to start with, when and how do you make and update these OKRs? It’s great to say you should have this recording of your goals, but I could easily come up with multiple conflicting mechanisms for developing it, none of which are obviously better:

  • The CEO could develop them independently and deliver them to the team
  • The executive team could develop them collaboratively
  • They could be sourced from the front-line team

None of these is obviously right or wrong, and of course, neither are they sufficient explanations for how to do it. Do you do it one sitting? Multiple revisions? How long should you spend on it? How often should you update them? Can you change them mid-stream if your situation obviously changes? There’s a lot left to the reader. You can say it doesn’t matter, but of course, it does, and even if you’re right, you still have to pick one. Why go through the effort of describing the output but skip the whole process you used to create and maintain it?

Here’s how we did it.

Startup Days

Starting by reading John Doerr’s original presentation, even though it’s relatively thin. In summary, you should have three to five top-level objectives, and each of these should have a couple of key results associated with it. Together these constitute a company’s Objectives and Key Results, or “OKRs”. These should then cascade down to the rest of your team, so that each team and person has OKRs. This is a useful high-level tool for communication and focus, even in small teams. (Note that I’ll use ‘goals’ and ‘objectives’ interchangeably here; far more people use the shorter term in practice, and we treated them equivalently.)

At Puppet, we spoke of an operational rhythm, which is essentially the set of repetitious tasks we run and the cadence we execute them on to keep the business working. But the OKR system as presented includes no operational rhythm, no indication that people are involved in creating these goals or that doing so takes any time. So we invented our own rhythm:

  • As early as possible each period, the management team meets to decide the company OKRs. This started out as a 45-minute meeting that just recorded the goals that were in my head, but evolved over years into a two-day offsite where the leadership team first acquired a shared understanding of where the business was and what we needed to do, then built the goals from there. In retrospect we should have put in these longer days earlier; your team should frequently think deeply about what you should be working on, rather than just running all the time.
  • The rest of the company has some time to build its OKRs from the top-level goals. Initially this was a couple of days, but it eventually morphed into a couple of weeks.
  • These cascaded goals are then used to modify the company OKRs if needed. (In other words, we supported a merged top-down and bottom-up planning model.) This is when management would learn if our view of reality was materially different from that of the people at the front line.
  • At the end of every period, the management team records how we did against our goals. Again, this began as just writing down the score, but grew to become a more complete retrospective run by a project manager. This meeting it at most a couple of hours long, and just includes the leadership team.

When we began this process, we wanted short-term goals, so we ran this cadence eight times a year; thus, we called our planning periods “octaves.” As we matured and could think and execute in a more long-term fashion, we reduced this to quarterly.

I think this system is sufficient for most companies of 15 to 250 people. Some companies might grow out of this at relatively few people, whereas others might scale very well with it. I expect most people could scale this system successfully by gradually increasing the amount of time spent on each session, with more time in deep discussion, and also by assigning a project manager to run it. I ran the whole process until we were probably 250 people, which was a mistake that took too much of my time, resulted in too centralized of an organization, and limited our effectiveness because I suck at project management.

Note that these are pointedly not plans; that is, they are not step by step instructions for how to achieve a goal. We’re declaring what we want done, but not how we expect to do it. This is both a blessing and a curse. On the one hand, it provides a lot of freedom for people at the front line to figure out the right way of accomplishing something, but it also leaves a gaping hole in your organization. At some point, someone has to actually do the work, but where in your operational rhythm does a team translate goals into a plan for accomplishing them? Do you make that time? We didn’t until far too late, and it mattered.

Scaling

As we scaled the company and this system, we found a few critical gaps.

The biggest one is obvious enough that I cringe now just thinking about it. You would never try to build a product without being clear on who would do the work and, of course, you shouldn’t try to accomplish your company’s goals without assigning each objective and key result to an individual, yet our initial version (and the one presented by Doerr) had nothing to say on people. At some point we added the requirement that every objective had a name assigned to it, which was a huge change for us – and a really positive one.

The lack of accountability for each goal was exacerbated by the fact that we didn’t have any mechanism for in-quarter check-ins on the goals. We’d frequently only find out at the end of a quarter that a goal was going to be missed, when it was far too late to do anything about it. So we built a weekly operations review (“ops review”) where we reviewed progress against the goals. This meeting is a predictive exercise, not a status statement. Goals are green if you expect to accomplish them on time, even if you’re still two months away from the deadline. We mostly focus just on the areas we don’t expect to hit, which allows us to invest early in correcting our execution or changing our expectations.

It’s worth reiterating, because this was so hard to get people to understand: The goal of the ops review was not to describe the status of each goal; it was to build a shared understanding of whether we were likely to achieve our goals and then build an action plan to resolve the predicted misses. The majority of people entered that meeting with a belief that they needed to justify their paycheck, and it took a lot of education to get them to understand the real purpose.

This addition to our rhythm was pretty awesome. In one move, it basically eliminated the firefighting that had driven so much of our execution. We still had fires periodically, but they were actual surprises, not just sudden surfacing of old information, or realizing at the end of the quarter that a goal never had an owner.

The downside of the ops review is that it’s expensive (it necessarily includes a lot of top people at the company) and it takes a lot of work to make this kind of meeting worthwhile every week. I got the idea for this meeting from the excellent American Icon, about how Alan Mulally turned around Ford. A long, weekly operations review with his senior team was one of his key tactics. My team often complained that weekly was too frequent, but if a company as big as Ford was responding weekly to the conditions on the ground, shouldn’t a small startup be at least that responsive?

Around this time, we integrated the budgeting process into the planning process. It’s important to recognize they’re different — you should build the plan you want then find a way to budget for it, rather than building a budget for your departments then letting them decide how to spend it. It’s important that your should be good at both, though, and it was around this stage we started to develop the budgeting skill and learning how to integrate it into planning. That was painful, to put it mildly.

As we scaled, the company goals tended to get expressed in terms of departmental targets within sales, marketing, engineering, etc. When we were small, this seemed like a feature because it had natural lines of ownership, but as we grew it became clear it was a critical flaw. It’s important to translate plans to people and teams, but this was dysfunctional. It discouraged people from building goals that relied on other teams, and thus encouraged silos in the company. Talk about a failure mode. When we added names to each objective, we rebuilt the whole process to be structured from the top down around company goals rather than team goals, which allowed us to crack this departmental view and force shared goals and collaborative execution.

We also eventually added a layer of OKRs above our annual goals, giving us a roughly three year time horizon. These became crucial in sharing and deciding what the priorities were for a given year.

What might come next?

The above roughly describes the system as it stood when I stepped down from Puppet in 2016. It was obvious at the time that we were in need of another step-change in capability in our planning system, but the new CEO took responsibility for driving that. By the time I left, we could see many opportunities to improve what we were doing.

The big one is that we needed to push all the local knowledge about this process into code. We were using multiple different formats and tools, because different meetings require different interactions, and it was too difficult for most people to track what was happening, where, and why. For instance, our source of truth for the OKRs themselves tended to reside in Trello, but it’s a poor fit for storing updates and presenting the predictions of whether a goal would land. I couldn’t imagine trying to run a report on quantitive goals based on Trello data. Thus, we ended up storing the weekly updates in spreadsheets, which are exactly as powerful and readable as shell scripts. It meant we couldn’t trust most people to update the data, because the document was so complicated. I would have loved a single source of truth that anyone could use. In addition, I wanted to have an app automatically pull any data from original sources so I didn’t have team members doing manual work that could be automated (I mean, duh, Puppet is an automation company).

I also wanted a significantly better retrospective process that truly helped us improve the business by laying bare how our wonderfully laid plans went wrong. We were good at the work of looking back and being transparent about where we were, but there was a lot of room for improving how we tie that work to how we operate.

Lastly, I hate that our goals were built around quarters. I think having a cadence for building and validating plans is critical, but it’s silly that this cadence got translated into the timelines for the goals themselves. It often implied that each of our goals would take exactly a single planning cycle. Some obviously do — we have quarterly sales targets that we need to hit during exactly a quarter — but many of our top-level objectives were shoehorned into a quarterly system. I’d much prefer a Kanban-style on-demand planning system that would allow us to have a high-fidelity plan for what we’re working on now, and a quality backlog for what we’ll do as goals complete.

Conclusion

I’m not convinced it matters much what planning and execution system you use, but I’m utterly convinced you should have one. In the end, it’s merely a team-wide mechanism for developing, communicating, and tracking what you’re trying to achieve. It’s obviously important to have goals. I think most of us would agree you should, in some way, share those goals with the team so everyone is working toward the same ends. And, of course, your goals tomorrow should probably be somehow related to your goals today. (This is surprisingly hard.)

If you don’t have one yet, you could do worse than building an operational rhythm from what we built at Puppet. You’ll have to work through a lot of initial discomfort as you translate vague words into technical terms whose meaning is widely agreed upon around your team. But it’ll be worth it.