It Shouldn’t Get Easier

Anderson’s knife can cut anything, taking a chunk from everything in the land.

Master Terrence’s strokes remove less with each cut.

Greg LeMond once said, “It never gets easier, you just go faster.” This quote has been a rosary for me, a source of contemplation and meditation over the years. I think of it every time a new problem reveals itself as an echo of something I thought I already solved.

When I started Puppet, everyone I worked with stressed the need for me to recognize my position as founder and CEO, to bring people with me. The summer before I stepped down, more than a decade into practicing this skill, it still showed up in every coaching session. Not because I haven’t improved — but because it is a life skill that I can improve at every year and still die with more work in front of me than behind.

I found it incredibly hard to hire those first few people. I second-guessed myself, was slow, looked like a fool, felt an even bigger one, and finally made bets based on too little information. When I rebuilt the executive team in my last year, I second guessed myself, went too slowly, made what looked like basic mistakes, and felt incompetent the whole time.

This isn’t a coincidence. It’s not a sign of my incompetence. It’s the exact opposite: It shows that I never let things get easier, instead I kept my intensity up and always focused on going faster.

LeMond knew how to win. You train, you work, you focus, and all that effort delivers leverage. What you did yesterday when giving 100%, you can do today giving only 97%. What do you do with that 3%?

If you want to win, you reinvest it. In what? Counter-intuitively, exactly what got you that leverage in the first place.

For each and every one of us, there are two kinds of skills: Those it’s worth devoting our lives to, and those it’s not. A given pursuit can be less important because it doesn’t matter to you, because you’ll never be good enough at it, or because you just don’t like it. Those that matter, though, are a perfect intersection of your love, your abilities, and your values. They will reward any amount of investment by making you better at what you care most about, and are best at.

You have to love it because you really can’t devote the time and energy needed to dominate unless you like the work. You need at least some ability. You don’t need to start with a natural talent, but you are most likely to be rewarded for investing in areas that come easier than when you’re starting at the bottom. And your investments have to match your values. Some people care most about skills that earn them money, others about having an impact on people’s lives, and yet others want to build. You have to believe that what you’re investing in will help you spiritually, not just materially. It’s the only way you can convince yourself to work as hard as you need to.

Yes, there absolutely are things you will never be good at that you have to invest in. When I started Puppet, I was an outright liability in some areas, such as business operations. I had to get better at those. But I was never confused into thinking I would be great at them. That’s what team building is for.

Given two skills, one where you’re 8/10 and the other where you’re 3/10, where do you invest? Some might recommend the skill you suck at.

Not me. If that skill mattered, you would never have gotten hired in the first place. The reason you have a job is because of your 8/10 skill. Get 10% better at your weakness, and wow, you’re at 3.3/10. Big whoop. Get 10% better at your strength? You’re at 8.8/10. That’s a huge difference.

But getting 10% better in your area of expertise is fantastically difficult. It’s your life’s work.

I am suspicious of people who say the hard things are easy. What I hear is not that it’s easy, but that they’re not trying very hard. Or they’re too embarrassed to be honest.

Greg LeMond was the fastest cyclist in the world, but never stopped trying to ride faster.

Miyamoto Musashi won more than 200 individual duels with a sword, but never stopped trying to cut faster.

Excellence requires perpetual intensity. You should be confident enough in your strengths to admit that it’s hard. It should be hard. It’s the only way to get better.

Learning to Write

Reese’s keyboard produces truth of complexity and beauty, admired from a distance by all.

With a violent strike of Master Aaliyah’s pen, Jorge is enlightened.

I set out in January to study the realms of finance, software, and my own desire, but found myself adrift with no laboratory for experimentation. Programming was my testing ground for the hypotheses that led to Puppet, but my new questions cannot be answered in silicon. Clumsy studies provided two conclusions: Writing itself can and should be how I express and test my beliefs, but only if I get much better at it.

I started Puppet with core hypotheses, considered stupid by the experts around me. There was no point in talking about them; anyone can talk, and listeners similarly get to pick their conclusions. Only those I could prove had merit.

Proof is complicated. Few of us live in the world of math, where there’s enough overlap between objective reality and our language for discussing it that we can be truly sure. Computer science is itself lacking the unsentimental judge that the natural world provides to actual science. In truth, I should not discuss proofs, but rather disproofs. My real challenge with Puppet was to get rid of my false beliefs and let the remainders shine through, and there, programming was the perfect foil.

The best product idea in the world is worthless if it can’t be expressed in software in a sufficient timeframe. Merely building Puppet forced me to discard many convictions, and early rejects often became critical axioms undergirding the whole system. Of course, in the world of software, the compiler is only the first test. The real arbiter is your user, your customer. Once you’ve expressed your belief in a form someone can use, do they? I remember arguing for hours with a customer against a feature he requested, but the cold hard reality of his problem had me spending that night in my hotel room fixing it.

I am often asked if I miss programming. I do not.

What I miss is the laboratory it provided me, and the complete world that enveloped me, pressing in on me with its constraints, requirements, and complexities. I miss the hours I spent focused on one problem, and the complex systems needed to turn my ideas into a form usable by others.

I am thrilled and relieved to see that writing can be a new and even better laboratory for me. When I was programming full time, problems would haunt me, refusing to leave. I wore holes in my shoes walking back and forth between my keyboard and the local coffee shop, trying to line things up so they made sense. I’d scrunch up my face while drinking the coffee, drawing enqueries as to my wellbeing.

Writing is harder than that. The problems are bigger, and yet deeper inside, and harder to extract. I was never afraid of programming, but every idea I fail to write frightens me at least a little. On the far side, successfully expressing something is cathartic, a release, and it washes everything out with it.

It’s a better laboratory, because I have far more opinions about the real world than about the software world. Like those hypotheses that led to Puppet, I don’t know if they’re good. But I do know they’re different. I’ve bounced off reality enough times, asking for help from the crowd of onlookers and then getting back up, that I have a good sense of which of my beliefs are widely shared, and which are rare. For better or worse, little of what I believe, of what I think is important, is widely shared.

