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.
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.
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.
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.
You probably believe, like so many people I’ve talked to, that you learn more from failure from success. Unfortunately, that’s total bullshit - in general, the only thing you learn from failure is, of all the ways you could have failed, you have discovered one of them. As a result, you’re wasting your time, making yourself and the people around you less happy, and losing the opportunity to be better, faster.
I used to believe this, too, but I’ve since learned that success is dramatically more important than failure, which has made me a better leader, friend, and father. In fact, I’ll show that you agree with me, even if you don’t realize it. If you can briefly invert what you’ve likely heard and said so much, this essay might just help you achieve more success, and be happier while on the path.
You Don’t Believe It
I’ve got a simple proposition that makes this really clear, but I also want to go deep in a couple of areas to explain why this belief is not just wrong, it’s dangerous.
Let’s say you’re building a garage (which, it turns out, I currently am), and you have two contractors to choose from: Someone who has attempted to build ten garages, and has successfully built ten garages; or someone who has tried to build ten garages, and has successfully built zero.
Obviously, you and everyone you know would hire the person who has experienced more (or rather, any) success building garages, and you’d ignore as a quack the person who couldn’t even build a single garage. But I thought you learned more from failure than from success?!
There are a bunch of other obvious examples. Do you want to learn basketball from Kobe Bryant or a basketball player who got dropped in college, you go for the one with success? Does your restaurant belong on a popular street with other successful restaurants and lots of reasons for people to visit, or a desolate strip where no restaurant has succeeded? Even, do you fight to take control of a busy drug corner, or try to convince users to go to a different corner? (Yes, I’m watching The Wire.) Should you emulate someone who has started 5 companies and never made any money, or someone who’s started one and built to a billion dollar company? There’s a reason we lionize the founders of Google et al, but can’t remember who started Webvan, much less any of the thousands of people whose companies never even got off the ground.
Why is it so alluring to think we learn more from failure than from success? A lot of it comes from the value of studying failures, both your own and others. The fact that you learn more from success doesn’t mean you can’t learn from failure; often, the only way to succeed is to study the failures, because, funny thing, in the beginning failure is all we usually have.
But don’t let that confuse you into thinking failure is somehow more worthwhile than success. When you fail, you often get stuck - you can’t move forward until you’ve fixed it. You lose time, momentum, and more. When you succeed, you can move on to the next step in your project, but more importantly, you have a single thing that you know works. There’s always a chance something else works better, and you might conclude at some point it’s important to improve what works (I’m always worried about local maxima), but if you’re failing, you can’t even start to worry about that.
Not Just Wrong; Dangerous
Think about your behaviors if you’re focusing on the failures instead of the successes. You’ve got a big sales team, a broad customer base, or even your own child. There’s always a wide variety of success and failure across your team, or even within an individual. If you focus on learning from failure, you’ll spend all your time with the failing salespeople, the pissed off customers, or the part of your kid’s life where they’re struggling.
Contrast that with focusing on success, on what works. You spend all your time with your best salespeople, ensuring they’re closing better deals even more quickly, and you learn from them what helps them outperform, so you can bring it back to the rest of the team. You work most closely with your happiest customers, figuring out what they love about your product and how you can find and create more customers like them. You’ve also spent a ton of time with your kid in the areas where they’re strong and awesome. They get to build life skills, and enough self-confidence they can more easily tackle the problems they’re not as good at.
In all of these areas, the individuals who are most important to you know you care about them, because you’re spending time with them, and they know you respect and appreciate their success because you’re focused on what they’re great at.
Think how your best people feel if you show up and instead of talking about the great deals, successful usage, or artistic talent, you only ever discuss their failures - “Because you’re focused on learning from failure.” Really?
Yet this is exactly the naive behavior of many managers, product managers, and parents. You ignore your best people, you ignore the things that are working well, and you force successful people to wallow in the misery of their failures.
Route Around the Failure
It’s not just that you should be more focused on the things that are working than those that aren’t; it’s that, in general, you should just literally ignore the failures.. You’re standing at a golf tee and you hit 20 balls. Most of them go wild and do stupid things, but one connects cleanly and lands on the fairway. Who cares about the other 19? Just figure out how to copy that 20th shot every day!
Obviously it’s not possible to ignore all failures, but when you can, it makes a ton more sense to just keep iterating until something works, without really making any attempt to understand those things that aren’t working. You try something 20 times, and only one works? Awesome! You found something that worked! Run with it.
Nature fully understands this. Nature cares nothing for failures. All those animals that failed to pass on their genes to viable offspring? Nature’s too worried about letting the successes run things to worry about the missing genes of the failures. Yes, I’m inappropriately ascribing intent to a natural process, but you get the idea. And yes, Nature generally operates on a longer time scale than the average startup, but you never get to viable offspring by spending all your time with animals that can’t have kids, and you’ll never get to a great product by worrying about the customers who think your product is stupid (unless that’s the only kind of customer you have).
Focusing on Failure is Depressing
I’ve never been accused of having too sunny a disposition, but this shift in perspective has dramatically improved my own outlook on life and how I work with everyone around me. The shift was heavily inspired by reading Switch by the Heath brothers; its subtitle is, “How to make change when change is hard”, and it really hammers home that focusing on the successes, no matter how small, is what allows progress. It’s not just that this works, though - it’s a lot more enjoyable.
Everyone hates spending all their time talking about the things they suck at, the projects that aren’t working, the customers that don’t renew, the classes you’re failing. Yes, you do have to do some of that, but it turns out, you don’t have to do nearly as much as you think. In fact, you should spend the majority of your time on the things that really are working. It’s not being a Pollyana - it’s following success, and it makes you and everyone around you happier and healthier.
One of the implications of this practice is that you rightfully give up more quickly on the failures than you might otherwise. You focus on the paths that are working well, and tend to quickly abandon approaches that aren’t working. All of your efforts and experience naturally concentrate on the areas most likely to lead to successful outcomes. .
Use It On Yourself, Too
This isn’t just about how you work with other people or stuff; it’s also about you. I’m not a big believer in following your passion, but I do believe strongly that nearly everyone has a different collection of strengths and weaknesses, and that most people have at least one or two strengths that they can form into truly valuable assets.
You have a choice in your life between spending all of your time on those things that you can be truly great at, or spending it trying to turn the things you suck at into things that you are merely bad at.
I’m personally strong on product, brand, and culture, but I’m never going to be great at operations or sales. I could work my whole life, and probably go from being a 2/10 in operations to being a 4/10, which still couldn’t get me a job. However, if I work enough, maybe I could turn my natural strength in product design from a 8/10 to a 9/10 or even 10/10. Which of these is a bigger asset to me personally, and to the people around me? Even better, which do you think is going to be more fun for me?
Yes, there are some areas where you have true liabilities, and you sometimes have to invest enough focused practice in these so they’re not holding you back, but even in those areas, you’re better off working hard to be part of a team that complements your weaknesses, rather than trying to make sure you’re good at all of it.
Yes, Failure Does Actually Matter
It’s true, this article is a touch hyperbolic, and I suppose some readings of it could cause one to conclude I think failure is irrelevant and you should always ignore it (even though I explicitly say above that failure is sometimes critical to understand).
Of course, I don’t actually believe that. I get a huge amount of utility from failure. I’ve studied crash logs with the best of them, I am a big fan of postmortems, and I prefer never to experience the same failure twice, which usually means I need to invest in understanding it well enough to prevent its reoccurrence.
What I want you to learn, though, is that you need to seek success. If you’ve got a product that isn’t quite doing what you want but has some happy customers doing some weird thing you don’t understand, go study their success and learn how to build on it. If you’ve got one programmer who ships more high quality software faster and more frequently than anyone else, shouldn’t you deeply invest in knowing what makes her special and how to spread that skillset around your organization? Your kid doesn’t fit in, and isn’t going to become the doctor you always dreamed of, but might accidentally be a music prodigy or a professional athlete; shouldn’t you dive deep into that, rather than wringing your hands about them not fulfilling your dreams for them?
Water flows downhill, routing around blockages, and everyone’s path to greatness involves developing that same ability to put all the weight behind the things that are working, and not get too fussed about the things that aren’t. If you can do that, you’ll be happier, more successful, and actually enjoy the time you spend helping the people around you achieve meaningful success in life and in work.
I’m a tech founder and recovering SysAdmin. I helped found DevOps and grew up in open source. These days I am convalescing from a decade of physical and mental neglect while running Puppet.
Read more