I’m excited by disagreement. Alignment is critical to execution, but diversity is needed for learning.

More than anything, I look forward to sharing my ideas, and as I did with Puppet, either finding them useful to other people, or having them cut to shreds to reveal new constraints, insights, opportunities. To do that successfully, though, writing is not enough: People must be able to read it.

Writing is no easier than coding, and in both, it’s ten times harder to write for others as for oneself.

One of my earliest optimizations in building Puppet was to prioritize my own productivity wherever possible. I explicitly chose to program in Ruby because I was faster there, even if it was slow and unpopular (Puppet was started before Rails was released). It took years for my programming style to reveal itself as an implicit personal optimization, highly effective for me but inscrutable to others.

My writing turns out to have a similarly mixed legacy.

All of the great shifts I initiated at Puppet began life as an essay, some extruded in a single sitting but more often sculpted over months and years. Once a hypothesis could defend itself, I then spent months and (more often) years translating it, turning it into something people could execute.

I’m proud of that work — how can I not be, when it helped build Puppet into what it is today?

But it’s fair to define good writing as something that doesn’t need a translator into its own tongue. By that measure, I’d failed.

Like a young programmer, I used to see people’s confusion as a sign of my genius and the value of my work. Now I look back with my designer’s eye and see it as a missed opportunity. We could have been there years faster if my beliefs had come with a better user experience. Kanies’s Razor is as applicable in prose as it is in code: Never attribute to genius that which can be adequately explained by incompetence.

I sit at the keyboard today as thrilled and scared as I was at the shiny benches of my science classes in college. Today I smell tea instead of banana oil and denatured ethanol, and I have no lab tech to stonewall me when I ask for easy answers, but the feeling of hope, of optimism, of a world to be discovered, understood, and fought through lifts me up just the same. I believe I can enjoy writing as much as I ever enjoyed programming, I can develop and test a wider range of hypotheses with a greater impact on those around me, and I can even learn get those ideas across to other people.

This, to me, is joy.

The Job of the Filesystem

It should do more so you can do less

Originally published at Hacker Noon

Apple just released iOS 10.3, which for the first time puts one of their production platforms on their new filesystem, APFS. I’m pretty happy that they are finally replacing such an aging, obsolete piece of core technology, but I’m nowhere near as excited about it as John Siracusa is. All APFS seems to do is finally meet the basic needs of a modern operating system, and not even all of those. It doesn’t come anywhere near doing what I care about most in the filesystem, which is owning metadata so applications don’t.

As anyone following the discussion of federal surveillance knows, metadata has become at least as important to our lives as our data. It’s not just the phone calls, it’s who you called, when, and for how long. It’s not just the phone, it’s which ones are your favorites and how they relate to each other. This metadata is as important to us personally as it is to the NSA, because it’s what brings simplicity, usefulness, and most importantly accessibility to the reams of information we create and rely on.

The reason I’m disappointed in APFS is that it missed the opportunity to promote metadata into something as important as the data, and as a result I’ve largely lost hope that computers will ever be as useful and open as they can be.

I’ve been trying for months to convert from Apple’s Photos to Adobe’s Lightroom for photo management, and the biggest barriers to doing so are metadata. It’s easy to get all of the photos — just drag the Masters folder into Lightroom. Oh, you organized your photos into albums? Yeah, that’s all gone. You had thousands of photos categorized as favorites so you could easily find the best? Oops, we ignore that.

Google Photos has the exact same problem. I can’t imagine how anyone who cares even a snit about photos could migrate to it, because there’s literally no way to do so that preserves any metadata at all. You get to keep the photos, but not how you organized them, and your only option is to rely on what they think matters to you.

Can you imagine switching email providers but losing all of the information about who the email is from or when it was sent? That’s as idiotic as what’s happening here.

If my filesystem owned this metadata, on the other hand, no conversion would be necessary. Any application could be written to read and write it directly, or I could trivially use any scripting language I wanted to do so. In fact, I could easily switch back and forth between different apps for different purposes, because they would not be able to lock me into their proprietary databases.

This shift is hard to understand, as we’re so used to thinking of applications and their metadata as somehow intertwined. For those in the programming world, there’s a clean analogy that helps to explain the horror of the modern filesystem:

For most of the history of software, applications have been written to directly access databases. They needed to understand the structure of tables and rows, and they had to write and manage their own queries for interacting with that data. Because of the complexity of duplicating this ability, applications tended to own their data entirely, and no other apps could get access.

We’ve recently instead seen a trend towards building very simple data services on top of databases, so that no app directly accesses them. This data service provides an API that understands how all of the data works, and also provides all of the key operations that can be performed on the data. This way, any application can access the data — for both reading and writing — without worrying that its use of the data is somehow incompatible with another consumer. You get the added benefit that any optimizations in the data service help every consumer, not just the one or two apps you remember to change.

Those data services are exactly what have enabled modern applications to scale to the level they do. The application developer can focus on their goals for the data, relying on the data service to provide consistency, portable operations, and everything else.

In the land of the operating system, though, we have no such luck. Everyone who talks to the filesystem gets about the thinnest interface imaginable: Get me a blob of data. Yes, there’s basic metadata (who owns it, when it was created, etc.), but none of it is or can be custom to the application, which makes it useless. Can you imagine how unpleasant it would be if we had to shoehorn both the subject of an email and the subject of a photo into the same keyword?

As a result, everyone turns that blob that the filesystem is trusted with into a database, and that’s where they put all of the metadata. Some even put the data there, even if it means huge database files and entirely non-portable systems. Really great app developers then go to the effort of building a full read and write API on top of this database that allows you to manage and port everything in the database. That’s enough work that most people skip it, though.

I would never have seen this missed opportunity in the filesystem if I hadn’t used BeOS. I went to Reed College, where Steve Jobs famously attended briefly (I made the unfortunate mistake of graduating, unlike him). This meant I was a Mac user all through school, which were the bad days of Quadras and MacOS 8 and 9. shudder I switched to BeOS because, well, I could, and it’s what really turned me into an OS junkie. There were many awesome things about it (many of which are now in OS X), but my favorite became how much responsibility the OS took for metadata. Applications became smaller, simpler, and in many cases, you realized your whole concept of an application was a way of organizing metadata, which meant you could rely on the OS entirely, and needed to write no code.

The greatest irony is that the author of Be’s awesome filesystem, Dominic Giampaolo, is now a lead engineer on APFS. Through the work of him and the rest of the team at Be, I came away with a clear idea of the value of my metadata, and especially the benefit of the operating system putting it on center stage.

So while I’m happy that my phone is no longer running the oldest, crappiest filesystem around, and I’m looking forward to the days when my computers aren’t either, I’m not excited. Until it was released, I could always dream that Apple saw the same future I did.

Now that the new filesystem is here, that hope is lost.

The Wrong Successes Kill Companies

Just because it’s working doesn’t make it right

Startups are in a constant life and death struggle, where a short succession of failures can destroy them completely, or a sudden string of successes can lead to growth and stardom. Exactly because of this constant risk of death, startups grasp at every flash of success, and their eventual failure can often be traced back to those successes they bet on, rather the roadblocks they hit.

This means what you decide to double down on is as important as the fires you decide to fight. This is true in any company — a specific form of this is covered in depth by Clayton Christensen in “Innovator’s Dilemma”, where successful companies over-solve their customers’ problems rather than finding additional customers. It’s especially true for startups, though, which are so risky that every potential customer, employee, investor, or partner can be the difference between making payroll and going bankrupt.

Steve Blank and Eric Reis have done a great job of teaching the world about the importance of quick learning and iterating until you get wins, but reality is more complicated. Say you’re in the middle of rapid product iteration and you get a rash of customers who sign up but are completely different from those you have been trying to attract. Is this awesome or horrifying?

How could new customers be such bad news, you ask? Easy: They could be the wrong customers. “Wrong” could mean many things. They could be from a very small market, such that success with them isn’t enough to build a scalable business; they could be unprofitable, in that they’ll be very high-cost to acquire and support, so every added customer loses you money over time rather than making it; and most commonly, they’re just not the customer your company strategy set out to find.

Eric Reis might say finding this kind of customer is the sign you need to pivot. That might be true. But it’s not automatically so. You were right enough to get this far, why give up so quickly on your definition of the perfect customer?

Because once you change your direction from focusing on the customer you want to customer you have — that is, once you start focusing on whatever seems to be working rather than your goals — you will quickly find yourself running a different company than you had planned.

This is one of the hardest problems for entrepreneurs: How do you decide when good news is leading to a better place, or a fatal compromise to your dream?

This came up constantly for me while running Puppet, in almost every part of my job. For instance, we did all of our high-growth hiring from Portland. Because of the small market and especially small tech sector, you have to be pragmatic about who you hire. You look up in 2 years, and you’ve got complete teams built off that first compromise hire. That first developer hire was a success, but changed your team’s direction. Now that that person has hired a team, or at least provided the template for the team, are you where you wanted to be, or completely off track?

You can argue that this isn’t a problem we would have had in the Bay Area, but not compromising when hiring is as pernicious a myth as true love. Even if you think someone is perfect, they’re still a real person, with opinions, behaviors, and habits that affect the destiny of your company, in good and bad ways. Again, the point here isn’t that you failed when you hired this person — the point is that the success you experienced changes your destiny in ways you can’t undo or predict.

That first customer started making feature requests and filing bugs, and two years later you’ve built something that can attract a lot more customers like them. Yay, or boo? There’s no right answer. I know one company that was almost destroyed by its biggest customer, and easily lost two years of roadmap progress focusing on them, but I know another company who built an amazing business by initially focusing on a couple of heavyweight customers.

When no decisions have been made, all life in front of you is opportunity. Choosing one opportunity inherently closes off others, and great decision makers know and accept this. If anything, sometimes a decision is great because of the opportunities it rejects, rather than those it selects. Running a startup is an accumulation of these bets, these selections and rejections. It’s hard to predict the consequences of even one of these big decisions, and it’s impossible to know what their legacy will be in a few years. You might end up exactly where you want… but you might be sowing the seeds of your downfall. That’s what makes the job hard.

The only tool I ever developed for managing this over the long term was to hold clearly to a specific set of goals, and to a specific strategy. When successes came along that didn’t fit our goals or strategy, we could decide to change them. But if we chose not to, then we essentially ignored it. It was a false positive. On the other hand, if you look up and a series of false positives starts to look like a trend you want to refocus on, then you must first rethink your goals and strategy, and only then switch your execution.

Or at least, that’s what I did. In truth, though, I don’t think I held the line enough. I think I was too willing to listen to people who were tactically great but didn’t buy into our strategy, and I was too willing to believe someone else’s expertise should take priority over my opinions. That doesn’t mean these were all mistakes, but it does make my time at Puppet easy to see through the lens of compromise and regret rather than the great success it really is.

In the end, when I look at how Puppet evolved, my sharpest pains come from compromises in strategy, and my brightest joys shine from a flawed execution in service of a pure vision.

The Binary Future of Software Companies

We’re seeing a rapid separation into SaaS companies and suppliers to SaaS companies

Software as a service is the most important technology business model innovation my lifetime, and before too long all important technology will be either provided as a service, or be an expert tool purchased in order to provide a service.

Software as a Service (SaaS) will not just restructure the entire economy of technology but dramatically improve it, because the rate of learning in a SaaS company is orders of magnitude better than for on-premise software (and oh my god better than for hardware). A really good on-premise software product is released and upgraded quarterly, meaning its fastest learning cycle is a 3 month cycle. A good hosted product is released tens of times a day. Twenty releases a day, times 5 days in a week and 12 weeks in a quarter mean that a SaaS company gets 1200 releases out in the time an on-premise company gets a single release.

Every release is a learning opportunity, which means a SaaS company can learn, and thus improve its user experience, more than 1000x more quickly than even a high-performing traditional software company. With this kind of difference in the rate of improvement, before too long anyone who isn’t a SaaS company is irrelevant. Literally — you can just ignore them.

Except of course that’s not true. If you’re a SaaS company, you can’t rely only on other SaaS companies; there are problems that can’t be solved off-premise, complexities that can’t be abstracted into a service, and technologies needed to provide your service that can’t be procured as a service. The most obvious example is that it all has to hit silicon at some point, and someone somewhere does actually have to buy CPUs, hard drives, and memory, with enough duct tape and baling twine to hold it all together and enough fans to cool it all down. While this is one obvious exception, there are plenty of others.

Thus, even with the learning rate of SaaS companies, and the resulting obsolescence of most other kinds of tech providers, there is still room for those who sell to the SaaS companies. This is somewhat akin to the ’49 gold rush, when there were gold miners and those who sold to gold miners. Both were valid pursuits, and tightly entwined, but they were very different businesses.

In the early days of the software world, and especially the early days of the enterprise IT department, every company evolved to be mediocre at any kind of technology, and they all looked pretty similar. They could do just about anything, and they sold to pretty much everybody, but they couldn’t do anything particularly well. This impending world of SaaS companies hires only experts; they are absolutely fantastic at everything they care about, and they have an equally fantastic service partner to whom they can outsource anything they don’t care about.

In some ways, this world is even more dangerous to the status quo of the technology industry. Our entire industry has evolved to sell to generalists: We build pretty decent stuff, and sell it to people who are ok at managing it. Our stuff can’t be too great, because great stuff requires expert users, and we can’t demand too much of our users because they have to be competent at nearly everything within a very large field (“networking”, “hardware”, “applications”), so they can’t invest in being particularly excellent at any one thing. Also, great stuff would be really expensive, and companies don’t buy expensive stuff, because no particular investment is all that important to them.

In this new world, there exist only experts, whose entire mandate is to specialize in the specific tools and technologies that will allow a SaaS company to excel, to win. For the investments that can make a real difference, no cost is too high, and no expertise is too narrow. For investments that can’t make a real difference, of course, we just find a service partner who cares so much about it we don’t have to think about it. Thus, as a SaaS company, I only invest in technology when I can afford to invest in experts, and I immediately reject any technology built for generalists because I can’t achieve outsize results with tools built for generalists.

Here we reach a future where there exist only SaaS companies, and companies who build expert tools for narrow use cases that exist within SaaS companies. Anyone else is fiercely riding a bicycle while watching a train recede into the future. The pundits of today are correct that the cloud is the most important trend of the modern era, but they’re wrong in thinking that AWS or Cloud Foundry hold a candle to the restructuring that SaaS will wreak.

Start With the Dangerous Questions

Throughout my 12 years as CEO of Puppet, I made critical decisions that affected nearly everyone involved in the company: What investors should we work with? Who should we hire? What products should we build? Should we take that deal with a customer?

These decisions are scary. Getting them right can be a huge lift for a company, but getting them wrong can destroy one. I worked at a company that lost more than a year of growth and roadmap development because they signed their largest customer ever. One of my advisors told me a payment of more than one hundred million dollars from a partner destroyed his company. I’ve also taken big risks on key employees, and had some of them work out fantastically, and others flame out spectacularly.

We’ve all been there. You’re in an interview, the first of many discussions with a candidate. You’re focused on building rapport, getting an overview of their career, but some niggling fears are pushing down on your sense of comfort. What do you do?

I know what I used to do, and it didn’t work. I’d focus initially on an overview and getting to know them, then I’d dive deep into their experience and skills. At that point I would find I still had fundamental questions I need answered, but it’s a bit awkward to ask these basic questions in the 3rd interview, isn’t it? Awkward indeed. You either take the risk and hire without those answers, or you take the loss and reset, looking like an amateur. I’ve done both of these more times than I can count. Just talking about it brings up again the anguish I’ve had in those late meetings, realizing there were critical questions I didn’t have answers to, and I just didn’t know how to get out of there.

So I flipped it. Now I chase the fear. I pin it to the wall, and I scrutinize it until it withers away or takes over the room.

With customers, one of my scariest questions has always been, “Why are you buying our product?”, as if merely asking them would cause them to reconsider. The only thing worse than losing a prospect, though, is having the wrong customer sign up. I’ve had customers who I spent hundreds of thousands of dollars supporting who never succeeded with the product and then didn’t renew a year later. Some have signed up then complained incessantly that we don’t have the features they need. I’ve said yes to a painfully low-priced deal to land a big customer, only to have them change all the terms at literally the last minute because they know they have us over a barrel. These are all signs that someone should not have signed up with you, that you have a mismatch you’re dodging.

I have hired people with time at important companies during critical growth years, and then found out later for all their knowledge of the events, they weren’t remotely involved. That was early in my experience of hiring — I’ve since learned to ask, “Yes, but what exactly did you accomplish while working at that great company near those great people?” I don’t care if a previous employer did great things, I care if you helped them do great things. Otherwise, it’s irrelevant.

This change in practice was initially frightening, and felt almost like I was breaking the social contract. I’m already hard enough to get along with, and not a person people usually enjoy interviewing with. I also have great loss aversion, especially when trying to convince a talented executive to move to Portland. The truth is, though, if you aren’t going to move, I should learn that in our first conversation, not after I’ve put 30 hours into interviewing you only to have to reject the offer because you can’t pull your kids out of school. I understand, but shouldn’t we have learned that together earlier?

Once I forced the conversation through these risky channels, though, the rest of the work is done without much fear. We quashed all the really scary stuff in the beginning. Even better, because we’ve walked the deep dark forest together and come out the other side (assuming we have), we understand each other better, trust each other more, and all of our conversations are tinged with that greater knowledge. When I recently went to hire a CFO, I rejected multiple highly qualified people very quickly because they were looking for the badge of leading an IPO rather than wanting to help build a great company. That’s not necessarily bad, but it’s not what we were looking for.

The best thing about this technique is that it’s good science. I have a chemistry degree, and I really kicked myself when I realized how inconsistent, how unscientific I was when making decisions. In some areas I experience no real loss aversion, so I can dig right into the scary stuff, but in hiring, signing large customers, and a few other areas, I found that the fear had been too strong and I kept tying myself in knots. Once I backed away and considered any candidate, any decision as a hypothesis, and then looked at my questions as experiments trying to disprove that hypothesis, the answer was dispassionately clear: You must run the most dangerous tests first.

Sure, you can do a bunch of simple experiments that are highly unlikely to prove you wrong. But if the 9th test was always the most dangerous one and your hypothesis fails there, then you just wasted a lot of time and paid a high opportunity cost.

The objectivity that came from looking at this problem through a scientific lens helped me recognize that my loss aversion was making my decision making much worse. I didn’t so much learn to operate without fear as learned that the fear was rational and was a useful signal. It gave me the strength to pursue that fear, rather than hide from it, even in the scariest areas.

Maybe you aren’t hiring people, or seeking investors. But I know you make key decisions, decisions that affect you and those around you. If you don’t get out of your comfort zone and ask the important questions, not just the easy ones, then you’re basically filibustering your work: “Well, we’ve run out of time, guess we’ll just have to skip those questions.”

If instead you can find a way to focus first on the scariest parts of those decisions, the parts that can least stand the light, then I think you’ll find you make higher quality decisions, you will enjoy the process more, and you’ll have better outcomes for everyone involved.

Your Whiteboard and Post-Its Aren’t Kanban

Kanban is an incredibly useful productivity tool, initially developed in Japan on automobile manufacturing lines. It has since become a widely adopted practice, including in software development and project management. Or has it?

That cute, simple tool you have that uses post-its, or skeuomorphic representations of them, to keep track of the state of some task or project? It’s not Kanban. To paraphrase Bill Hicks: No no no, I know you think it is. But it’s not.

What you have is a useful means of task and project management. It might be awesome. It might be saving you effort, time, and stress, and actively making your life better. I’m sure it’s a good tool, Brent. But it likely has nothing to do with Kanban.

To be clear, that’s fine. There’s no rule that says Kanban is useful to solving your problem, or that you ever need to use it. It’s just, you know, words have meanings. And the meaning of Kanban is all about inventory management. It’s true that you totally could be using post-its on a whiteboard to track inventory. But you’re probably not.

In both your task tracker and in Kanban, the card represents something. That is, the card itself is not relevant, but it represents a thing that you care about. In your tool, it’s representing some task that someone needs to do and the state that the task is in. This helps you to understand and communicate key information across all of your tasks, projects, and teams. I can see why you find this useful. Heck, I find it useful. I’m using it to track the state of this article, for instance.

In Kanban, the card represents something completely different: The need to refill inventory. At its simplest, you use cards to denote the minimum allowable inventory in a system, such as car doors sitting at an installation station. You do so by literally placing a card on the door at the minimum level. You pair these cards with separate rules about the maximum allowable inventory. Now each of your inventory pools (doors, engines, seats, etc.) have maximum and minimum levels — if the inventory gets low enough, the installer encounters the card and orders a refill, which itself is never above the maximum allowed. As you operate the system you tune it over time to make sure your min and max levels are right.

For most of your work, you can ignore the card and focus on what’s in front of you, but as soon as you encounter it, you must take action. This gives you two features that are otherwise lacking: You get to ignore the card and focus on your work for the majority of the time, which is incredibly important for productivity, and you also get to explicitly separate the process of optimizing the inventory pools from how you consume them. You can always be in the moment when you do the work.

On first blush, you might think to yourself that this doesn’t sound very useful. I mean, how much of your life is really affected by inventory problems? Pffft. Literally all of it. You deal with this constantly in your car, for example; its maker decides on your maximum fuel level (the tank is fixed in size), and you never want to run out of gas, but instead of a card you have a light on your dash when it gets too low. Obviously every grocery store and restaurant has to think about this, but so do banks (envelopes, paper, checks), mechanics (parts, tools), and coffee shops (coffee, chairs — yes, chairs).

You have personal inventory problems, too. We keep hearing about these magical fridges that will order milk for us automatically (but are more likely to be used in a DDoS); Amazon has released one-touch buttons that enable us to trivially order new inventory; and most of us have experienced the ignominy of running out of a key supply at just the wrong time, such as when using the toilet. To see these problems for what they really are, you need to step into a different mental model, a new world.

You need to step into the world of inventory. Rather than seeing everything around you in terms of work to be done, see it in terms of pools of inventory to be shifted, consumed, and refilled. It’s not necessarily “better”, but it is often enlightening. Kanban got created as a tool specifically for increasing the efficiency of such a world, and only makes sense when you’re in it. In fact, the cards themselves aren’t important at all — there are plenty of different triggers available.

It might shock you to realize just how much of your life would be improved by viewing the world this way. Suddenly all of those latent tasks that are sudden emergencies when you run out of something become simple efficiency problems that are easy to model and solve. In my last few years of experimenting with this in my personal life, I’ve built many triggers into many of our inventory pools. None of them are cards, but they are all closer to Kanban than your Trello board.

For example, we go through a lot of granola in my house. Our means of ensuring we never run out is to have two containers, about the same size. We always pour breakfast from one and refill from the other, and the emptying of our refill container is the trigger that causes us to buy more granola.

We keep one in-use and one unused toilet paper roll in each bathroom, plus a cache in a closet. Emptying the in-use triggers using the extra roll, which triggers pulling another roll from the cache. If that is the last roll there, pulling it triggers buying more.

In each of these cases, we’ve set up inventory pools that match how long it takes to refresh them. For example, our granola containers are sized that so that we don’t go through a whole container faster than it takes us to buy more. We never run out of toilet paper, but we don’t have to dedicate a room to storing it.

This perspective also allows us to recognize when we are missing a trigger to refill inventory, allowing us to shift the conversation from personal blame to process improvements. For example, in a bid to teach our kids to self-regulate their sugar intake, we’ve started making our own fruit yogurt and letting them add sugar, rather than buying pre-made fruit+sugar yogurt. We kept running out, though, because it took a day to thaw frozen fruit. We didn’t have an appropriate trigger to start this task at the right time. Having recognized this problem, we created one (I get frozen fruit out to thaw when we have about one meal left of pre-mixed yogurt), and on first blush, it seems to be working. We haven’t yet integrated it with one that buys more yogurt on the right cycle, though, so it’s not yet a complete system.

These are examples of using non-card triggers for Kanban-style inventory management. It’s the triggers that matter, not using cards to represent them. If we tended to have larger collections of unit inventory, cards might be appropriate. E.g., I usually buy razor blades in bulk, and it might be appropriate to label one of those blades with a card to trigger repurchase when I reach it in my stack. Here I’d have to find the right optimization between managing a large inventory, finding the right trigger, and getting the lowest cost per blade (which requires buying in bulk). Combine that with the fact that I usually use an electric razor (which means I rarely assess the state of my blade inventory) and the likelihood of making an inventory mistake goes up, thus increasing the value of a trigger-based system.

For all that I love tools like Trello, and systems like Kanban, I’m not sure they can ever actually be used together. That is, I think we have a whole industry of tools built to model a specific kind of problem, which are instead useful for many things but specifically not the problem they’re meant to exemplify.

The beauty of Kanban is that it’s out in the world, where your work is. (Don’t be confused into thinking that that board or those cards are your work; they just represent it.) I’ve been trying for years to build a Trello board, or some equivalent, that enables an inventory-oriented view on what I’m trying to do, but I’ve not yet succeeded. For instance, [WIP limits] mean something completely different when they represent tasks instead of inventory. That doesn’t mean they’re useless, just not useful for the same reasons.

My recommendation is that you enjoy your task management system, and continue to get what you can out of it. Maybe just stop calling it Kanban. At the same time, though, ask yourself: Where are the inventory pools in my life? What do I run out of, and how can I build triggers at the right point to prevent that? How does my world change when viewed this way?

Most of all, get out into the world. That’s where the work is.

I’m Often Asked

Since these are questions I’m often asked, I thought you might be interested in their answers.

How did you get from a hippie commune to starting a software company?

I was born on a hippie commune in Wisconsin, then moved to a related one in Tennessee when I was 4 (this was “The Farm”, best known for having produced Spiritual Midwifery, a book that was a major contributor to reviving midwifing in the US). When I was 8, I cut a foot of hair off my head and began attending public school in Nashville, Tennessee as a vegetarian who’d never heard of capital-G God.

Suffice it to say, it did not go well.

Much later, as I worked my way through college, I realized that my coping mechanism for dealing with the stark conflict between those two cultures was to literally forget everything I knew. It was then I realized I only retained a few memories of my childhood on the Farm. Given contradictory but unverifiable information — and Nashville and the Farm were definitely both — the only reasonable response is to discard it all. That explains why I didn’t trust the kids in 4th grade who told me I was going to burn in hell for 10,000 years because I wasn’t baptized, and it also explains why I do not resemble someone raised on a hippie commune.

I graduated from high school a year early, mostly to escape my incredibly violent 3,000 person high school run by jocks. I didn’t exactly have role models to show the real possibilities of what going to school can do — nearly every adult I knew went to college, but I knew I didn’t want to use my degree to build shoddy houses and dig outhouse holes in the woods. When it came to picking colleges, I eliminated all schools that had fraternities, sororities, or organized sports (because I wanted my school run by the geeks, the nerds, the brainiacs), and then I picked the best school I could find the furthest from my home town.

I looked at schools in Alaska, but the one I found that fit the criteria was too small at 400 people. It never occurred to me to consider overseas schools. Then my home room teacher pointed out Reed College, in Portland, Oregon. I’m sure their whole book was useful, but the only bit I remember was how their Guerrilla Theater of the Absurd ingested red, white, and blue mashed potatoes in preparation for a visit by then-vice president Dan Quayle, and then threw them up at his speech. I was in. That was a whole different kind of patriotism than they practiced in Nashville.

I was too poor to visit any schools, so I showed up at Reed having never been on the west coast, or within a thousand miles of Portland. The black and white photos in the school book didn’t quite capture the place. Seeing the campus for the first time is unquestionably the first time I remember honestly crying for joy.

One of the first things I did there was buy a computer, and one of the last was decide not to be a scientist.

How did you get from a chemistry degree to starting a software company?

I had seven jobs in two and a half years at the end of college, so I tried a lot of things. I got fired a lot. Until my last year, I was planning to be an academic scientist, but Reed did a great job of training me on exactly what that job entailed, and the result was that I didn’t want it. For all that science is all about trial and error, they don’t actually allow much failure in your career — you better pick the right boss, the right school, the right project. Anything else means you can’t get the grants, because there’s just too much competition for too little money.

Once science was out, there weren’t a lot of other great options. I am not one of those who grew up with a computer; I didn’t get one until my sophomore year in college, and taking a loan out for it is one of the first things I did in school. I had spent a lot of time playing with my computer, and I found I was particularly adept at breaking it. When are you most likely to break it? When you’re procrastinating. And when are you most likely to procrastinate? When you really, really need your computer to work because there’s something big due the next day.

This meant that I also got pretty good at fixing it quickly. Or maybe, setting it up in such a way that it was always easily fixable.

When it came time to look for work, this is pretty much what I had to go with: A science degree, and facility at breaking computers. That led to a QA job, a couple of mac admin jobs, and finally a support job, which soon turned into a Unix administration job. Most of those jobs I was fired from (who gets fired from the Plaid Pantry?), but the last one was a great fit for me, and I only left because I was moving to Nashville.

Once I got there, I continued my investment in scripting and automation, which two jobs later resulted in my being a consultant, having worked myself out of a job. I quickly concluded I could make good money at consulting but hated the job. I thought about an MBA, because the badge is useful, but I didn’t think the schooling would be. I almost went to law school, but then I realized it’s so expensive you have to become a lawyer afterward, which I didn’t want. So, I did the only thing left: I started a software company. I figured I’d learn more failing to start a software company than I would succeeding at getting an MBA.

Puppet wasn’t my only idea — I’m still pretty enamored of a software product I wanted to build for scientists — but in the end I concluded it was the one I was most likely to succeed at, based on my own knowledge and on the market. In the end, I started Puppet to get out of system administration, not because I loved it.

Did you ever think Puppet would get this big?

I always knew it was a possibility, but I never let myself get hung up on whether it would happen or not. Any given situation has many possible futures, and it’s generally unwise to be too attached to any one of them. With Puppet, I was always committed to some of the constraints, but generally not so much to the specific outcome, and certainly, I didn’t spend much energy trying to predict it. With the right constraints, I hoped we would end up in a good place, which was the most I could hope for.

In terms of those constraints, they were things like maintaining a high quality business, where deals were good deals and customers generated real revenue, where we focused on the user and not the buyer, and where we maintained our authentic voice even in marketing.

That being said, I did think that Puppet could succeed, and in a big way. I knew the market was measured in the billions of dollars a year, and I knew it was composed primarily of bad software sold by dying companies. Someone was going to come in and take business away from those companies, take users away from them, and I saw no reason why it wouldn’t be me.

“Someone has to do something, and it’s just incredibly pathetic that it has to be us.” — Jerry Garcia

Did I hope for something like this outcome? Heck, I hoped for more, faster. This is one of the better possible futures Puppet had when I started, but there were far better futures available, and it’s tough not to see those and ask, “What if?”

In the end, though, I am incredibly proud, pleased, and surprised by what we were able to accomplish. I know how lucky I am, how rare this outcome is, but I also know that it wasn’t entirely accidental, that I started at the right time with a good idea, a good market, and a pretty decent plan, and I worked intensely while passing up many opportunities to make mortal mistakes.

Why That Startup Advice is Useless

Starting companies is a high-risk enterprise, especially so for high-growth, venture-backed companies, which fail more than 90% of the time. Yet people generally talk about successful companies as though their achievements are somehow inevitable and reproducible. We look at Google, Netflix, and Amazon thinking that if we can just copy their practices and decisions, we can also achieve their outcomes. After all, their actions are clear-cut (in most cases), as is their success; what’s missing?

Yet, no amount of studying these companies has significantly increased the win percentage. Part of that, of course, is that every startup is studying the same playbook. I think the bigger part, though, is that we don’t talk about high-growth companies in a way that really reflects the experience. In years of researching growth companies and talking to leaders of thriving and failed enterprises, I’ve found that even the best companies went through what seemed to be life-threatening experiences, and in general, you couldn’t tell from within the company that it would achieve the success that it eventually did. The steps to prosperity are obvious in retrospect, but their rightness is nearly always concealed when looking forward. What follows is a metaphor that helps to explain why it is so hard to think about this clearly.

When we look at a successful company, we can clearly see the path it followed to get where it is. You can look at the key decisions or hires they made, the practices and habits they adopted, the market forces that affected them (or didn’t), and how they worked with and around key players. I call this the ridge they walked. We can look back and say, Wow, that one decision, or person, or market change, really made the difference. What if Google hadn’t gotten ad selling just right just then? It doesn’t matter, because they did. What if Amazon hadn’t invented S3 when they did, giving them the freedom to create all of AWS? It doesn’t matter, because they did. What if Netflix hadn’t been brave enough to switch from DVD distribution to online video? It doesn’t matter, because even though they made some missteps, they made it through.

Looking backward, that ridge is clear.

However, in all of these cases, and countless other equally critical events for these same companies (and for every other growth company), they couldn’t see then what we see now. What they saw then is what everyone leading a growth company sees: an infinite expanse of uncertainty, akin to a field of ice that you have to pick a path across. As the leader of a growth company, you have to believe that there is a path across that ice that leads you to (at least temporary) success. Your job is to find that path. As the company progresses, the ice alongside you falls away. If you are lucky, you are standing on solid ground and it’s only the ice on either side that falls away, leaving a clear ridge behind and below you. If you are unlucky, you picked wrong; you step off the ridge and the ice cracks. If you are really unlucky, there wasn’t any solid ground anywhere, and you’ve led your company to an ignominious end where everyone suddenly realizes the whole company is built on thin ice. Everyone laments the massive mistake that is now suddenly evident. But crucially, until you took that step, the difference between your path and one that was successful was invisible.

I don’t mean to imply that leaders have no visibility into the likely success of their work, nor that the only way to manage risk is to plow forward and hope it works out. This analogy does, however, help to explain why seeing someone else’s clear path to success isn’t nearly so useful as we’d like in helping us navigate the infinite expanse of ice in front of us. It might be that working in small increments and building a lean organization will make the difference between small, correctable errors and catastrophic mistakes, but it might not. Building a great advisor network of people who have done it before might be exactly what you need to navigate the ice fields of entrepreneurship, but no one gets to navigate the exact same ice field twice, so they might just as easily confidently lead you to a crevasse that didn’t exist when they ran this race.

Note that no matter who you are, and how well you’re doing, at some point you will hit a growth wall. All marriages end in death or divorce, and all great companies end up getting bought or going flat in growth, because infinite growth just isn’t possible. At this point, everyone will suddenly say they could see it coming all along. Well sure, you did too. It was one of the possible futures.

When you look to understand a growth company, either because you are hoping their lessons will increase your chance of success, or because you want to share the key lessons with others who are striving, you get limited utility from studying the ridge of non-deadly decisions behind someone. Equally useless is studying the infinite expanse of deadly but featureless ice in front of an organization.

Instead, to get the most out of studying a company’s success, you must live their experience at that seam between the proud success behind them and the scary uncertainty in front of them. It’s not useful to simply understand that Intel pulled off a massive strategic shift in switching their focus to microprocessors. The real value comes from examining what state were they in at the time that enabled them to make that decision. Oh, it turns out that they were having their clocks cleaned by competitors in memory, and microprocessors were already generating a lot of their revenue, so it was less about switching focus and more about shifting identity than business. If anything, Intel failed in making fast enough a decision that observers and many insiders knew was right. When you frame the decision that way, it seems more manifest and relatable. The important lessons are about emotionally wrenching identity changes and making correct decisions with urgency, not some sort of prescience about how the market was moving.

We so often ascribe some kind of mystical foresight to great entrepreneurs, when in fact, they suffered just as any of us do, but for whatever reason, had a different result. The founders of Google had no pretensions to organizing the world’s information, and instead desired to sell their algorithm. They started the company only because no one took the algorithm seriously. Mark Zuckerberg had no particular interest in building a social graph; he was just rating girls on the Internet. He built a company after it became clear he had lucked into something great.

And perhaps most notably, Steve Jobs is considered the exemplar of tech industry triumph, as evidenced by the early success of the Apple I and II, the truly innovative Mac computer, and the wild popularity of Apple products in his second stint with the company. However, to focus our attention solely on these successes overlooks many key aspects that limited or propelled his achievements. For example, the Mac shipped so late and was so expensive that it was functionally irrelevant for a long time, and the rest of the industry caught up. Would a wiser Steve Jobs (or you, having internalized his lessons) have shipped earlier before the competition claimed the market? Would he have made compromises to bring down cost and make the Mac less of a specialist device? Would he team up earlier with someone with operations chops, freeing him to exercise his product design prowess? Can we learn these lessons without spending the decade in the wilderness that Jobs did? Only if we examine his steps and choices in their actual ice-field context rather than with the 20/20 hindsight we tend to use when canonizing our heroes.

In retrospect, the right answers to these questions are often easy and obvious, but the full context that was necessary to see those answers wasn’t available to anyone at the time. We build myths about why people did things, or how evident greatness was at the time. Those myths are not just wrong, they’re pernicious. The simple truisms they provide keep us from examining the real motives and conditions that were in play, and obscure the truly useful frameworks that we can apply to our own situations. They also dramatically underplay the role of luck in success.

Building greatness is a miserable journey, largely because you’re trekking over an infinite expanse of ice with unknown thickness. So much of greatness is being willing to continue pushing forward, even in the face of fear and uncertainty. We do a disservice to people who did important things if we act like fundamentally tough decisions were obvious at the time, or that great entrepreneurs had a single good idea that led them to greatness. In truth, the successful entrepreneur grows their knowledge and experience in ways that no one else can replicate.

I hope that in the future, people will look back and say I built a great company. I hope they laud my good decisions and lambaste my stupid ones. But I also hope that people are honest about the fact that I started the company with small goals, and only through success was I able to build larger goals. I hope that my decisions are studied within the context of hope, fear, and experience that I made them in, rather than their historical obviousness.

Developing My Future

Those who know who I am are likely aware that in September I stepped down as CEO of Puppet, the company I founded, and whose first product I built. The question everyone asks these days is, “What’s next?”

However, I am committed to not committing to anything until at least the fall of 2017, which means I couldn’t answer that question even if I wanted to.

As a result, you have an opportunity to watch and participate with me as I take this journey. Along the way, I’ll be trying to share what I have learned and what I believe, and to the extent I can, my thought process as I figure out what’s next. If you follow along, I expect you’ll be informed, sometimes entertained, and at least periodically offended.

Taking Time

Part of my reason for delaying a commitment is that I want to spend the summer traveling with my family (a summer where both parents are unemployed and have some cash is a privilege and luxury I’ve never had and don’t expect again). Primarily, though, it’s about giving myself enough time to think deeply about what I want to do next, and why. By the time my last day at Puppet rolls around in March, I will have been working on Puppet for 12 years, full time.

Most people seem to think I started Puppet (or, more insultingly, I decided to turn it into a “real company”) when we first got investment in 2009, but in fact it had been my full time job since March 2005, and we were ramen-profitable by the end of the first year. Even before that, I had been doing sysadmin work full time since 1997, which means 20 years in one industry. Talk about a monogamous relationship! It’s impossible to spend that much time in one area, and then immediately pick a new direction that isn’t encumbered with biases resulting from such focus.

I am truly thrilled not to know what I’m doing next, to have the opportunity to explore ideas without a strong gravitational pull or a narrow time window in which to work, and just to be in a state of high uncertainty where I can pursue curiosity without worrying about how it relates to commitments I’ve already made. I am quite confident, though, that I will not be starting another company in the infrastructure space.

There are multiple areas where I think I would be excited to start another software company (most of them somewhere in the productivity space; if you squint, even Puppet qualifies as a productivity tool). But I’m also interested in helping to create many companies, not just one, which makes investing, advising, and board membership interesting. Diversity, especially in the tech world, is a huge priority for me, so it would be great to find some way to contribute meaningfully there. And whether I want to or not, I expect to spend some chunk of my time learning how to be productively involved in our civil and political discussions. Heck, some part of me feels guilty for not investing all of my energy there.

About the only thing I can promise is that whatever time I put into companies will almost all be focused — whether investing, advising, or operating — on helping individual people spend more time on the things they care about and add value to them, and less time on the menial work that gets in the way. That could take the form of productivity tools, automation, or management tools, for example. I’m generally more comfortable with B2B models, because I understand better how to build a business there, but I’d love to help build great tools companies for consumers that aren’t ad-driven.

If you’re interested in following along at home, I’ll be writing in this space as I pursue this decision, and hopefully after. My goal is to write often, and on any topic that strikes me, but you should expect to see articles on technology, finance, people, and the industry, with a periodic dose of just me being a person. I have many hypotheses right now, and not a lot of data, so I will be quite surprised if this space looks in a year like I’m thinking of it today.

My hope is that my writing is more about what I learn and conclude, rather than sharing my personal journey, but don’t be surprised if some of the articles are more about me than the industry.

For those who do decide to follow along, I hope you get some value, some interest, even some excitement from some of what I write. I also hope you’ll share with me anything you think is related, intriguing, or just confusing in topical areas. The best place to find me at this point is on twitter.

Thanks,

Luke