Writing on Luke Kanies

Building on ATProto

luke@lukekanies.com (Luke Kanies) — Mon, 20 Jul 2026 00:00:00 +0000

Bluesky’s Atmosphere Protocol has the chance to become the base for a whole generation of applications. But it’s developing in surprising and disappointing ways.

I spent part of last week at the Local First Conference in Berlin. I was not surprised to find that AI coding was on everyone’s minds. Less expected was how pervasive ATProto was.

I’ve been considering trying to build on ATProto for a few months, so this was a great chance to ask a bunch of questions from both people building on it, and the people actually building it (multiple key Bluesky people were there).

I want ATProto to be the answer for me. I want to again live in a world where application developers use public, community driven standards to create interoperable applications with common data standards. I think it can be. But unfortunately I think it’s not on track to be that right now.

In this post I’m going to describe what I have been wanting to build, and how ATProto’s current and proposed designs do and don’t work with that. And I’ll also throw in some comments about what’s been surprising to me.

I’m probably trying to do too much here. But my main goal is to provide feedback on the proposed design, and it’s hard to do so without being clear about what I want to build and why.

Start With Reviews

The smallest version of what I want to build is a suite of applications for recording reviews. In an ideal world, these applications would supplant Yelp, GoodReads, Letterboxd, and a bunch of similar applications for just about anything you might consider reviewing. (Yes, I know there are already people building versions of these on ATProto; I’d want to collaborate with them.)

I want to replace these applications not because of their function, but because of their business models. Neither my wife nor I will use them the way they’re intended, and I think most people are like one or the other of us.

Local First Data

For me, I don’t want these companies to own my data. We have more than a thousand bookmarks in Yelp, but… they’re stuck in Yelp. I can’t do anything else useful with them: I can’t publish them, I can’t share them, I can’t write scripts across them, I can’t version control them. They belong to Yelp, not me. And, frankly, the experience they provide for managing lists of bookmarks kinda sucks.

This is a classic local first use case. I could adopt one tool that was great for writing reviews, another that used the same data but was better at publishing best-of lists for my friends, and another that made it easy to share “best business books” lists on my web site. No single app is going to do all of these, but a shared, public data model allows everyone to have what they want.

I’ve lost the willingness to give big corporations a permanent right to control how I use my own data. (That’s why I’m writing this in plain text and publishing via Hugo.) The apps only get worse over time. And if I’m going to invest that much time in recording my opinions, I want to control its use, not let Yelp do it.

Public and Private

As to my wife, she will just never publish anything online. Never. If I want her to review books or restaurants or recipes, it has to be in a place where I – and maybe the rest of our family – will see it, but no one else.

Personally, I am willing to publish public reviews. And sometimes I specifically want to, like sharing books I found useful as a founder. But doing so is complicated. The information I would record about a restaurant for myself is quite different from what I would want the wider world to know. Yet… most apps don’t allow you to draw this distinction. Reviews are public. Your opinion affects the subject’s reputation, even if you didn’t want it to. (I’m vegetarian and autistic, so a place working for me is not necessarily relevant for other people.)

Fundamentally, most of these applications are built to enable influencers: People who want to build a following online for their reviews. “Oh man, she has the best book recommendations!” “If he likes the restaurant, I know I will too!”

But most of us don’t want to become influencers. If anything, we’ve generally learned the lesson that it sucks to be followed by a bunch of people online. I want to keep my stuff private. I don’t want my opinions to matter to anyone else.

I mean sure, when someone comes to town I want to be able to give them a list of restaurants they should visit and activities they should do. But I want to send it to them, not the rest of the world.

We can split the world into three kinds of people:

Those who would only record a review if other people will read it. These are the influencer-wannabes
People like me, who would provide a mix of public and private reviews, depending on the circumstance
People like my wife who will only ever record reviews if they can be confident it will be private to just their friend group, or even just to themselves

The current crop of applications works fine for the first group. But it leaves the latter two out in the cold.

And I bet anything that those other two groups are much larger.

So, what we need is a system that allows application developers to easily let their users choose how public or private they want to be – entirely public, entirely private, or sharing piecemeal with individual groups.

What does this have to do with ATProto?

Let’s start with what’s great about ATProto: It seems to be the first protocol designed to solve identity at scale, enabling any application to build ATProto identities into their application for authentication, tracking followers and following, and the other related features that basically every application needs.

Its identity system not perfect (I wish it were more human readable, especially). But it seems to be close enough today that nearly every speaker at Local First this year mentioned it. No more does every app developer have to create their own social graph, their own identity and authentication systems, their own means of finding friends.

Unfortunately, at least for now, the rest of the protocol is of limited use for my goals.

Today, ATProto is public-only: It assumes that everything you do will be published online for the whole world to see. That design decision is baked into everything from the storage systems to the structure of the publishing services.

The community is currently designing what they call “permissioned data”. (I think this is a silly name, and it should just be called “private data”, which is better both because “private” is actually a word, and also because it describes user behavior instead of technical implementation, which is a far better naming practice).

Unfortunately, while most of the assumptions driving the design seem reasonable, the resulting design looks very hard to build on. A lot of where I think it goes wrong is captured perfectly in the above linked post:

Before we get into it, the through-line on all of this is that public broadcast data is substantially different from permissioned data.

I fundamentally disagree with this. (I am not the only one.)

Private and public data are basically identical. A restaurant review is a restaurant review whether I am the only one who ever sees it or it gets shouted to the rooftops. A book review I share with my book club is identical to a book review I share with my wife or publish on my web site.

Data I publish to the world is just a special case: The permission is world-read. Just like data I never publish is a special case: It has no readers other than me.

Unfortunately ATProto is already used out in the wild for Bluesky, and it is designed and built as a public-only protocol. It would be hard to change it to support access control, limited distribution, and the other features you need with private data.

So, instead, the community has, from what I can tell, just… designed a completely independent system for private data.

Permissioned Data relies on the existing identity system and lexicons (for defining data types). But adds entirely new data structures, plus new methods for managing and validating that data. (Note that the link above is to one in a series of posts on the design; you can get to all of them from there.)

So, as an app developer, you have to essentially write two applications: One for public data, and one for private. But, your users don’t think of it as two apps. “These are restaurant reviews. All the restaurant reviews should go together.” So your job, as the developer, is to support these two data systems, and two protocols, but never let the user see that they’re totally different.

That gets messy real fast. You’ve got a private post you want to make public? You’re not modifying it – you’re deleting the old one and making a new one in the public subsystem. Does it keep its likes? Its reposts? Links to it? 🤷‍♂️ No idea, but… probably not.

It’s actually worse than that. ATProto’s storage subsystem, the “Personal Data Server”, provides direct access to your data. In other words, you should expect more than one application to want to read and write your data. So now, anyone who is interested in this data has to write two versions, but lie to their users and hide any differences.

Because, again, there aren’t actual differences. The actual data being stored is the same. The way the user thinks about it is the same.

To me this is a sign that the current proposal is flawed.

I don’t know how to fix it. I’m nowhere near close enough to conversation to think I can propose solutions yet. But hopefully I can help people see problems, at least.

One last local-first note

I only had a high-level understanding of ATProto went I went to Local First, so I learned a lot while I was there. One thing I was definitely wrong about was how the PDS worked.

I naively assumed it worked a lot like a git repository. The ATProto community regularly says that I own my own data. I tend to assume that means that I have a copy of it, and that when I make changes, I am operating against my copy then distributing it. This is exactly how git works: I clone a repository, make my changes, then push them back up to the server for distribution. I have a hard time imagining “owning” my data without always having a copy of it.

But no, that’s not at all how ATProto works. The PDS is “your” server, but… it’s actually a server. You do not push data up and pull it down; you speak a protocol to it. You only “own” your data because it and the protocols for accessing it are public, and you can change where it is stored.

It does use cryptography-based data integrity guarantees like git does, which is one more reason I assumed I could easily manage the data like git does. But those guarantees are only used on the server, not in the protocols you use to provide new data.

ATProto meets about half of the design principles in the Local First essay linked above. But it clearly misses on the data being at your fingertips or the network being optional, and also misses out on a lot of implied abilities because you’re always talking to a remote server.

If you want to record a review while you’re offline… best practice is to essentially store those reviews in a temporary area, then push them to the server when you’re back online. In other words, you have to build your own custom storage and sync system if you want offline support. Obviously not impossible, but also obviously not local-first.

If you then cross this with the current design for Permissioned Data, I’ve got a bit of a mess:

Custom local storage for offline data
Custom sync system for emptying offline data
Sync system must use different protocols for public and private data
Online app usage must also use separate read and write systems for private and public data, and is likely different from the system used for offline support

As an application developer committed to both local first principles and letting the user choose between public and private, ATProto is working at least as much against me as with me. Am I really better off building on this, versus designing my own system? That question is doubly scary when you recognize that the protocol designer and I are so far apart philosophically.

If I believe public and private data are fundamentally the same, just with different access rights, but the community believes they are and should be different… I am fighting the protocol, storage system, and community every step of the way. I’ve done this before, and it sucks.

Conclusion

I’m still excited about ATProto. And thankfully, the Permissioned Data design is early enough that it can still be improved. And I’m not the only person out there pushing back on the existing design and its goals.

Even if the proposed design goes through, I can build at least somewhat on ATProto, maybe using its identity and lexicon systems.

But I came up in the 90s, when the entire internet was built on standardized protocols that were internet-scale, resilient, maintained by the community and a standards group, and built to empower its users rather than enrich whoever could build the biggest moat. I want that world again.

I think ATProto has the opportunity to be the first new protocol of this type in decades. I hope they go for it, and build something every application developer (but especially me!) wants to build on.

AI Is Like a Crappy Consultant

luke@lukekanies.com (Luke Kanies) — Mon, 12 May 2025 00:00:00 +0000

I decided to finally give vibe coding a try. I’ve barely written any code since I hired developers at Puppet in like 2009. And I’ve been a staunch AI/LLM skeptic. But I figured I should at least be an educated skeptic.

After a false start, and a couple of months of periodic usage, I’ve come to some conclusions about it. The first one is the most important:

You should treat AI like an untrustworthy consultant.

Think of this scenario: You need help with your company’s core product. You have to bring in an outside expert, either just as another body, or more likely, because they have knowledge your team doesn’t. What do you do?

Give them commit access and let them work unsupervised? Of course not.

At the least, you have someone sit by their side, checking every line.

More likely, you don’t even let them touch the keyboard. After all, you want more than the help – you want your team trained up so they don’t need that help next time. The only way you’ll get that is if your team does the work, even if someone else is telling them what to do.

That’s how I consulted at Puppet: I show up, I walk you through all the work, and when I leave you have more than a functioning system; you actually know how to use it. Sure, it was faster and easier to do all the work myself. But no one ever learned anything then.

All the coding I’ve done with AI help is in Swift, using SwiftUI, to build iOS apps. I’ve never worked with anything like any of that – I’ve not used any of the specific tech (other than an iPhone as a user). I’ve never used a UI framework. I’ve never worked in statically typed languages. And I’ve barely ever worked in compiled languages. So, it seemed like a solid use case for getting some fast help.

My first try used Cursor, and let it edit everything.

After a few iterations, I had a bare-bones application. But… I felt like I was pushing around a bag full of bolts. There was definitely stuff in there. But I didn’t even know how to think about the changes I needed, because I didn’t understand enough.

So on the second iteration, I decided I would do all the typing: The AI does not get to touch the keyboard. When I started it was all gibberish, because I didn’t understand anything. But after only a session or two, I have a pretty good sense of how both the language and framework work. That’s about when I realized the second big thing:

AIs are crappy architects.

It kept giving me stupid advice. For instance, every time it encountered an error, it would just catch it and print some logs. Uhhh… that’s bad. It would encounter a small problem, and design a big stupid solution instead of doing a small rearchitecture. Because it can’t think, it couldn’t realize when it hit a design wall that needed rethinking.

After a while, I concluded that it wasn’t very good at the back end code – I have a lot of experience with modeling and data flow, and I kept finding dumb things it did. But I never found those dumb things in the area I have no experience: the UI.

But… then I thought for a bit. And I realized, duh, that’s probably just because I’m not good enough yet to recognize the dumb stuff it’s doing.

Coincidentally, I am now hitting a repetitive wall with Swift’s type checking. I keep having to break a view into smaller and smaller files so that it can compile fast enough. Turns out that’s the AI’s only trick for fixing this problem. But a small amount of research shows there are other options. In particular, I can instrument the compile and see what’s actually taking all the time, and focus on just rewriting that code to be more compiler-friendly. This is the kind of stuff an experienced programmer does without thinking, but a crappy consultant whose entire experience is based on trawling Stack Overflow probably never figures it out.

I did find one area where LLMs absolutely excel, and I’d never want to be without them:

AIs can find your syntax error 100x faster than you can.

They’ve been a useful tool in multiple areas, to my surprise. But this is the one space where they’ve been an honestly huge help: I know I’ve made a mistake somewhere and I just can’t track it down. I can spend ten minutes staring at my files and pulling my hair out, or get an answer back in thirty seconds.

There are whole categories of coding problems that look like this, and LLMs are damn good at nearly all of them. Where did I fail to log correctly? Where am I not handling an error appropriately? If I am updating this method name, which files do I have to change?

I’ve had about five to ten sessions of using Claude – just on the command line, no fancy tools, and no editing allowed. I have about enough experience with Swift and SwiftUI that the terms of the relationship have changed. I feel more like the senior engineer, and it is the junior developer I have working on a short term contract. I can pass it the stupid grunt work (rename this method through the whole system, fill out this boilerplate for a new view, figure out how this new library works).

But I absolutely can’t trust it to make any big decisions. And I have to check all of its work. (Even better, it won’t be offended when I do.)

After a few more sessions, I’ll probably start letting it edit files directly. But only for that kind of large scale, small change work. Once I build the error management framework, it can probably push it through the system (especially since I’ve sprinkled my code with comments when the error management was missing). But I’ll still walk through all the changes to ensure it actually makes sense.

Those Great New Calendar Tools Probably Won't Help You

luke@lukekanies.com (Luke Kanies) — Fri, 15 Sep 2023 00:00:00 +0000

They’re built for people who hate meetings, not for those who need to be great at them.

Photo courtesy of JEShoots.

There is a new movement around tools for managing your calendar. My favorite is Reclaim, but there are many others. They provide help running meetings, rearranging them, and avoiding them.

It’s great that these tools exist. The calendar is the least improved area in the average office worker’s life in the last few decades. My particular bugaboo is that calendar apps don’t know that you exist as a physical person, so they are perfectly willing to let you schedule two in-person events five minutes and 3000 miles apart. Any other kind of application would see that as a catastrophically brain-dead bug, but somehow the tools we use to arrange our lives don’t.

But… Something always struck me as off about these new tools. I didn’t want to use any of them. I’m a tool junkie, so this is pretty weird. Even Reclaim took me a while to understand and fit into my life. It was obvious these tools weren’t for me, but why not? Who were they for?

They’re for front-line workers: Developers, accountants, SREs. I used to be one of those. I’ve certainly been yelled at enough by them for putting meetings on their calendars.

But I’m not one today. I haven’t been in at least a decade.

My employees at Puppet used to say they hated meetings (I’m sure they still do, they just don’t work for me any more). I would tell them: Replace “meeting” with “collaborating with my team-mates” and say that again, eh?

So yeah, I have a different perspective on meetings.

Not that I think they’re all awesome. But for me — and most other leaders and managers — meetings are how we do our job. The life of a manager is built around communication. Much of it can be unscheduled, and ideally asynchronous. But a lot of it needs to be direct, synchronous, interactive.

That interactive time is much less efficient than, say, email, which means managers have to schedule their time carefully to ensure they get everything done. And of course, employees hate it when a manager shows up at their desk unannounced and asks for time. They want that meeting scheduled, too.

So a manager’s day is built around meetings, and there is a new crop of tools to help with them. What’s not to love?

Well. The tools are built by and for people who hate meetings, and often who aren’t very good at them. Instead, I want tools for people whose job is built around meetings, and who know they must be excellent at them.

Managers do need help. Not nearly enough of them are actually good at the mechanical parts of their jobs, including managing meetings. But these tools are mostly about avoiding or constraining them. They’re for the people asked to join, not for the ones calling them or running them.

I hope these tools do well. I want there to be a mature market of great tools in this space.

But even more so, I hope to see a parallel mature market for tools to help make better meetings. The average employee suffers from all the meetings they have. If managers were better, there would be fewer meetings, and the ones remaining would be better.

That’s a much better world.

Do I Hate Investors?

luke@lukekanies.com (Luke Kanies) — Tue, 22 Aug 2023 00:00:00 +0000

Of course not. But the fact that people think I do says a lot.

Photo courtesy of Andre Hunter.

Seeking a round of funding is about the most miserable thing I’ve ever done. Truly. Fundraising was less pleasant and more demeaning than anything else I did at Puppet. But Clickety’s final (abandoned) round was uncomfortable in a new way.

Two different investors asked me the same question:

Why are you fundraising if you hate investors?

The question caught me flat-footed. Mostly because it’s such a stupid one.

I don’t love working with real estate agents. I feel like I’m being scammed. Even if I like my own agent, I usually don’t like the other one. I’m uncomfortable the whole time.

But in the US, it’s way harder to buy or sell a house if you don’t use an agent. And even if I went without, the other side of the party probably would hire one. So, I use a real estate agent. And I work with the agent on the other side at the same time. You want the house, you use the system.

And when I buy that house? I ask my banker for a loan. It’s not because I love bankers. It’s because I need help buying the house, and he’s in the business of helping people buy houses. Seems pretty straightforward. It has nothing to do with whether I like bankers, banks, or the mortgage financing system.

The legal system is similar. I actually do like a lot of lawyers. But… god, not all. And the way lawyers often work is stupid. I don’t actually think lawyers designed modern legal documents as a form of job security, but it sure looks like it sometimes.

But when I need to work with complex contracts, I hire a lawyer. It doesn’t matter whether I like lawyers or the US contract system; I have a job that demands legal help, so I go get it.

There’s a huge difference between all of them and venture capitalists, though: Bankers, real estate agents, and lawyers don’t demand that I act like I like and respect their industry. But VCs don’t just want me to start a great company. They want me to like and respect them for trying to make money off the work of me and my team.

Why was I fundraising from VCs?

To paraphrase Willie Sutton (maybe?), because they’re the ones with the money. If I want funding for my company, I need venture capitalists. What does it matter how I feel about the venture industry?

If you’re an entrepreneur today, there is no other source of capital. You can either bootstrap, or raise money from VCs. There are a few firms experimenting at the edges, like Calm, but they have a minuscule amount of money compared to the venture capital industry.

Yes, I could bootstrap. I’ve done it before. But it took four and a half years. I’m not as patient today as I was when I was 29. I also thought it made sense to start this company as a CEO and product manager first, rather than as a programmer. (In retrospect that was a mistake.) That made it impossible to bootstrap. I needed a team.

This question is just offensive, though. Its implication is “you should not raise money from investors unless you are willing to show respect and appreciation for the money they give you”.

Why? The world famously hates bankers and lawyers, yet continues to work with them. Why does this field get to demand our respect, when others don’t? Finance, especially, is just here for the money, and everyone – them included! – knows it. We just have to convince them we’ll help.

VCs are gatekeepers

Investors display their power by demanding your respect. They don’t invest in people who don’t show fealty to their image of themselves.

It’s how banking used to work: Some people got money, and some people didn’t. Fundamentals had nothing to do with it. You had to be in the right network, have the right skin color, the right class. Eventually bankers realized they made less money when they only loaned it to their friends. (And the US government forced them to back off their discrimination a bit.)

Most investors today will tell you to just “play the game”. This is what they mean: Participate in our discriminatory process, and show us proper respect. This is why you usually need a warm introduction to even be allowed to pitch them.

It’s a broken system that leaves broken people in its wake.

But I raised money within it, many times, because that’s where the money is.

Hate the Game, not the Player

No, I don’t hate investors.

But I do hate the world of venture capital. It is fundamentally flawed. It incentivizes behavior I can’t stand, and quashes behavior I find respectable and moral.

For what it’s worth, I also hate the larger finance industry. It’s not like venture is some rare target for my ire. There’s a reason I’ve never considered working in finance. (Well. There are several.)

Venture is an amazing engine for creation and invention. But it mostly invents stuff I wish didn’t exist. And it does not seem to be able to solve the problems that matter most to me or the larger world.

People appear to hear my dislike for their industry and think I hate them, personally. I can’t do much about that. I respect and like some investors. I dislike some others. But I generally have no particular feelings about a given individual.

That being said…

I don’t tend to respect investors.

Being a venture capitalist doesn’t automatically disqualify you from garnering respect. But it also does not automatically deserve it.

In the 1980s, finance was at its peak. People made ungodly amounts of money ruining the lives of thousands and thousands of people. And they were held up as heroes of business. We’ve largely learned that stripping financial assets is maybe not something we should be proud of. These people still get rich, but we have learned not to lionize them.

Is the modern venture investor as heartless and shameless as a PE investor from 40 years ago? Generally, no. (Although there are definitely exceptions.) But like those 80s wolves of Wall Street, VCs have found a money-making edge, and they’re ruthlessly exploiting it.

I’m just not that impressed.

I can see why someone would read that disregard and disrespect as hate. Especially given the power dynamic: I’m asking them for money, yet I’m not showing “proper respect”.

My banker didn’t demand I “play the game” when I applied for a mortgage. He just needed evidence that I could afford the house I was buying, and that it was worth what I was paying.

Being autistic means I’ll never be able to “play the game”. It’s literally constructed so only the in-crowd can join. I can mask for a while. But it takes hundreds of meetings to raise a round. Most people in the meetings look the same, dress the same, went to the same schools, and ask the same questions, yet think they’re special geniuses. And most of them give the same answer (“no”). It becomes hard to hold a facade.

It’s not a choice, or a lack of skill. It’s a hardwired neurological limitation. You might as well ask me to be taller, or have a lower voice.

For better or worse, I’m not sure it matters now. My personal limitations are likely to prevent me from trying to raise money again. But I hit those walls in large part because of how harrowing fundraising is.

Will I do it again?

My experience at Clickety tells me I’m unlikely to run another venture backed startup.

It looks like I’m already a bit of a pariah, which might explain part of why it was so hard to raise. (Not that I don’t deserve some of that reputation.) It’s not about to become easier for me. The older I get, the less I can handle gatekeepers. And I was already crap at tolerating them when I was younger.

My health — both physical and mental — would need to significantly improve. Running a company is stressful enough. Raising money was too much.

I won’t rule it out. I know my future is going to look different from my past. I have a lot of healing to do.

But I still believe in the power of software to make people’s lives better. And venture capital is a fantastic source of acceleration. I hope to continue to work with founders, and intrinsically that means working with investors, too, sometimes.

I also love solving problems. I hope to help others do it. But I won’t rule out trying to solve some problems on my own.

And maybe one of those solutions will be so good they can’t ignore me.

My Monopolies

luke@lukekanies.com (Luke Kanies) — Wed, 18 Nov 2020 00:00:00 +0000

Most industries are dominated by monopolies. How we enforce antitrust law explains far more than you might think. Photo courtesy of BP Miller.

My first monopoly was AT&T.

I lived on a commune until I was eight. We didn’t have toilets, but we did have phones. We didn’t own them. It was a commune, after all. But they were in our house and we got to use them.

When we reentered “normal” civilization, we still didn’t own our phones. AT&T did. This was 1984, the same year Congress broke them up. I was more confused than injured by their power. Capitalism was new to me. Every single thing in our house was ours, for the first time, except that one. We had to lease it from Ma Bell. Even weirder, the lines in our house were apparently not ours. (I mean. We were renters. But you get the idea.) We had to pay to attach other objects to ports in our own house.

This confounded me. “Some… outside company I’ve never heard of makes rules about what we have in our house?” Yes indeed.

Thankfully, it didn’t last. With five siblings, we needed but could not have paid for those extra phones.

My second monopoly was Microsoft.

They had complete dominance of desktop operating systems and software (the Office suite, plus Outlook/Exchange for email). I went to Reed College, so I exited school as a Mac user, in the middle of their dark days. In hopes of avoiding Windows I tried everything else: BeOS, Linux, Solaris, you name it. No matter how fast I ran, I was often stuck on Windows at work because, well, everyone was.

Microsoft abused its monopoly heavily and freely until being taken to court. Microsoft’s abusive behavior is usually discussed in terms of its effect on the web. But I’ll never forgive them for Outlook. It taught multiple generations of people to do email incorrectly. To this day, the average business user is incapable of having sophisticated discussions over email because Outlook trained them not to.

Ironically, Microsoft itself likely only exists because of Congressional antitrust action against IBM. The government eventually withdrew its case against Big Blue, but not before convincing it of the importance of leaving room for others.

The Paradox of Antitrust Choice

Kids coming up today are lucky. They have so many monopolies to choose from.

Of course, I don’t actually mean “choose”. You pretty much have to use all of them. Google for search, Facebook for social, Amazon for e-commerce and cloud infrastructure, and Apple for hardware and apps worth paying for.

Tech is absolutely rife with monopolies. (And monopolists.) But the industry itself is largely in denial about that. “We’re different!”

The last month has highlighted this. Congress has dragged the richest, most powerful tech founders and CEOs in to testify. More importantly, a Judiciary subcommittee has produced a huge report on concentration in the tech industry.

Responses from the tech industry have not been great. Many have laughed at congress members for their lack of tech prowess. Some focus more on what the tech companies haven’t taken over yet than on what they have. Others have claimed that tech is so different they have to be looked at fundamentally differently.

Tech is not special

I’m going to focus on that last link, from Ben Thompson. He makes a throwaway comment:

consumer harm, which is the de facto standard for antitrust in the United States

The article itself is interesting and informative, as most of Ben’s writing is. But this small line shows that Ben is in a box that limits how he thinks about antitrust. And if he can’t see out, few others are likely to.

I think he should. I think you should. I think everyone should.

Abuse of monopolies affects all of us. It’s not just about tech. We’ve allowed most of our industries to become highly concentrated: Agriculture , pharma, internet access, and many more. Heck, even eyeglasses.

America doesn’t have a tech monopoly problem. We have a plain old monopoly problem.

Ben works hard to explain that the tech monopolies are natural because of what he calls Aggregation Theory. He implies this makes their monopolies more acceptable, even inevitable. He accepts there is abuse, but a very narrow definition of it. Even if his theory is sound (which I am not convinced of), it doesn’t explain the rest of the monopolies that plague us.

Something else does.

The “consumer welfare” standard is not the law

Ben is right that US antitrust law focuses on consumer welfare. That’s pretty much the work of one person: Robert Bork. His book, The Antitrust Paradox, successfully rewrote the history of American antitrust enforcement. Gone were concerns about competitive markets, or any discussions of the downsides of market power. Nope. If prices are low, it’s good. That’s it.

He didn’t get any new laws passed. He just convinced our country to enforce them differently.

Yes, consumer welfare is an important input in the laws themselves. But there’s far more to it, including a healthy focus on market power. Yet Bork managed to gut everything else with one book. (To be fair, there were a lot of rich and powerful people set who became even more so once he won.)

To be clear: The laws themselves have not changed. Only how we enforce them, within the government and the courts.

It is impossible to understand antitrust enforcement in our country without accepting this fact: We have strong antitrust laws and are choosing not to enforce them. They have been gutted by an extreme interpretation, and fifty years later, nearly every industry demonstrates the ruinous consequences.

Revisiting Consumer Welfare

Bork successfully reframed the downsides of market power, with a lot of help from the Chicago School of Law. But there have always been people fighting back.

And they’re finally starting to make headway.

Lena Khan produced the seminal work in this category, Amazon’s Antitrust Paradox. She lays bare how powerful Amazon is, and how useless consumer welfare is as a means of assessing monopoly abuse. Its impact has allowed her to carry the flag even further.

In particular, she was part of the team that ran that Judiciary subcommittee hearing, and produced the related report.

Yes, her argument - and thus at least partly, the argument made by Congress - is that Amazon and its peers have too much power, and they are abusing it to gain even more.

But more importantly, she’s arguing that you cannot have a conversation about market power without also talking about standards other than consumer welfare.

That’s what Ben Thompson (and Ben Evans) and all the other tech commentators need to understand.

The argument is not really whether one of these companies is a monopoly. It’s what standard we should use to assess their behavior.

Do we let Bork decide, and use a light hand and generally tolerate heavy concentration of power?

Or should we follow the original intent of the laws, focusing more on encouraging a competitive landscape and a market free from companies that are too big and too powerful?

The Tech Monopoly Minefield

Every tech founder I know builds their business around the reality of these monopolies. If you’re in e-commerce, your business is defined by the space Amazon leaves you. You don’t necessarily have to be on Amazon, but prepare to be attacked if you’re not. If you’re in social, you have to ensure Facebook doesn’t want your business. If you make apps, you can only make or sell them the way Apple lets you.

I expect most founders and investors don’t even realize how much we’ve given up on doing because of these monopolies (and all the smaller industry heavyweights, like Salesforce). We talk big about agile startups outwitting the big players, but… that only works if they can’t choke off your suppliers, outbid you for engineers, or take hundreds of millions in losses to destroy your company.

What could we build if we didn’t have to fear so many big players?

Conclusion

I’m still haunted by that AT&T phone we didn’t own.

I could not be happier that the government is finally revisiting our antitrust standards. And honestly, I’d rather they make mistakes in regulating the huge players than not regulate them all. We’ve seen what five decades of almost no action results in.

Like everyone, I love fast cheap shipping. But it’s not worth destroying independent retailers over. Honestly, I can’t stand using any of Facebook’s products, but maybe I could if they were stand-alone instead of part of a soulless corporation bent on domination.

I believe in the free market. But none of the markets I’m interested in are. They’re all dominated by players so large, so powerful, that our only choice is to work with or around them.

It’s long past time to get rid of the consumer welfare standard, and bring back to true antitrust enforcement.

Designing Tomorrow’s Privacy

luke@lukekanies.com (Luke Kanies) — Thu, 22 Oct 2020 00:00:00 +0000

Privacy expectations are changing. How will companies change with them?

Photo courtesy of Tobias Tullius Change is coming to how tech companies handle privacy. Everyone is going to have to adjust, but new startups are caught in the middle: Be as useful as the companies built in the old world, while following the new rules.

Today’s dominant tech companies don’t care much about privacy. Many of their businesses couldn’t exist if people were careful with their data. Facebook only survives if people are willing to share widely and publicly. Google’s ad engines feed on reams of public data.

Privacy will matter far more to new companies. Google has taught companies the cost of sharing their data publicly. Consumers are slowly waking up to how pernicious Facebook’s data practices are. And the laws themselves are changing.

Regulation is already happening at the state level, and internationally. You might not want federal legislation, but state by state rules would strangle growth of new startups.

I know some say government can only create problems, not fix them. I am not so cynical. The creation of the EPA is a great example of government taking industry in hand and making the world better. I am eager for Congress to take privacy as seriously.

The Business of Privacy

But I’m not a legislator. I’m a builder. I’m more interested in understanding how people’s behavior will change, and what that means for the products I’m creating.

For some, the future of privacy is already here. DuckDuckGo is thriving (despite its silly name) on promises of providing great search without all the tracking. The Brave browser is growing for similar reasons.

But how big is this change? Will the average person in the next decade expect to retain privacy, demand companies respect their data? (I originally wrote “computer user” here instead of “person.” With the smartphone, there is no difference.)

Or will privacy concerns continue to be like security concerns have been for the past decade: the domain of the few, the nerds?

This starts as a moral question. Privacy is a fundamental right. We deserve applications whose business model requires it, rather than neglects it.

But it’s also a business question. What kinds of companies thrive in the current privacy framework? Will they thrive in ten years? What about a world with little privacy? Which companies might do better if people cared more about it?

It’s worth elaborating on what I mean by privacy. Google and Facebook have very different definitions, for example. Facebook’s business is built on promising as little privacy as possible, and delivering even less. They share your data with pretty much everyone. Google just uses your data internally. They don’t share your browsing history; they just use it to market ads.

There are far more companies out there like Google than Facebook. Everyone shouting “data is the new oil” is advocating for Google’s business model: Collect a ton of data and profit off of it. It might start as your customers’ data, but if you collect enough it, and tie it all together, it becomes your data.

By policy, these companies (usually) care more about privacy than Facebook does. They rarely sell or share your data. This is better. But privacy isn’t restricting data to only a few trillion-dollar companies. It’s sharing my data with people, not companies.

It’s instructive to look at one company offering less privacy today than in the past: Microsoft. In the old days, all of my documents sat on my computers. My email ran through servers run by corporate. Microsoft could never have gotten to any of them.

Now it’s all “on the cloud.” What does that mean? Microsoft has it. They might not be sharing it with others, but they’re certainly looking at it. Oh, maybe individuals aren’t. But their programs are.

This can be good. Usage data can help vendors improve their software.

But mostly, it’s bad. These promises of better software tend to be hollow. I don’t want better ads. I don’t want your algorithm picking what I see. And I certainly don’t want machine-learning recommendations based on a statistically average user.

People are beginning to see the downsides of handing all of their data to companies. They know that Facebook, Google, Microsoft, Apple, and Amazon have too much power. They are changing their privacy expectations. Not just the nerds, but average people.

But how much? How fast?

The Cloud Conundrum

Privacy in the modern era is a special quandary. The cloud is pretty great. No synchronization. No management. Easy sharing.

No one wants to give that up. Yet today, cloud usually brings severe privacy compromises.

Do I try to build without the cloud, enabling more privacy, and try to compete with what might be less functionality? Or do I build on the tools everyone else uses, where a lack of privacy means there’s little limit to what I do?

Is there a world where you get all of the benefits of centralization, of the cloud, of being online, but don’t have to sacrifice your privacy? Can you be in the cloud, but keep your own data instead of letting a company put it all into one bucket?

I think so. For many cases, I don’t even think it will be that hard. It will just require thinking differently. It will require new answers, maybe slightly harder ones. But not whole new forms of math or science. Something attainable and reasonable today.

As a founder and investor, there still might be big downsides. It might mean you can’t be the next Google. The next Facebook. Or even the next Salesforce.

It might be that a company is worth less if it does not exploit your data.

What if ethical, privacy-conscious companies stay small, and unethical privacy-destroying companies get to keep growing? There is precedent. Prior to the creation of the EPA, an industrial plant would be committing fiscal suicide to spend money reducing pollution.

I worry about this. I’d sure love to see better behaved companies get rewarded with growth. But that’s certainly not the world right now.

Of course, this is partially why we need new regulation. The rules need to change. There was a time when big business just dumped all of its waste in the local rivers. It was cheap. Why should they care if it killed people and ecosystems? Gotta protect shareholder value! But then the rules changed. Nixon (!) created the EPA, and now we take it for granted that industrial players are forced to protect the air and water at least a bit.

The rules will matter less if enough people change. If you stop buying from companies who abuse your data, they’ll stop doing it. If the next Facebook can’t be built off of your data, then someone will need to find a new way - and hopefully a better one! - to meet your needs.

But maybe those businesses won’t be quite as big. Or get there quite as fast.

Are you ok with that? Is that a reasonable trade off?

It is for me. Facebook didn’t make me a billionaire. I’m not at risk of some other data-centric company making me rich. I’m not investing in companies that collect and exploit your data.

But a lot of people are. A lot of our industry is built on the idea that access to this data is good. Many companies could work without it, but choose not to.

Take the smart home, for example. My smart thermostat is in my house with me, right next to my phone. On the same network. But how does my phone configure it? Not by talking directly! No. My phone contacts cloud services, which then contact my thermostat. Why? Partially because it’s easier. But mostly it’s about data.

There’s no chance Google would have bought Nest for $3.2B if that data weren’t available.

Maybe Nest would be a better company if it were more concerned with making better devices instead of extracting our data. But I don’t think Google would be as excited about that other company. Investors like the multiples that all that data gives them. And product people like what the data allows.

Like industrial effluent, this data is toxic. Dangerous. I’m afraid of what’s being done with what leaks out. I’m afraid of all of the bias. I’m afraid of businesses built on my lack of privacy, my lack of boundaries.

My Bet on Privacy

My new company assumes people will care more about privacy than they have. I expect I’m giving up some long-term potential by doing so. There are things we can’t do as a result. Things that our competitors might find easy to do.

But we’ll be able to make promises no one else can. And we’ll find new ways - hopefully better ones - to solve our customers’ most important problems.

Even writing this frightens me a bit.

I’d love to believe that promising privacy would make my company more valuable, make it easier to raise money. I know it will make it easier to hire people.

Some users will choose us specifically because of our privacy model. But how many? And will it be enough?

I know the bet I’m making.

But I also know it’s a risky one.

Don’t Make Board Decks

luke@lukekanies.com (Luke Kanies) — Wed, 22 Jul 2020 00:00:00 +0000

Why and how my team built board reports instead of PowerPoint decks. Fifty pages, less work than slides, and more valuable. Image courtesy of Drew Beamer.

Board meetings are a critical time of communication and reflection for a company. You have to share enough information that the people in the room can make existential decisions about the business. Yet most CEOs I know share only slides (the “board deck”) with their board.

This is a huge mistake.

People who worked for me at Puppet claimed I hate PowerPoint or Keynote. Nope. I use them myself when presenting on stage in front of a large crowd. But they are a horrible choice for communicating without a talk track, and are incapable of conveying large amounts of information, or anything of detail.

Don’t trust me? Ok, how about Edward Tufte , The Godfather of information design, who partially blamed them for the Columbia space shuttle explosion:

These [NASA] review boards examined what is probably the best evidence available on PP for technical work: hundreds of PP decks from a high-IQ government agency thoroughly practiced in PP. Both review boards concluded that (1) PowerPoint is an inappropriate tool for engineering reports, presentations, documentation and (2) the technical report is superior to PP. Matched up against alternative tools, PowerPoint loses.

What’s that you say? Running your business is easier than shooting rockets into space, so you are fine dumbing down your communication? You’re not in great company.

Amazon forbade PowerPoint in staff meetings, switching to a six page written memo:

Bezos revealed that “narrative structure” is more effective than PowerPoint. According to Bezos, new executives are in for a culture shock in their first Amazon meetings. Instead of reading bullet points on a PowerPoint slide, everyone sits silently for about 30 minutes to read a “six-page memo that’s narratively structured with real sentences, topic sentences, verbs, and nouns.”

Scott McNealy banned it at Sun Microsystems years earlier.

It’s not just that slides are bad.

There’s a much better option right in front of you.

For most of my time running Puppet, we prepared a board memo: A text document written in normal English, with supporting images and charts. It averaged between 35 and 55 pages in length.

It worked great.

It took less time to prepare, and conveyed the state of our company more effectively. I recently shared my last board report, from 2016, with a friend, and he protested, “This is an SEC filing, not a board report!”

I’m not sure if our process is a fit for you, but hopefully it will at least inspire you to find a better solution than slides.

I used to be like you. Well. I never walked through slides in the meeting. I always drove a short (3ish items) agenda. My goal was discussion, not presentation. But I did start out using a deck.

I still cringe a little at the thought. But one of my startup principles is “Innovate only when necessary.” Your business requires a certain amount of breaking new ground. But don’t add risk by doing something unnecessarily new. If I avoided everything I thought was dumb I’d never get anything done.

Everyone else did board decks. My team was used to them. 🤷‍♂️ Sure, we’ll give them a try.

I hated it.

We spent too much time, on the wrong work, and did a poor job in the end.

Wow. The team spent so much time on fonts. And arranging images. What, exactly, is this adding to the board meeting? I understand: An ugly deck makes us look bad. But it seemed like we were spending a third of our time prettifying something instead of actually communicating.

There’s a good reason it was so hard to make them attractive: We had a ton of information to convey. We had to include detailed information about sales, marketing, engineering, and operations. The reader needed to quickly gain a sense of what was working, what was not, and what the vectors were around the company. No amount of picking fonts and rearranging images could deliver that understanding with PowerPoint.

So one quarter we ran an experiment. It was early on, only a year or two after our first round.

I gave each member of my team a choice: You can produce slides, or prose (i.e., plain text, using full sentences and paragraphs). Unsurprisingly, sales and marketing picked slides, and engineering and services picked prose.

What a stark difference.

The prose was done faster, communicated more, and just felt so much better.

Experiment over, prose won, we switched.

But how?

I don’t remember exactly how the process evolved. I do remember where we ended up, six years into using producing what we called board reports.

We did all the writing in Google Docs. We could all work at once and not step on each other’s toes.

I would build a skeleton of the report: Write out each section heading (“Summary”, “OKRs”, “Product”, “Marketing”, “Sales”). Then I’d use a comment to assign each section to the relevant executive. They’d either produce the text themselves, or do so in partnership with their team. Sales, marketing, and finance would include a lot of charts and graphs; product tended to stick to prose with a couple of diagrams or screen shots.

As people filled out the document, I played a few roles.

I spent most of my time assessing when someone was done. I’d read through people’s work and mark something that was insufficient, unclear, or missing with a comment in Google Docs. These are easy to spot even when scrolling through a fifty page document. As people worked, they marked their progress as done or ready to review. A completed section was easy to recognize: All comments and suggestions were resolved.

In this way, I could scan a large document and instantly see where work remained to be done.

My second job was overcoming a shortcoming in Google Docs. Or maybe a lack of training of office workers. Docs has built-in headings, and if you use them, your document is visually consistent, and auto-generates a table of contents. However, most people who worked for me never used the headings. They’d make a headline bold and increase the font size. So I had to go through the entire document and correct the markup. This was probably a quarter of my time.

By the end, I delegated this to a senior copy-editor who we trusted to see the entire document in process.

My last major role, and the only one that resembled the work of a CEO instead of an editor, was to ensure we were telling a single, coherent story. I’d write the summary to set the key messages. Then as I assessed everyone’s work, I pointed out inconsistencies or gaps. Most of this simple editing: Ensure all of the text used the same voice (first person plural, usually). It involved plenty of strategic work, though: tying company goals to team performance, ensuring the whole story was told, and asking everyone to cover the ‘why’, not just what happened.

You can guess this process triggered a few tense side conversations as I dragged information to light.

That, in the end, is the real point of the board report: Make sure we all understand the true state of the business. The writing was more important than the reading. It was on me to ensure we did the real work, rather than just packing it with information without saying anything.

I usually spent about four hours on it. Again, on a fifty five page report. My team each spent 1-3 hours. I did have the odd executive here or there or spend more like four or five hours on their part. We also never invested enough in automated reporting, so I’m confident some parts of the org had to work harder than I’d like to admit to generate their charts.

We targeted completion at least a couple of days before the board meeting. I’d share it with the board as a PDF. A couple of times I tried sharing it as a Google Doc (copied, so they can’t see the edit history), in hopes they would ask questions that could drive the agenda. It never got much engagement so I stopped.

Without a board deck, what did we actually talk about? I mean, without slides driving every minute, don’t you lose track?

No way. I ran a tight ship. But we measured time in half hours and big topics, not individual clicks.

My board meetings were usually three hours long. I’d spend an hour with just the board discussing high level status of the business and team. Then we’d take an hour and a half to cover our agenda, usually with portions of my team in the room. Then we’d spend half an hour at the end again just with the board, discussing what we learned and what we expected to do about it. This is when we also assessed individual executive performance. By the end of my tenure we also had a few minutes set aside for just the board, with me absent.

This process created space for deep conversation in the meetings. Everyone who read the report (which was, well, nearly everyone) was caught up on the business. They were fully prepared to discuss the three topics. And we had no structured flipping of slides to get in the way of discussion.

After the meeting, I edited the report as needed then sent it to the whole company.

Usually this involved removing just a line or two. Sometimes it was larger surgery, and others no changes at all. Mostly I cut out discussion of personnel changes, or removed sentences that required more sensitive, political phrasing than I practiced in these reports.

The end of this cycle ensured everyone involved in the company was up to date on, well, everything. Goals, status, progress, weaknesses, strengths.

I don’t know if everyone should use this process. I know many people were raised by American business to think slides are the best form of communicating. That’s a hard habit to break. I won’t even judge you if you use slides during the meeting to display the agenda and schedule, and maybe key images.

Slides are perfect if you want to tightly control the message, and not leave much room for hard questions.

But if your goal is to do real work in board meetings, skip the deck and write a report.

Entrepreneur, Stage 1: Bootstrapping, Burnout, and Babies

luke@lukekanies.com (Luke Kanies) — Tue, 07 Jul 2020 00:00:00 +0000

How I got here, how it went, and what happened along the way. I didn’t want to start a company. But I had no choice.

I was a SysAdmin after college, because I tried everything else and got fired from them all. I had seven jobs in two and a half years. I’m very fireable. System administration was just the chair where I happened to be sitting when the music stopped. More a safe, fun place than a source of deep passion.

By that point in my career, I was a little easier to keep around. More importantly, I had become worth the hassle. I did good work because I liked the puzzles.

I had a particular way of working. My boss would say, “You should do this thing, and you should do it this way.” He did not look at how I worked, only the result. That gave me the freedom that made the job worth it. When I told him I had finished he would say, “Great, how did you do it?” and I’d say, “Look, is that a bird?”

I automated everything I could, whether it needed it or not. Automation has a built-in reward mechanism. I would take this well-paying but stultifying job - Type this command 1,000 times - and I would reframe it: How about I tell the computer to type the command 1,000 times? It will work. I’ll watch. Bam! Now I can move on to other fun stuff.

Over time I did so much automation I kind of ran out of work. I was in Nashville at the time, while my wife was getting her PhD, so there were no interesting jobs that needed my skills. Hmm.

I could go to business school, but - sorry! - I don’t have any respect for the MBA. Everything I hear about business school is how valuable the network is. If I want that, I’ll take a cruise. I thought about going to law school, but it is so expensive you have to become a lawyer afterward. I didn’t want to be a lawyer. I just wanted to change my career.

So I was like, I’ll find someone who’s doing what I want to do-building a product to help people like me-and I’ll go and help them.

Oh my god, that was miserable. I lasted five months.

Commuting back and forth between Boston and Nashville did not help. I also had the brilliant idea of commuting seven miles each way by bike. In the winter. In Boston. I gave myself permission not to ride if it was under twenty-seven degrees. Being on the road in Boston is dangerous in a tank. On a bike, in the snow, was a cruel joke.

But mostly I just hated our software. I hated what we were building. At one team meeting, a senior developer said, “What does it matter what our customers think? They’ve already bought the product.” Reaction to that statement - nothing at all - told me I was in the wrong place.

So I left.

I got home. I said, I have a little money saved up, and I’ve tried everything else, and now that I think about it, I guess my dad was kind of an entrepreneur. I mean, he did run his own business for thirty years. Technically. I suppose.

Maybe I should start a company?

I know everyone in the world who is building automation tools for sysadmins, and none of them are going to build a business. “I built this, so, obviously, it’s the best.” But they’re only interested in publishing papers and getting academic tenure. Their software was already perfect, so they saw no reason to listen to anyone’s reasons for not using it.

I thought, what if I build something? And then listen to the people who are using it? (And maybe those who aren’t?) Hmm. Could work.

I quit my job. Well, I quit my job first and said, “Eh, I should probably find a way to eat.” So after trying everything else, I started a company.

We lived on my wife’s generous graduate student stipend of $23,000 a year - the job I quit paid $110,000 a year - and, like I said, I thought I had some money saved up. At some point the IRS sent me a letter that said, “We disagree,” and it turns out when the IRS disagrees with you, well, you know how that goes. And even if you’re right, by the time you prove you’re right, “Ok, I had ten grand, and I spent ten grand on a lawyer proving I have ten grand, and…” Just send them the check.

So I was broke when I started my company.

As a sysadmin, you’re not a developer. People will tell you: In DevOps, everyone’s a developer. Those people are lying to you. Or selling something. Which, you know. So I had to become a developer. I had written some code before Puppet, maybe 5,000 lines total. But by the time I handed it over, it was 130,000 lines of code.

The people I handed it to regretted my learning experience.

I adored it.

I learned a lot. It was, to be frank, super fun. One of the densest learning periods of my life. Programming is the best puzzle. I find it harder to step away from it than anything else I’ve ever done. It’s been two days since I ate, I think my wife has been trying to get my attention for the past twelve hours, I should probably … and then I try to move, my legs don’t work. I’m lightheaded from hunger and my feet are tingly.

Good times.

After about ten months I got my first paying customer.

I often advise other entrepreneurs. Much of what I tell them is to avoid what I did. I only had a vague idea for how to make money. I figured, “I’m confident I can make something valuable. I kind of have a plan, but I know my plan is stupid. If I bring my plan to people and listen to them, that could help make my plan less stupid.”

This is not that bad of a strategy! But it’s not exactly specific.

I didn’t really ask myself: What is my overall business going to look like? How will I get there? I started with services, because I’d been consulting for a while, and I was confident I could make enough money to eat. I know investors are down on services businesses, or anything that doesn’t look like a founder throwing themselves off a cliff with what they hope is a parachute. But you gotta eat. And services are a fantastic way to make money while you’re figuring things out.

I had a lot to figure out.

At the time - 2005 - there were a lot of open source companies out there. When I say a lot, there were four. I thought, “They’re doing well, I will copy one of them at some point later on.” That was not that great of a plan. Two years later Red Hat was the only one left. They’re a software powerhouse today, but they went public during the bubble as a T-shirt and mug company. There’s no copying that.

I did start making money, though. We consulted for three-and-a-half years. “We.” I was the only employee. About three years into the company, I discovered one day that I was incredibly burned out. This was the first of three major burnouts for me at Puppet.

Burnout Strikes

I distinctly remember realizing I was burned out. I was standing next to my wife, at the doctor’s office, looking at an ultrasound. We just learned we’re going to have twins, and I get a sudden flash of insight: My life is unsustainable.

I personally can’t recommend, when you’re in a bootstrapped startup, planning to have a baby. I would work especially hard to avoid having more than one at a time. But that’s what we did.

(Speaking of which: All you people who had your babies serially, you’re lazy and you don’t know what you’re doing. You think you had it hard. We were tested. Y’all are amateurs.)

The technician said, “Oh, you are going to get scanned a lot.” Um. You’re going to have to explain that one. She told us we were having two. We laughed. She must be incompetent. Just because you have twins (she did) doesn’t mean you can recognize them in someone else. While using an ultrasound wand. Which is your job. Scan… scan… BING! The two fetuses clearly popped into view. My wife would have fallen over if she weren’t already lying down. My knees shook. I thought, I can’t do this anymore.

I had been working every hour I could. I counted once: It was about 72 hours in my busiest week. There are people who say, I work 100 hours a week. You might stand there 100 hours a week. I’m skeptical you’re working. Based on what I know about productivity, I hope you’re not.

I couldn’t do it anymore. Since February 2008 or so, coincidentally the same day I found out we were having twins, I haven’t worked more than 40 or 50 hours a week. No evenings and weekends. I might dabble sometimes, but I won’t let it become a pattern.

Don’t worry. I managed to burn myself out two more times without those extra hours. It can still be just as bad. Pack that intensity into fewer hours, and you’re all good.

So. I need help. How?

Getting Help

I had tried to hire people in the past. Both of them were misses.

The first hire was the most notable. In the three months it took to figure out he wouldn’t work out, the best person I could possibly have hired became available and then unavailable. This guy’s biggest impact was ensuring I couldn’t hire the person who would have been most helpful.

There’s one more crazy story about him. In the middle of his interview at my house there was a drive-by shooting next door. He had taken a bathroom break when the shooting happened. They weren’t trying to hurt anybody, just shooting up a car to send a message. One of the bullets ricocheted off the car, then my porch, and broke my front window. He came out of my bathroom, and I said, “Are you ok?” “Yeah, why?” “No reason.”

I needed him to work in my house.

(Yes, I did actually tell him. Eventually.)

When he didn’t pan out, I concluded, I guess I just can’t hire. I’ll do it all myself.

Pro tip: Don’t do that.

Puppet worked in spite of these decisions, not because of them.

Things had changed, quite suddenly. I needed help, and now.

I hired the only people I could think of who might do me a favor: my college roommate and my best friend. Two separate people. Again: Don’t do this. I paid them full salaries.

Years later, I realized, “Wait a minute, if I was paying them full salary, they weren’t really doing me a favor, were they?”

Burned-out people make low-quality decisions. Your brain is gone, and you’re stupid. You work too many hours, you get burned out. You hurt your business doing this kind of thing. Get sleep, eat well, get exercise, step away from work. It’s good for you.

We were making a few hundred grand a year. And by “we” I mean “me.” I’m the only person consulting. I’m getting a little help with the code and stuff.

But now I’m going to hand all the consulting off to my best friend. “Ahh. I can see the light.” And by light, I mean impending twins.

The transition is bright in my memory. He was shadowing me. Μy last gig, his first one. “Hey, funny story, tomorrow this is your job.” We were in San Francisco, my only development gig fueled by Red Bull. I had made a promise to Stanford University, in exchange for some money. If I did not keep that promise by - I think it was - August 31, the Sunday after my gig ended, I had to give the money back. Of course I didn’t have the money anymore. I had to give them the code instead.

I’m at my client’s office during the day, and back in my hotel room at night pounding energy drinks and my keyboard. My kids are due any day, it’s my last flight, my last trip before they are born.

I finish it. I ship it at 1:00 a.m., send Stanford a note with all the details, and go to sleep.

My wife calls me two hours later and says, I don’t think it’s a drill, my water broke.

Well. I’m in San Francisco, and she’s in Nashville. You cannot get from San Francisco to Nashville fast enough to catch a baby. Everyone told me, “Now don’t worry, it’ll take 24 hours.” The kids had other plans.

Seven hours.

I was a father before I landed in Dallas. Cell phone pictures in 2008 were terrible, but they were enough to make me cry in the aisle.

Once again, things not to do, but it mostly worked out. My kids didn’t even notice.

My mother-in-law is actually thankful. She got to be in the delivery room instead. She would have been staring through the window if I had been there. It was great for her, and a great bonding experience for them. It was just, you know, complicated for me. If I’m going to flail at fatherhood, I could at least be present for it. Absent bad father is just a step too far.

That was summer of 2008. We were a little over three-and-a-half years in at Puppet. Lots of change all at once. We added two people and two babies. The business was picking up. I was spending more of my time at events and out in the community than writing code. Mostly this meant that the code wasn’t getting written, rather than that I had delegated it.

Again, my wife was getting her PhD. Nashville is kinda my hometown, and so as a result I, you know, hate it. I always told her I wouldn’t be at her graduation, I would be in the U-Haul honking the horn.

But she was pregnant with twins when she graduated. I was running a bootstrapped startup. We couldn’t afford to go anywhere.

What it all means

The birth of our kids was more than a turning point for our family. It transformed Puppet. It forced me to acknowledge I could not do it alone. I brought in help before they were born, and by the time they turned one I’d raised a funding round and moved to Portland.

In the four-and-a-half years of bootstrapping, we went from zero to around $250k a year in revenue, and from one to three people. In the seven years after funding, we grew to five hundred people and more than seventy million dollars in revenue. More importantly, we had an impact on thousands of people and thousands of companies.

I think founder stories are important. They’re usually educational, and often inspiring.

But they’re myth. They are a specific version of what really happened, refined and presented. Often, the myth so obscures what really happened that the lessons are dangerous rather than helpful.

This is a key story in my founder myth. For better or worse, I’m not afraid of you making catastrophic mistakes by trying to emulate me.

They say you can either be a good example or a horrible warning.

I think this story proves you can be both.

The First Two-Million-Dollar Check

luke@lukekanies.com (Luke Kanies) — Tue, 30 Jun 2020 00:00:00 +0000

A single drink perfectly captures the weirdness of raising money for the first time. Photo courtesy of Dylan de Jonge

I found myself at a hotel with some friends. I was visiting Portland for a conference. Puppet’s first investment round – and mine! – was closing. The money was being deposited.

Have you seen a David Mamet movie, like The Spanish Prisoner? They’re fantastic. But eerie. Disquieting. They build up a story, brick by brick. Then they yank a few bricks away, exposing the whole story as a lie. Only a hollow truth remains, unrelated to your built up belief. It makes you question everything.

I’m waiting for the closing in this hotel, and I order a Macallan 18 to celebrate. This was back when it was only expensive, not egregious. I lift the glass, and I think:

The money is being deposited into my bank.

I think it’s a real bank.

I mean, they had, like, a website. And websites are pretty hard to… wait a minute.

Who introduced me to the bank?

The investors introduced me. They specifically wanted me to work with this bank. They’re the ones giving me the money. They wouldn’t say they’re giving me the money then give it to someone else. That’s a silly kind of fraud. I just have to trust them.

I sit there. Sipping my whiskey.

I think it’s a real bank.

I think I’m getting $2.25 million.

I had never seen a bank account with that many zeroes - and I still may not at that point! I have no idea what to do.

So I sit there. Savoring that delicious, delicious whiskey.

I didn’t mean to raise money. I was just focused on running the company. We had bootstrapped for almost four and a half years. I figured we were going it alone.

I had talked to people in the past about raising money. It was like Groucho Marx’s joke about clubs: I wouldn’t take money from the investors willing to give it to me. “Wow, I would love them as an investor,” you get nothing. Or, “I would happily give you money and ruin your life.” Hmm. Not really the deal I’m looking for.

One day at an event, an investor tracked me down. He said, I’d like to invest in your company. I said, That doesn’t sound right. A lot of investors say, We should talk. He said: We should talk on Monday. That specificity made all the difference.

He made a very confusing offer: We would like to write a $1.75 million check into a $2 million round. I said, how can you be that bad at math and work in finance. He said, Go find other, rich people that you know to give you the rest of the money. I said, you are, literally, the only rich person I know. He said, I just joined this firm. I am not rich. Then we’re stuck, I said.

I lived in Nashville at the time. There are a bunch of rich people there. But they’re all musicians. They don’t do technology. We most emphatically did not hang out. We weren’t going to fill this round through my network.

Eventually, by connecting me to their network of rich people, I was able to raise $2.25 million. Mostly through luck not skill. I didn’t build a deck. I didn’t run a formal process. I didn’t pitch multiple investors to get competitive term sheets. I pretty much did the exact opposite of the play book. The investor who filled out the round turned me down at first, but I heard his wife persuaded him. I don’t know if she liked me or was cursing him.

Once all of the investors are in place, you wait.

The things you learn in your first round.

Closing takes about thirty days. Five rounds later, I have no idea why. It takes thirty days, and it costs $30,000. One of the terms in the term sheet you get from your investors states that you pay for closing. “We’re going to give you this money, and then you’re going to give some of it to the lawyers.” Investors cap the fees, and the lawyers coincidentally hit that exact number every time.

I honestly don’t know what the lawyers do at closing. The documents are massively long, but they’re pretty much the same. At a late-stage company, I can understand: There is diligence to do (although not by the lawyers), financial data to look through (done by analysts, not lawyers), customers to talk to (by the investors, not the lawyers). At an early stage, though, there just isn’t much information. I don’t know what they do.

But it takes thirty days. And costs thirty grand. Says so on the term sheet.

So you wait.

But when that waiting stopped, boy howdy did things move.

The money did get deposited. It was a real bank after all.

Within a month I’d moved from Nashville to Portland. Within two months, I had my next three employees. And within six months I had a team of ten.

Raising money set us off like a rocket. Bootstrapping for more than four years provided a fantastic foundation for quick growth.

Looking back, I’m glad we raised money. I only wish we had done it earlier.

How TechCrunch is like the Iliad

luke@lukekanies.com (Luke Kanies) — Thu, 21 May 2020 00:00:00 +0000

The drive for social status created the worst, most important part of the Iliad. Now it’s filling up investment announcements. Picture by Mikuláš Prokop

My fancy liberal arts school hazed me, like it does all students: I had to read The Iliad and The Odyssey.

We did more than read. We wrote. We talked. We dissected, for meaning and history. Me, and a dozen other kids I’d just met. It was school, after all.

The Odyssey is great. A proper story. Easy to read, and easy to see why it stuck around.

The Iliad is… not. It’s hard to read. Everyone in it is kind of a jerk. The biggest jerks are the biggest stars. The entire story rotates around a woman - Helen - without giving her agency. Maybe she didn’t want to go home?

For all its difficulty, it’s the more important book. Studying it taught me a lot.

Founders could learn from it even today.

In a hard book to read, one section is by far the hardest, weirdest, and seemingly most pointless. We called it the Parade of Ships, but Wikipedia uses the less glamorous “Catalogue of Ships.” It is exactly what it sounds like: A description of a lot of ships. More than a thousand. You know. Because Helen’s face was so beautiful it launched a thousand ships.

This gives us the millihelen: Enough beauty to launch one ship.

The Catalogue is scintillating:

First the Boeotians, led by Peneleos, Leitus, Arcesilaus, Prothoenor and Clonius; they came from Hyrie and stony Aulis, from Schoenus, Scolus and high-ridged Eteonus; from Thespeia and Graea, and spacious Mycalessus; from the villages of Harma, Eilesium and Erythrae; from Eleon, Hyle, Peteon, Ocalea and Medeon’s stronghold; from Copae, Eutresis, and dove-haunted Thisbe; from Coroneia and grassy Haliartus, Plataea and Glisas, and the great citadel of Thebes; from sacred Onchestus, Poseidon’s bright grove; from vine-rich Arne, Mideia, holy Nisa and coastal Anthedon. They captained fifty ships, each with a hundred and twenty young men.

That’s just the first paragraph! Every time I read this I delight in its nothingness. Now that I don’t have an essay due.

This litany, 2,500 years later, wakes our deepest fears about dusty old books. You’re probably feeling pretty good about skipping it. Yet it drove people to tell this story again and again. Being in it mattered. To your family. To your village. To everyone in Greece. Without the Catalogue of Ships, The Iliad might not survive.

Retelling a great story would always draw a crowd. (Remember: Both of these books were told in oral form long before they were ever written down.) But giving every listener a chance to brag or shrink because of the behavior of one of their ancestors… jackpot!

I was reading a funding announcement recently, and was struck by this:

Investors in the $10.1 million round for the company were led by ArcTern Ventures and joined by new backers Capricorn Investment Group, Incite Ventures. Previous financiers in the company included Wireframe Ventures, Congruent Ventures, Ulu Ventures, Energy Foundry, Hardware Club, 1/0 Capital, and Wells Fargo Strategic Capital […].

That’s a long list. Especially so for a company likely raising only its second round of funding (based on the amount).

Then it hit me:

These investors are listed for the exact same reason the ships are catalogued in The Iliad!

The Greek warriors were fighting for timé, a kind of honor and fame. The stories helped them pass it on to their descendants.

Investors are fighting for the modern equivalent (named, ironically, after a different, also unpleasant Greek story). Now it’s earned in investor announcements on sites like TechCrunch, not ship descriptions in stories told in the town square.

This is more funny than bad. There’s value in being able to track down which investors work with what kinds of companies. More openness is a great trade-off for a little exposure for the investors.

Still. Seeing the parallel was a delightful lift to the morning. I have a science degree but a liberal arts education. I love what the combination has done for my career. It’s nice to have it be a source of humor, too.

The parallel provides a lesson for founders:

The catalogue of ships describes a thousand vessels, and far more people. But most of them were never mentioned again in the story.

Don’t look for those involved in the investment. Look for who helped the company succeed. Who wrote the first check.

P-Hacking in Startups

luke@lukekanies.com (Luke Kanies) — Wed, 06 May 2020 00:00:00 +0000

Science has a problem.

It’s kind of broken.

Well. Not all of it. Mostly the social sciences and medicine. And I don’t just mean the fact that they consider Freud canon.

It started with a trickle. A retracted paper here. A study that couldn’t be repeated, there.

Then someone decided to get systematic. It opened the floodgates. A study in 2016 showed that 70% of scientists had failed to replicate another scientist’s work, and fully half had failed to reproduce their own work.

Reproducibility is fundamental to the scientific method - it’s supposed to be a study of the natural world, which doesn’t change all that often - so what does its absence mean? Are we incompetent? Can we trust anything? Do we know anything?

The high failure rate of venture-backed startups is its own kind of replication crisis: “How could my company fail? I followed the growth-hacking, blitz-scaling advice from the founders who made it big!” I don’t mean to give blogs and podcasts the weight of peer-reviewed science. But our industry seems to trust them as if they deserve it.

What does it mean if a founder can’t get similar results when following the practices of another?

Science has begun to heal itself. It’s time for startups to go through their own reckoning. Their methods are failing most people. It’s time to learn why and how to get better.

What’s wrong with science?

The crisis in science has multiple, interconnected causes. A lot of them come down to taking techniques from simpler systems and applying them to the far more complex study of humans. The practices useful for studying minerals also worked great on metals, but with people? Not so much.

One of the most famous examples of these studies that fizzle under scrutiny is the marshmallow experiment, conducted at Stanford University in 1972 on the children of students enrolled there. It produced original, important conclusions on the ability of children to endure delayed gratification, and later studies showed that ability was highly correlated to success later in life. Suddenly we’ve got a new tool for understanding how successful you’ll be at a very young age.

Or… maybe not. Further studies showed the original work was actually just exposing the socioeconomic background of the kids. If your family is well off, you are comfortable with delayed gratification and, just coincidentally, are also likely to be well off when you’re older. If you’re from a poor family, delayed gratification is harder to accept and, huh, you’re also more likely to be poor than those kids of rich parents.

Once someone reran the study with a larger group of kids (900 instead of 90) and controlled for socioeconomic background… the effect largely disappeared. It’s not all that surprising that kids with no food insecurity are better at delaying gratification and also will be more successful in life. It certainly doesn’t grab the headlines like announcing that kids who can wait five minutes to eat a marshmallow will earn more money than those who can’t. No HBR article for that one.

It’s been almost fifty years since this study was published. That’s five decades of science based on flawed work, five decades of science that has to be unwound and retried. The longer these mistakes last, the more expensive they are to fix. And like that HBR article above, many conclusions never get retracted.

One particular “technique” has helped trigger the crisis in science. Many a growth-hacking product manager has fallen into the same trap. They can only be rescued through discipline and rigor.

The how and why of P-hacking

Abusing data is a sure way to get bad results. Unlike startups, scientists rarely just make up their data. They make more subtle mistakes, like P-Hacking. This probably sounds pretty cool, but it’s actually a common form of data misuse. Wikipedia describes it this way:

…performing many statistical tests on the data and only reporting those that come back with significant results.

It works like this:

A researcher comes up with an idea for a study. He collects a bunch of data, runs the experiment and… no dice. The idea didn’t pan out.

Hmm. “I have all this data. I can’t just throw it away.”

So he starts slicing the data looking for something that stands out. After a while, sure enough, he finds some correlation that is strong enough to stand up - usually its P-value is under 0.05, and thus considered statistically significant. He publishes this in a paper and looks like a genius. It gets big exposure in the press. Journalists love weird and surprising science. They can report on it without understanding it.

But no one can reproduce the work. The paper gets retracted. He gets uninvited from the big conferences. (Don’t worry. The papers never follow up and publish the retraction.)

What went wrong?

He left out one key piece: How he got the data.

Let’s say he thinks breastfed kids are healthier than bottle-fed kids. He sets up a study that tries to isolate just these variables, which means he wants his population to be reasonably homogenous (similar quality of life, similar locations, etc). Put simply, the difference being researched should be the only material one in the population (unlike in the marshmallow experiment).

But then he looks at the data and - like most of these studies - find there’s no significant difference in health outcomes between breastfed and bottle-fed kids.

He could just toss the data. But, well, he’s already paid to collect it. He’s got all these graduate students who are working nearly for free. He might as well try something. So he puts a student or two on trying to find useful results.

They nearly always do, but… that success kills his work. All those controls to make it work for his original experiment fatally bias it for other studies.

Let’s say he discovers that the study participants who were bottle-fed tended to move around a lot more than people who were breastfed. He concludes, oh, wow, getting bottle-fed causes you to hate your parents and move away. (Yes, this is exactly the kind of headline that would get picked for a result like this.)

He has not proven that. All he has shown is in this particular - probably small, and certainly narrow - data set, that happens to be the case.

He should throw away all existing data. Start from scratch controlling for everything except this new variable under test. Only then can you look for correlations between how a baby was fed and mobility.

But he was too lazy or scared to do that. He found a match in that smaller, biased data set, and then published the results without admitting the problems in either his data or his methods. A few decades ago he would have gotten away with it: A big splashy result on publication, and then everyone just assuming this was true, with no attempt to reproduce and no real questioning of the result.

Today, no chance. Science has developed defenses against this kind of malpractice.

Preregistration of experiments is a key tool.

Researchers register with a central database that they are going to study the health of breastfed vs. bottle-fed babies. When they get results, they point to that registration and say, see, this is what led to my data collection.

If they then wanted to publish some other study, people would say, no, you didn’t pre-register this, which makes us suspect you’re p-hacking, so we’re going to do a deep dive on how you got your data. On second thought, we’re just going to reject your paper. Come back when the results hold on a clean dataset.

This might not initially seem to have anything to do with startups. Product managers and marketers aren’t commissioning studies - and they certainly aren’t controlling for variables!

Hmm. If you look at it a bit funny… Every data-backed marketing campaign and feature launch is an experiment.

Let’s build an analogous example.

A product manager builds a new feature, and because he’s growth hacking, he has lots of telemetry to tell him exactly how people are using it.

His theory is that people will use this new feature in some specific way. But he builds it, ships it, and observes, well, hmm, no, almost no one is using it. It’s a bust. I’m sure you’ve never worked on a project like this, but trust me, it happens.

Except… hey, there’s this small group that is using it, and widely. He looks into it more closely, and realizes they’re using it at 10x the rate people use the rest of the product. So he changes plans, and he rebuilds the feature around the specific thing those few people were doing with it.

Wait, what? No one uses that feature, either, and even worse, the people who originally used it aren’t any more, now that it’s focused on their actual usage!

What went wrong?

You got caught p-hacking

The data set from his failed feature is bad data. He got the most important result: This feature did not work well for his users. He wasn’t willing to let go of failed work. Just like the scientists, he went looking for some other way to reuse it. And instead of developing new hypotheses and running new experiments, he took his biased data and tried to find new correlations cheaply.

Unfortunately for him, he did.

But when he published the new feature, he is faced with a harsh truth: Those few people who were using the feature in unexpected ways don’t look like the rest of his users. A new feature built for that purpose doesn’t help everyone else. And because he relied on data to make his decisions instead of talking to actual users, he learned too late that those unrepresentative users were doing something even more weird. His simplified feature actually removed that weirdness in the name of simplicity that everyone can use.

So now he’s two features in and nothing to show for it. So much for growth-hacking.

How do I fix it?

The solution is very similar to what science has done.

Connect your data to experiments. With discipline. You must get new, clean data for each new test. I know this is anathema to modern data-oriented product management. But it’s the only real way to trust your results.

That word discipline is key. You don’t need to build some international central registry. Whatever your mission statement says, you’re not really saving the world, and you’re not actually doing science. You’re just trying to build a product people love. What you need is rigorous internal practices, and to hold each other accountable so you can’t cheat at statistics.

Unfortunately, this requires you let go of one of Silicon Valley’s most cherished and wrong beliefs.

No, you don’t learn more from failure than success.

Experiments fail. This might be an important part of the process, but it’s not very valuable. Congratulations. Of all the possible ways you could fail, you’ve discovered one of them. Don’t let it go to your head.

Don’t work too hard to salvage that failure. You’re p-hacking, and just making it worse. Yes, obviously, you get personal lessons. You might be lucky enough to learn something that triggers your next experiment. But you have to go run that separately.

You can’t build on the detritus of failure.

So my data is now worthless?!

Of course not. I still rely on data for all kinds of problems. One of the great things about building a company today is how easily you can get information at scale.

But never let yourself forget that your data is heavily biased, especially by how it was collected. One of my favorite examples is from when YouTube dramatically reduced response time. Their average response times went up! Suddenly people with much worse connectivity found it worth using, making the average worse. The developers thought they were helping existing users, but the biggest impact was in creating new ones.

You have to recognize your job isn’t to find some way to make the data valuable. Your job is to make high-quality decisions. Use data when you can. If you don’t have data, go get it.

But the job of the data is to inform you, not give you answers. Use it to hone your instinct, to improve your decision-making. When something doesn’t add up, go talk to the actual humans who are the source of the data. And even, spend some time with people not represented in it.

If you’re working at a software startup, you’re not doing science (even if, like me, you have a science degree). But you should still take advantage of its discipline and practices.

Don’t stop at protecting yourself from P-hacking. One founder’s success might be hard to replicate for many reasons. Gain what lessons you can. But don’t blindly trust others’ story of their work.

Because failure on your part won’t be paired with the retraction of a Nature paper, it’ll be an announcement of layoffs in TechCrunch.

The Automator's Dilemma

luke@lukekanies.com (Luke Kanies) — Fri, 24 May 2019 00:00:00 +0000

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

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

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

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

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

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

Ah. No.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

My Losing Battle with Enterprise Sales

luke@lukekanies.com (Luke Kanies) — Fri, 25 Jan 2019 00:00:00 +0000

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

Photo by Tim Trad

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It’s a helluva boss fight.

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

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

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

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

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

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

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

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

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

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

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

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

A Writing Report: Two Years In

luke@lukekanies.com (Luke Kanies) — Thu, 17 Jan 2019 00:00:00 +0000

My biggest articles, lessons learned, and plans for this year.

Photo by Elijah O’Donnell

I started a daily writing habit two years ago. If you look at my output since then, it’s a bit haphazard: Lots of advice to founders, discussion of venture capital and the blockchain, and a bit of telling my own story.

My own review of my writing is mixed. I think the writing is good, and in most cases I think the topics are important and my viewpoint adds something. But the writing style is painfully far from how I talk, and thus too far from how I think of myself. There’s little humor in it, as one example, which is counter to how I present, or even just talk with friends. I have found a voice, but not my voice, nor one I’m terribly fond of. Maybe I read too much fancy writing in college, and too many Serious Business Books since then, but not enough that didn’t take itself seriously.

I expect one of the main reasons I struggle to include humor is that my jokes tend to be self-deprecating, but I still don’t feel comfortable writing much about my failures and problems at Puppet. I’m still involved, but can’t claim to be a spokesperson or any such thing, so a lot of topics aren’t available. Yes, these are my stories, but I recognize how much of an impact I could have on the company, its employees, and its community if I were flippant about my failures of the past. This was manageable when I was running the company, but doesn’t really work in this state. That can’t be the whole explanation, though, and I plan to do more experimentation this year to begin to suss it out.

I have mostly chosen topics by focusing on beliefs I have that others don’t. Some of this is insight I think is special to me, such as one of my favorite essays, Where Does Your Work Live, and some is straight disagreement, as in No, You Don’t Learn More From Failure. I still run into this last one all the time, and I love having a well practiced argument for how silly this popular belief is.

My series on VC was very different: An attempt to share with a wider world what I’ve learned about how venture works from the inside. Of course, I’m not inside venture in the normal sense: I raised a bunch of money, and spent a ton of time with investors, but have never been an investor myself. But my own learning over those years didn’t seem to be represented anywhere, and based on how often this is brought up, it seems people found it valuable. A year later, it’s a bit unclear even to me how much this series is an explanation of venture capital or an indictment. I truly do believe venture is totally broken, and it seems much of the rest of the world has now come to agree, based on the conversations I’m seeing. Even so, it is actually a fit for some people, and they should know how it works internally. Hopefully the series helps them.

I did a series on the blockchain, too, and this was much more an exploration on my part than an explanation. I had plenty of education and opinions going in, but I didn’t really know what unique insights or beliefs I had until I started writing. This is probably my best example of learning by writing. I started with the knowledge that the blockchain was primarily full of fraud and black market sales, and that I was more interested in the crypto legacy of git and BitTorrent than Bitcoin, but I learned a heckuva lot more in the course of exploring this area in more depth. I’m not sure anyone else learned anything; I’ve never had anyone mention these posts to me, nor seen them reposted anywhere. I am not sure what to take away from that.

My most frequently shared piece is Strategy is Culture. Even after all this time it still gets shared roughly weekly, which is more than all of my other pieces combined. This article took me more than a year to write; every week I’d try to write it, give up, then dash off something simpler and less important. I had to figure out a lot to get to the point where I could successfully explain how closely linked I think strategy is to day to day execution, and how that, in the end, is your company’s culture. It still feels like a fundamental insight that most other people are missing, something so important that my struggles at Puppet all make sense suddenly.

Unquestionably my most popular piece was Why We Hate Working for Big Companies. It was the only one I wrote that got mainstream visibility (albeit just a reposting on a sub-brand of CNBC), and it got shared far more often and widely than I could have hoped, especially given its length. Weirdly, after a big splash it has almost completely dropped off.

In addition to it getting the most reach, it also had the biggest impact on me. It forced me to express my weird combination of beliefs. In doing so, I realized how rare they are, and how important they are to what I do. It took a lot more work, but I eventually realized this essay introduces the topics I need to focus on, both in my writing and in my company building.

My interests today are at the intersection of economics, technology, and the individual worker. I’m educated and opinionated on each of them, but only by considering them together does a complete picture of my opinions and drive start to emerge. This piece on why it sucks to work at big companies is the first time I brought it all together, and I think that’s why it worked so well.

It’s also a longer piece than just about everything else I’ve published. I’ve tended to write articles around 1200 words, mostly because that’s right about what people recommend you write on a daily basis. But the success of this one began to make me think I might do better with longer works, and my struggles to get hard topics out over the last six months has helped validate that for me. It’s really hard to bring together a bunch of ideas into one coherent whole - it’s much easier to instead just write one article on each concept - but it’s more valuable and better work to do it all in one.

After two years of writing, my goals for the next year are, in no particular order:

Come closer to my real voice. This means being more funny, but also more relaxed. I feel like my writing style is too stiff, too formal, which is hilarious given how informally I speak.

Write more about what I think about. I have written a lot of things I believe, but mostly not written much about what’s filling my brain. I hope to do better on that this year.

Write bigger pieces. I think I’d worked through the bite-sized ideas that were fighting to get out, and now any effort to produce something easily digestible seems to require compromising the work, rather than making it better. I think it’s holding me back, not being a helpful constraint. I’m going to be a bit more willing to go long, and pull a complete thread together, even if it means plenty of people will skip it because of length or complexity.

Thanks for reading so far this time. I hope to keep you entertained this year, too.

The Rights You Lost When the Document Died

luke@lukekanies.com (Luke Kanies) — Tue, 08 Jan 2019 00:00:00 +0000

There are many upsides to the era of the smartphone and the cloud. But I’ll never forgive them for killing documents.

Photo by Daniel Zurnau

The limitations of mobile devices perfectly complement the strength of the cloud, as foretold by Sun Microsystems two decades ago: Your computers will be weak and hold no data, and the servers will be powerful and store everything. They were just wrong about what form those weak computers took (and, of course, who would be selling the servers).

I obviously love the benefits of mobility, of having an amazing computer in my pocket and having access to the world’s information pretty much wherever I am. And there are many capabilities we take for granted that you just could not provide without large central collections of data that the cloud enables.

But many of the changes in our tech landscape are accidental outcomes of cloud + smartphone. I regret them. And I want to fix them.

One of those big changes is the demise of the document.

You might think, no, I still have documents. I mean, yeah, I used to have Microsoft Word documents, but now I have Google Documents. Right?

No. The content you have in Google Docs is stored in a big database. Sometimes, when they choose to, you can treat it like a collection of documents. But it’s not.

This is pretty obvious when you try to use Google Drive. Compare using documents there to a Dropbox folder full of Word (or Pages¹) documents. One comfortably exists in a world of folders, hard drives, and file systems, and the other just feels…. not quite right. That’s because Google Drive is wearing the camouflage of a filesystem, but it’s a database in the back end, and the truth leaks through. We’re not fooled that easily.

It starts with a miserable user experience, but doesn’t end there. Because Google is storing all of your data centrally, you need their permission to use it. This is new.

Until the smartphone and cloud took off, Microsoft had a comprehensive monopoly in digital documents, in text, spreadsheets, and presentations.² To participate in business, you pretty much had to own Office. Their position was so strong they built a Mac version just to prop that platform up enough for it to look like a viable competitor. The market just didn’t see an OS as competitive without office.

But lo and behold, times change, and now you want all of your files online. Google wants to help you do it, and just happens to have a couple of fancy features you couldn’t (at the time) get without uploading everything. Real-time collaborative editing is actually pretty sweet.

Microsoft worked for years to prevent other apps from reading their documents, but they seem to have stopped that at some point. I don’t know if they just gave up the arms race, realized they had already won so it didn’t matter, or actually felt the need to reduce their market power. But by the time Google acquired Writely and rebranded it as Google Docs, it wasn’t that hard to read these docs separately. This was a massive boost for Google (and theoretically smaller companies, but it didn’t turn out that way).

After all, all the docs you care about were right there, on your computer. You didn’t need to ask Microsoft for a copy; you did not have to export them, wondering what data was included and what was kept back. And the form you’d send to Google is the exact form you’d send to anyone else, via email or on a USB drive. Their ingesting of all of your critical data was pretty easy as a result.

But in 2019, things are very different. Want all of your data from Google Docs in the next new company’s fancy web app? Step 1: Export. That’s right. You have to ask Google to give your data. Because, and I hate to belabor this, you don’t have it.

Then your fancy app needs the ability to import the special arbitrary 100% proprietary format Google exports in. It’s true that some apps might allow you to skip this step: They’ll authenticate directly to Google and slurp your data down. But just like when Facebook shut down data access for Twitter and other competitors after building its own network by copying data from Friendster and others, Google will only tolerate this kind of integration when they don’t feel threatened.

You need their permission, their tolerance. Given their use of monopoly power to weaken Yelp, among many others, you can be sure they’ll have no qualms about quashing a budding competitor by making this hard if someone gets close.

So here we have two analogous situations, with almost identical data, but in one case you have your data, and in the other, you’ve got to ask permission for it. There are downsides to each, but there’s no argument they’re different.

Note that this isn’t really a question of data “ownership”. Google would probably argue that you do actually own your data, as might Facebook. You just can’t access it in a useful way.

I’m thrilled that the cryptocurrency/blockchain communities are driving a conversation around data ownership, but it’s still disappointingly naive. This concept runs up hard against the reality that digital copies are free, and it’s basically impossible to prevent people from copying data you’ve given them read access to. Conversely, “ownership” means nothing if I can’t get all - and I mean all - of my data in a useful form.

What they need to talk about instead is rights. Realistically, I can’t own my birthday. Would that be a copyright? Trademark? Patent? Of course not. It’s just a fact, and facts can’t be property. But we all know that my birthdate matters.³ I need the ability to prevent you from, say, publishing it widely, or using it in combination with other facts to impersonate me. These are legal rights, not aspects of ownership.

I miss the rights that documents gave us, now that we no longer have them. Because these rights were implicit, a consequence of the technology reality at the time, we did not even know we were giving them up. But we’ve got to fight now to get them back.

The first thing you can do is be conscious of this when you choose your tools. All life is a compromise, and sometimes it’s the right answer to give up rights for functionality. But many apps are functionally equivalent, yet make vastly different choices about your rights.

As one example, I recently migrated away from Evernote, because their business model is shifting to a focus on businesses, which, well, I am not. It was a nightmare. Even though everything in my Evernote notebooks was either a text file or a PDF, I couldn’t export literally a single thing as text or PDF. Well, that’s not true. I could export each individual item that way. But not the whole collection. My choices were HTML or a proprietary format. It took hours of manual work, and a lot of it I just dumped in a folder, never to look at again unless disaster strikes, because it wasn’t worth it.

Compare that to what I’m replacing it with: Keep It (as of today, anyway). I’m sure I’ll give up some features to pick it, but, ah, I haven’t found any yet. And all the files I put in it? They’re just - hold on to your seat, folks - files. I can open that directory on my Mac. I can add things to it. I can remove them. Then I can see them in Keep It. If I stopped using it tomorrow, I would have to, um, add the files to something else. Or use the Finder, or Dropbox, or something similar.

It’s obvious that Keep It respects the document, and they see their value as adding functionality on top of it, rather than subsuming it in some way.

This should be the gold standard. You should be able to adopt an app that gives you functionality, but does not take away rights.

In the age of documents, apps like Microsoft Word could try to curtail your rights, but other developers would be on your side trying to give them back. In the age of the cloud, and the smartphone, you don’t get that option. You no longer have rights, you have “permission”, with a side of binding arbitration.

I don’t think we can go back to the era of documents on a disk. But it’s worth looking back and asking: As we’ve gained so much, what have lost?

And then demanding that our software providers begin to give some of that back.

Although even Pages, and all of Apple’s productivity apps, weaken the definition of a document, because they use bundles instead of a single file. ↩
I was on team break-up. ↩
I can’t believe you forgot mine last year. ↩

Follow your weird

luke@lukekanies.com (Luke Kanies) — Thu, 13 Dec 2018 00:00:00 +0000

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

Photo by Elias Castillo

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

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

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

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

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

That weirdness is how we win.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Review of the 2018 iPad Pro

luke@lukekanies.com (Luke Kanies) — Thu, 29 Nov 2018 00:00:00 +0000

The sideways logo gets hidden, rather than fixed.

Photo by eleven x.

Yes, I know this photo is of the old model. But it perfectly captures what’s still wrong with the new one.

The iPad has been my primary mobile computing platform since a couple years after it came out. I’ve had every version since the very first, and I immediately replaced that one when a version with LTE arrived. I spent two months traveling with my family last summer and only used my iPad. I’ve taken countless trips with nothing but it and my phone to get work done.

I’m not mobile-only. I have a 5k iMac on my desk, and am far more capable and productive on it than I would be on anything else, because of screen size if nothing else. It’s worth noting that I’ve worked professionally on MacOS (Classic and X), Solaris, Linux (I tried nearly every distro available until around 2008, and even tried the BSDs), BeOS, and once in a while a little Windows. I had two 21" Trinitron monitors on my desk in 1999, and I’ve spent more hours than I could count fiddling with my computing experience to maximize productivity. Heck, that’s what ended up with my starting Puppet: I just wanted to get more done, faster. So when I say the iPad is the most productive device for me in many situations, I’m saying that within the context of twenty years pursuing exactly this.

I’m a heavy iPad user, and it’s really important to me. I use my phone, but I love my iPad.

That context is important for this review to make sense. We’ve seen many reviews of the new iPad that could be summarized as, “I’ve been using a Windows desktop for twenty years, and the iPad still can’t replace it for my use cases.” Those reviews are useless. I mean, unless you’re one of those people. Get a Kindle, I guess. This review is for people who are willing to shift work styles and recognize that different platforms optimize for different problems. Success for the iPad is more about whether it has valid and compelling uses rather than whether it works for each and every one.

The short version of this review is that I love the new iPad Pro, but I decided not to keep it. I already have two of the older versions at home. The difference between this and previous generations is not a big enough jump for me in the ways I use it, especially given I’m between jobs. For the things that were working great, they now work better, but more of the things that weren’t working, it doesn’t really make an impact.

Your scroll bar is telling you, though, that this is a much longer review. Settle in. (Or silently close the tab, and save half an hour of your life.)

How I fell in love with the iPad

I know some find that travel is explicitly where they struggle to survive without a laptop, but it’s where I flipped the fastest. The easiest explanation for why - also explaining the importance of LTE - is my pattern of travel when I was still running Puppet.

Here’s what it looks like if I have a laptop:

I show up at the airport. I find a seat, pull my laptop up, log in, and join the local wifi. Most of the time this doesn’t work, because airports, so I tether with my phone. Then I wait. No idea how long. I use Apple’s Mail, and the desktop version has consistently had some issues downloading mail efficiently, especially from Google. I’ve tried literally every other mail app; don’t @ me. So I wait. When boarding is called, or all the mail is obviously downloaded, I close my laptop. I have often found myself carrying an open laptop through the boarding line because it’s not done yet.

On the plane, once we’re at 10k feet, I process the mail. When I was running Puppet, I received about 230 mails a day, and sent about 30. Ideally a 1.5 hour flight between PDX and SFO (my most common trip) would at least get me to “no scroll bar in my inbox”, and sometimes even inbox zero(tm).

I land. If I am taking a taxi, I get in, open my laptop, tether to my phone, and let the mail start flowing out. Some of them make it. Some don’t. I’ll try to join every wifi network I spend more than five minutes around. If I’m not taking a taxi, no mail gets sent until I get to my hotel after dinner, most likely - I can’t do this while driving, and the trains are usually too far underground to get service.

I just spend the rest of the day dealing with inconsistencies in the inbox on my phone and the one on my laptop. 🤷‍♀️

Here’s what it looks like on my iPad:

Once I get on the plane, I open the mail app on my iPad to make sure it’s fully synchronized. I then put it in airplane mode, and start reading on it. At 10k feet, I lower the tray and start typing. I’m a little less efficient on an iPad than a laptop, so I get a little less email done, but it’s shockingly similar.

When we land, I turn airplane mode off. I open the mail app just to ensure it’s going to synchronize as quickly as possible.

I get annoyed texts from my team about the torrent of emails I’ve just unleashed.

That’s it.

You could argue that this says nothing about the iPad. Any device that was always on and had an LTE connection could do this, no problem. But of course, my other computers don’t and can’t have these features. I honestly don’t know why I can’t get an Apple laptop with an LTE chip in it, but I do know why it’s not running 100% of the time.

Once my primary travel computing use case - email - flipped, I found a way to make most other things do so.

There are many people whose primary use for computers is sitting in one place, working on one or two problems for hours at a time. I’d be surprised to find those people prefer an iPad. Even if I could program on one, I wouldn’t want to, because the screen just isn’t big enough to show everything, and I can’t have all the windows open that I need.

But as a CEO, my job was constant change, constant context shifts, constant movement. I craved depth, but usually in vain. The iPad fits that life perfectly.

That’s why I love it.

The iPad today

Everyone has said this 1000x times: The iPad’s hardware is great, it’s the operating system that’s lacking. I agree, but I have more to say than that. And it’s not just about features like reading files off a disk, which I doubt I would ever use.

Apple has to (ahem) think differently about the device altogether. They’ve gotten better: They’ve agreed it’s not just a big phone, it has different users, different use cases. It needs a different experience.

But they’ve barely begun to work through the consequences.

I love my iPad. I use it more than every other device put together. I have for years. It is great at so much.

But its user experience for absolutely mundane work is a shocking embarrassment.

I built an automation company to almost 500 people. Our software was built on the recognition that system administrators - the people who make your computers work for you - were spending too much time on menial tedious work, and it got in the way of their real work. Puppet helped restructure their entire work life, automating away the tedium and making space for the most important, most valuable work.

The iPad has provided me great new abilities, but forces me to take the long way to using all of them. If you were to watch me using it, you’d notice that a huge portion of my direct interactions with it are only necessary because of its failures, not my desires. Some of this is not a ton better on the Mac, which always focused more on simplistic usability than working hard for power users. Coming from a fully customized keyboard-driven experience in FVWM and its descendants, I was never going to be happy. I still miss focus follows mouse with no window auto raise. But man, it could be a lot better.

I need you to understand. I want you to feel what I feel.

On my desk, my mouse is less than an inch from my keyboard.

But every single time I have to take my hand off the keyboard - every time - a large buzzer sounds in my room, a million candle power red light starts flashing, and the overhead sprinklers turn on.

Ok, it’s not quite that extreme. To the observer. But that’s what it feels like to me. When I say I want to do everything on the keyboard, what I mean is every time I have to do non-keyboard interactions it is a massive disruption in how I work, move, flow. It breaks my interaction. Some of these are ok - scrolling is probably the least disruptive, although it’s such a core use case it’s amazing there’s no good option from the keyboard¹. But clicking into a text box? Selecting text? *shudder*

I grew up remodeling houses with my dad. Imagine a hammer that required I put it down every time I needed a new nail. Or a screw gun that required two hands to load a screw, so I had to hold it between my knees on a ladder. Insane. You could never get flow. You’d throw that stupid thing away.

That’s what it’s like to use an iPad.

Let’s just pick the simple stuff. Something I do every day, often multiple times a day. Let’s walk through each little step, get granular so you really see it.

I have to make a calendar event based on an email. I’m in Apple’s Mail, and the calendar app is next to it. Again, there’s an air horn next to me, a strobe light mounted to my left, and a bucket of water above my head, ready to tip over every time I touch the screen.

I’ll be generous. We’re making the appointment for today, so no need to navigate within the calendar to pick the right day.

Task one: Switch to the calendar app.

Oops. I foolishly have both apps on screen at once. You can’t shift focus between those apps. Or can you? Wait, what does focus even mean on an iPad? No one knows. I’m in Mail, so I know it starts with focus. I lift my right finger up, and select the slot on the calendar I want. The world explodes.

In this case changing focus would not have helped, because Google’s execrable iPad apps don’t really support keyboard shortcuts. Huh. The company whose keyboard shortcuts are so dominant in desktop email that everyone else is copying them, doesn’t even use them on mobile? Maybe if Apple cared, Google would? Probably not, but since Apple clearly doesn’t, why should they?

I wipe the water from my face, and am now in the new event pseudo-pop-up. Oops, I need to copy the email address of the person, because it’s someone not in my contacts. I slowly, cringing, move my finger back to the mail app. How many taps does it take to get to an email address? I’m not sure, but I think it’s about four. It should be Cmd-Tab, Cmd-R (to reply, which I have to do anyway), Shift-Tab a couple of times to get to the To field, Cmd-A, Cmd-C to copy the address (I can use arrows and such to get just one if I want), Cmd-Tab to get back to Calendar, Cmd-V to paste.

Yeah, not here. I think focus is now in the calendar app, so I have to touch the mail app again anyway. I hit the reply icon. I use Shift-Tab to get to the To field, which mostly works. I then try to copy the address. This fails at least 50% of the time. Like, just fails. I mean, the buttons on the keyboard work. But when I try to paste elsewhere, the clipboard appears to be empty. Or something. Nothing happens. Since I’d rather have a crappy workflow than an inconsistent one, I use my finger again to touch the email address. How does one copy an email address when copying doesn’t work?

You don’t! You drag! Because absolutely, the one fix I want to bad keyboard shortcuts is different touch experiences. I love that drag and drop is more powerful now, but can’t you get the basics working, too?

Honestly dragging is also inconsistent, but weirdly, I’ve found it’s more consistent than the keyboard. I frequently swap email addresses in a mail - when I respond to an intro, I swap the default ‘To’ person to BCC, and move the ‘CC’ to ‘To’. If I drag them around, it almost always works, but if I use the keyboard, it just… doesn’t. It fails differently all the time but nearly always fails.

Ok, so I drag it into Google Calendar. Hmm. I can’t seem to drop it on the Guest field. Maybe because it’s not the active text field? Ok, I let go, touch the calendar, and then tab to the guest field.

Hah! Just kidding. Tab doesn’t work, it just puts tabs in the event title. I touch the guest field, and drag again. This seems to actually work.

By now, I have successfully put a person’s email address in a field, and I’ve had 14 buckets of water dumped on my head, I’m flash blind, and I’ll never hear again.

I won’t bore you with the details of actually getting the rest done. Obviously GCal not having keyboard shortcuts of any use hurts a lot, but even better shortcuts would not help much, because the biggest disruption is switching apps back and forth, and once in an app, picking the correct field.

And before you tell me to switch to Fantastical or something, please. My calendar is currently showing eight separate calendar feeds, all different colors so I can easily tell them apart. E.g., mine, my wife’s, my travel, my kids, the two soccer clubs I follow (#gunners #RCTID). My main event feed further colors every event by event type. Just today I can see four different colors of event. And I only have one meeting I’m personally attending. Apparently no one else does this, because no other apps even come close to Google in effectively managing this overlay of info. Don’t @ me. I don’t know how you people live.

And also don’t try to tell me I should automate this whole process. Sure, you’re right. Except again, it would only work sometimes, I’m always dealing with natural language text that doesn’t easily parse, the automation would be brittle and I’d move from being pissed off at Apple and Google to being pissed off at my own code, and I’d spend my time trying to figure out how to build abstractions over similar automations on different platforms, version control them all, package and deploy them, and suddenly I’m trying to use Zapier with microservices in a docker container in a VM on my iPad just so I can create an event. That’s definitely better.

It should be clear to you by now that every time I do this from my living room, my basement floods, my neighbors call the cops because of the sirens, and the lights have knocked countless birds from the sky. It’s a disaster.

And this workflow is one of my most important, most common.

The basics just don’t work. Maybe you didn’t know you can “minimize” an email by dragging it by its top bar to the bottom of the screen. Where’s the shortcut for that? What about the one to cancel an email? Honestly just deleting email with the keyboard fails most of the time, and 100% of the time after the first few. Delete, delete, ooops now it doesn’t work. Of course, this is true on the desktop, too, so…

Everyone else, all the other app developers, they follow Apple’s lead. They know Apple does not respect the keyboard. So they don’t either.

But the thing is, this diatribe has nothing to do with the keyboard.

It has to do with my flow. And the flow of everyone who uses this device.

I love my iPad. But Apple has clearly not taken a critical eye to where it supports flow, and where it breaks it.

I grew up on a hippie commune in rural Tennessee. When I was about 7, the state built a bridge across a ravine, which shortened the drive to Nashville by 30 minutes. One bridge, and suddenly a trip we took all the time is an hour shorter, round-trip.

One little simplification can have a massive impact.

Apple is adding features, but not connecting them. They’ve run a freeway into town, but haven’t built all the feeder roads so people can use it. There’s a fancy bridge between two cities, but the roads to and from it are still gravel. There’s a high speed train between cities, but the stations are outside of town and you have to walk there.

It’s not enough to put things in place, they have to fit into a coherent, cohesive system.

And until Apple respects the iPad enough to really think about how it all fits together, I will finish my work day soaking wet. Brrr.

Now, about that new iPad

Naturally, I bought one of the new Pro models when it came out. I have the original (2016?) 12.9" at home, and also the 10.5" that came out in the spring of 2017, both with LTE and the keyboards, and one pencil to share.

I almost never use the big one. It’s just too big. It doesn’t fit into my EDC bag (mostly because that was specifically chosen to fit the smaller ones), it’s too unwieldy to read in bed on, and it’s just hard to move around like I do with my main one. I mostly use it to watch soccer games on while I’m making breakfast on weekends. I’d sell it, but we often have five kids at our house playing Minecraft or Roblox, and I would never hear the end of it if we were short one.

I think Apple did exactly the right thing by making the big one smaller and growing the screen size of the small one. I don’t think it will, but I really want the new big one to work for me. The thing I miss most about my desktop is the big screen. I want more space, bigger screens, multiple of them. I had two screens on every one of my computers starting in 1998, until I got this 27" iMac - the screen is finally big enough, and managing windows on multiple monitors on a Mac was just not worth it.

So, I got the big one to try it out. I bought it just before heading out to visit my family for the holidays. I left my smaller iPad pro at home, to force me to use this for everything, including reading books in bed.

I returned it on the 14th day.

I loved it. If I were still gainfully employed, I would have kept it. I’m having to optimize a lot for lack of income right now, and that goes big time into my decision. Even without that constraint, a lot is riding on iOS 13 to deliver real improvements. I’m expecting to be disappointed.

The reality is, the device is too similar to the two I already have. When I was less money constrained, it made sense to take every incremental upgrade. Today it does not.

For all my lack of keeping it, though, I think it’s worth sharing my experience. I think it’s enough different from others that it stretches the tapestry a bit.

The bigger one is enough smaller that it really does feel different. I could see myself traveling with just that, no smaller one - I just did for ten days. But I would have to replace the bag I have carried for years. A bigger bag would mean I’d pack more, and be less happy. But honestly, I think it would be worth it. I could consolidate to just one iPad, mostly portable but big enough to be more productive. I would love that.

One area performance was immediately obvious was loading photos. One of the things I love most about the iPad Pro compared to other iPads is just how fast it downloads from SD cards. last summer I took more than 6000 (yes, you read that right) photos, mostly on my Fuji XT-2, and processed them all on my iPad. The connection on the Pro is waaaaay faster than on the normal devices, and it makes a huge difference. The new one seems to download the photos even faster, so fast the thumbnails are shown even more slowly than the data makes it onto the device.

That being said, most of the speed doesn’t matter that much to me right now. I’m typing this on a 12.9" that’s almost three years old, and I suffer through the app reloads and web page refreshes that the new one did not force on me. But it’s a pretty minor sacrifice for what I do, which is mostly reading and writing.

One of the biggest features in this new one was a mixed bag. I love having Face ID. Sometimes. Apple stubbornly insists this is a portrait device. That’s wrong for the smaller device usually, but always for the big one. Like, literally, I never use it in portrait mode. I know some do, in a stand or something. I don’t. That poor decision by Apple compromises Face ID so badly that I think they’ll move the camera in the next release. Here’s why:

I’m right handed, so I use my right index finger for most touch interactions. This leaves my left hand to hold the device, move it around, etc. And when I do that, where am I holding it? Right over the camera.

Pair that with the fact that Face ID is built to be used less than two feet from your face, and it’s a bad setup. I am sitting on my recliner in my living room, and every time I use the device here, it would say, “Face too far away”. I grab it with my left hand to move it closer, and now I’ve got the camera covered.

When I got the iPhone X, it was a magical experience. I just did not notice Face ID. On the iPad Pro, I’m getting a constant “You’re holding it wrong” experience instead. I’m having to babysit how I log in or authenticate, and have constant friction. Again, all because Apple is wrong about how their customers use this device.

The other big feature is the new pencil. I would use this one more than the old one, but not a lot. I basically only ever use them when taking notes in meetings. That was much more important years ago, less so now, but it’s still not that useful for how I work. Most of my text apps don’t support it (e.g., the app I’m writing this in, Ulysses), so any notes get sequestered in Apple Notes, which is a consumer app that fails quickly for me when asked to do complex information management. I need complex folders, with PDFs sitting next to notes and text files. I mean, duh, I want to organize by content subject, not content type. Plus my handwriting is illegible. So I agree the pencil setup is better, but that’s more a statement of how bad it was than how clever or great it is now. I know this matters a lot to some, just not that much to me.

The larger screen really is better. I don’t do “multitasking”, but I often have two apps on screen. E.g., when I process email, I almost always need to look at my calendar. With the bigger screen I can have my calendar in a small window, showing daily view, and it works great. I can only do this on my small device if I squint a lot. Being in my 40s is awesome. (It’s not all work; I also often have Destiny Item Manager and Discord open at the same time.) Again, note, this is about allowing me to get all the apps for one task on a screen. The computer is multitasking, I am not.

The new keyboard folio is pretentiously named, and such a bad wrapper for such a beautiful device that I’m embarrassed to touch or see it. I think technically the first case for the first iPad might have been worse, but wow that’s a low bar. So I have three color choices for my $1500 device, but I have to wrap them all in a slate-colored piece of vinyl? Shameful.

I guess the new setup is better. I definitely love having two angles, and it’s certainly less confusing for others to use the device. It’s a bit more disorienting for this expert user, though. I never got lost on my old iPad, but this one is sufficiently featureless that I’m always struggling to hold it in just the right way when opening it. Where’s the hinge? What corner does the camera go in? I frequently felt like I was studying a foreign object rather than using a well-known device. It needs to be far more obvious how to grab it, how to open it. The asymmetry of the old one was ugly, but you would never be confused about where the hinge is, or the bottom, or anything else. And the keyboard being exposed on the back is just a mess. It gets filthy, that filth passes to the screen, etc. Yuck.

That being said, the actual keyboard bit is better. I am typing this on the old one, on my lap, so clearly that was never a problem for me, as it apparently was for others. But the new one is more rigid, and the actual typing seems better. I mean, not good compared to my mechanical keyboards, but better.

So for this one, I’m calling a pencil: Wow the last one was really really bad. This one’s a bit better, so it’s only really bad. Unlike the pencil it’s a real downgrade in orienting yourself on the device when you first pick it up. The materials and handling issues guarantee no better than a middling grade.

I like smaller bezels and the new form factor, but honestly none of that matters to me except for how it makes the device smaller. Yes, Apple has a knack for industrial design that immediately makes everything that came before seem antiquated, but I’ll suffer through somehow. My car is six years old. I’ll be ok. I’ll just start calling my old devices dadcore.

Conclusion

It often seems that Apple’s industrial designers are their favorite kid, and the software designers are only there because someone has to fill the machines with stuff. Jony Ive gets to lovingly expound from his featureless white room on the physical bits, but, ah, not so much on what it’s like to use it for anything other than a dinner plate. That’s someone else’s job, someone else’s love.

I don’t think this is “new Apple”. Holy cow I hated early releases of OS X. Yes, it’s far more important than my interfaces be lickable than usable. Of course.

Apple’s operating systems usually do have a much user experience than others. But, ah, you’re comparing yourself to XWindows, which still can’t automatically detect an external monitor², and Windows, which is a clean-room copy of MacOS done by aliens. The competition isn’t exactly fierce.

After college, I switched from MacOS to BeOS. I loved that OS. There was so much forward thinking in it, and there was a real conversation about what usability really meant, with a close connection between the people building it, developing for it, and using it. When it went away, I had no real choice but to switch to Linux. Literally every year I cycled through all of the distros in hopes of finding one that didn’t require me to hand-maintain my X.org config to support two monitors, but always ended up back on Debian, because at least its packaging was sane.

I finally switched to Mac when I realized: Once a year, I spend a week being livid, utterly pissed, bright red and burning hot, at Apple, all their products, and how they seem to just not like or trust their customers.³ But I spent an hour every day feeling like that about Linux. I eventually concluded I’d rather compartmentalize all of that into one chunk than spread it evenly throughout my life.

So yeah, I love my Apple devices, but, like, only compared to everything else. I hate software, but I’m pragmatic.

With that as a preface, here is the most accurate, but also most damning, review I can give for these new iPads:

They are a stunning implementation of the wrong thing.

The easiest way to see this is looking at the Apple logo on the back of the iPad. If you use the new keyboard, it’s covered in shame, but on my existing devices, it’s either hidden or sideways. If I am not using the keyboard, it’s wrapped around hiding the logo, but if I am using it, then I’m in landscape, and the logo is on its side.

The crazy thing is that Apple already learned this lesson! They used to ship their laptops with the Apple logo upside down. Or rather, it was right side up when just sitting there, but not when you actually used it.

Look, I don’t care about the logo. It wasn’t my blind spot that led to this.

What I care about is what it means that Jony Ive, Tim Cook, and all of the other leadership aren’t seeing these sideways logos every day, and tearing their hair out.

I’m trying to imagine an exec meeting there, with fifteen Apple logos sideways around the room, and everyone just shrugging. I can’t. Someone has to notice, be pissed off, right?

I can only conclude they don’t use these devices the way I do, and that causes me some despair. They still have a long road to walk. They’ll get there. But not soon.

The first thing I do every morning is turn off rotation lock, and enabling it is the last thing I do every night. I only need it enable when reading it bed, and the rest of the time I want to easily switch back and forth. This little bit of software friction cuts my usage of the keyboard by like 50%. One of the best things about using the big iPad is it’s too big to read in portrait, so this problem goes away.

A teeny software change could just ignore rotation lock when the keyboard is attached.

That software change would have happened ages ago if the people building these products used them anything like how I do.

Since they obviously don’t, I am not optimistic they’re going to make the right fixes.

Yes, there are a bunch of features they should add. But it’s more important they make a psychological shift in what this thing is for.

This device does give me some bit of hope. Even they can’t ignore the debacle that is Face ID with these things in landscape. That will push them to reorient.

Until then, you’ll just have to hide your sideways logo. But I’ll know it’s there.

Page up/down aren’t scrolling; most apps handle them poorly. ↩
I’ve no idea if this is true. But it was true last time I checked, and that time was in the 21st century, so it’s still embarrassing. ↩
This was more so at the time, around 2007, then now. ↩

We Were Promised Flying Cars and Five Hour Work Weeks

luke@lukekanies.com (Luke Kanies) — Fri, 26 Oct 2018 00:00:00 +0000

Work is not a zero-sum game

Image courtesy of Clem Onojeghuo

Remember those stories from a few decades ago, about how improvements in productivity and automation would mean that we’d only be working 5 hours a week by now? They seem as fanciful, and predictive, as The Jetsons.

It’s almost a punch-line now, because many actually work more hours today than back then. How could they have been so stupid?

Of course there is actually a lot baked into the fact that higher productivity has not reduced hours worked (nor, it turns out, has it raised wages for the bottom 50% of earners in the last three decades, quite contrary to the previous, oh, 200 years). But a big part of why that prediction seems so silly now is it included an implicit assumption: That the work we’d be doing today is pretty much the same as what we did then. You know, before computers.

And I don’t mean, they could not foresee how much time we’d waste on social media. Their primary mistake was not thinking about how we’d use the space created by greater productivity.

We’ve known for centuries that increased efficiency results in increased consumption - we keep improving fuel efficiency, yet we’re consuming more gas than ever. Why?

We also know that expanding a freeway has never reduced traffic congestion. It has the same cause.

Induced demand. People who would not have driven with only two lanes, because of all the traffic, will now drive if there are four lanes. Trips you would not have taken because of the gas cost now become affordable and reasonable.

If your goal was to get more people driving, and maybe get the resulting increase in economic activity, then I suppose you got what you wanted. But if you were trying to reduce traffic - which is why most people say they want more freeways - then you’ve failed. If anything, you made it worse, because now twice the number of people are stuck in traffic. You didn’t reduce the problem, you just spread it around.

Demand is induced in many other areas. I grew up remodeling houses with my dad and got to see the impact of pneumatic nail guns and paint sprayers, which automated a huge chunk of how we’d spent our days. Of course, we didn’t use that newly free time to sit around, we changed our behavior: We did higher quality work, we finished jobs faster so got more done in a year, and we lowered prices.

I ran into this perception conflict all the time as I was building Puppet. I’d say I was building automation for the data center, and salespeople and execs would say, “Oh, so you can fire sysadmins!” I don’t know what they had against operations teams, but no, I would respond: I can give you a choice between reduced cost at the same service level (i.e., you fire people), or keep costs the same but increase service quality.

“Wait, that’s an option?!” Without higher level tools like Puppet, people had no idea how to increase service quality. Cost was their only dial, so they focused on that, even if it made no sense. Once I gave them other choices, of course they wanted better quality.

So where success in 1999 was shipping twice a year, and not going down, like, that often, now success is shipping multiple times a day and never appearing down to your customers. The standards have changed entirely, and that change was made possible mostly through automation. You can bet Netflix doesn’t become the new standard for infrastructure hotness using the bad old manual practices of the 90s.

You might say, no, people’s standards changed and that’s what motivated them to invest in automation, but you would be wrong. They always wanted higher quality. They always wanted better service. They just felt they had no choice but to accept the status quo, until we showed them other options.

I’m not saying automation never destroys jobs, never reduces the amount of work to be done in an area. But it’s by no means the default result.

The first impact of automation is to increase quality. I felt this myself, building houses. The main reason I’m no longer a carpenter is because of how incompetent I was at setting trim nails. You drive the nail most of the way into the wood¹, then use a small punch to recess it. You cover that one little hole in spackle, and no one can tell. Unless you’re me. When I do it, I make a little sunflower, with a hole in the middle and holes all around in a circle, because I’m just that good at letting the punch head slide off the nail, into the wood. If we’d had the trim nailers that exist now, even I could have done a decent job. That kind of success might not have driven me out of the industry and into the welcoming arms of computers. I’m not a lot better typist, but the delete key does wonders for my self-confidence.

And let’s be honest about what we’re automating: It’s literally the most boring and least useful work we do. I wasn’t exactly high skilled labor, but I assure you there were more valuable things for me to do than try to set a nail while on my knees, bent over to the base molding. As a SysAdmin, yeah, my bosses thought my job was typing the same command 1000 times a day, but we can look back now and see that definition actually got in the way of the work, rather than being it. We had much more important stuff to do. Or at least, I did. Not sure about the bosses.

If we were all willing to drive cars from the 70s, while living in houses from the 70s (oh god the colors), using computers from the 70s (all three of them), watching channels from the 70s (all three of them), then yeah, maybe we could also work 5 hours a week.

But we all know what we’d do with the spare time: We’d make more work.

You’d do something silly, like write a book. And obviously, most of those books would be junk, but enough would be good that it would become someone’s job. And maybe the other writers didn’t actually have a knack for writing, but found they could be great at helping other writers. Oops, now you’re an editor, or a publisher. And now you’re working more than five hours a week again!

Stupid entrepreneurship.

Or maybe you don’t want to be a writer, you just hate Avocado Green enough to do something different with your kitchen. Oops, now your friends want the same thing, and you’re an interior designer.

Or maybe you realize that the gas-guzzling death-traps we all drive in are insane, and you figure out some way to start bringing those sweet little rides over from Japan. You know, just to fill the time. Because you can only consume so much of your day watching three channels (and remember, no ESPN in this scenario).

You’re not the only one that’s bored. Everyone else has more time, and a need to fill it. They can spend the effort to become experts in watches, furniture, bicycles, hiking, boating, economics, philosophy, or any number of other areas. And we all know the main outcomes of expertise, beyond insufferable newsletters: Demand for more specialized stuff, or enough disgust at the lack of it that you’ll just do it your darn self.

Some number of us won’t do the work, but we still want more, because why else would I have read three books on horology? It only takes a few people to step in to fill that demand, and suddenly your time is taken up.

And of course, if you want to buy that fancy Patek Philippe to pass on to your kid, you probably need to work a few more hours than the minimum.

So now you know why we don’t work five hours a week, and hopefully you have a little more confidence that automation will generally be good, not bad. It’ll create more entrepreneurs, raise wages, increase quality, and reduce cost. Not every time, but most times.

It doesn’t explain why those prognosticators in the 70s were so silly, but, well, I bet it wasn’t the worst decision they made that decade.

16oz Estwing finish head with a curved claw, natch. ↩

Great advisors reveal your truth, not theirs

luke@lukekanies.com (Luke Kanies) — Tue, 16 Oct 2018 00:00:00 +0000

Giving answers is easy, and usually worthless

Photo by Blake Cheek

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

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

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

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

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

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

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

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

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

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

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

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

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

A great advisor should provide light, not direction.

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

Hold on to your why

luke@lukekanies.com (Luke Kanies) — Wed, 26 Sep 2018 00:00:00 +0000

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

Photo by Sharon McCutcheon

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

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

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

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

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

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

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

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

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

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

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

Bullshit.

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

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

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

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

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

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

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

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

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

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

Owning My Strava Ride

luke@lukekanies.com (Luke Kanies) — Tue, 11 Sep 2018 00:00:00 +0000

I know what it means to own my code contributions Github, but what does it mean to own my rides on Strava?

Photo by William Hook

I recently went mountain biking in Bend, Oregon, which is a few hours’ drive from my house. As I usually do, I used Strava to record the ride. This was a new trail for me, and I got lost multiple times, so I also used Trailforks to figure out how to get back to my vehicle.

I’ve been thinking a lot about how services like Facebook start out helping us, but at some point the relationship shifts and we’re stuck helping them more. I don’t think Strava has gotten to a stage where the relationship is abusive, and maybe this is weird but I hope they stay too small to ever get there. Even without that shift, though, I am a little uncomfortable with our relationship.

I was standing on the trail, trying to find the right trail and idly watching a coyote search for chipmunks. As I switched between apps, I realized that I was losing a lot by recording in Strava instead of Trailforks. Or rather, I wasn’t; people who want to bike this trail in Bend were.

I log my rides (and my infrequent, hilariously slow runs) in Strava for, um, reasons. I don’t want kudos, and I don’t really look at my historical performance, although I do enjoy being able to study my rides at times. I want the data there, even if I rarely use it. And it conveniently automatically completes my daily exercise goal in Streaks. It’s kind of useful, but if it went away tomorrow, I wouldn’t miss the online component much, if at all.

If I instead recorded all of the trail rides in Trailforks, then everyone who came after me could get some value from the information provided by my ride. They could see what route I took, could likely tell based on my speed when I had to walk and when I was able to ride, and they could over time get a sense of what routes are most popular, or even what signage is confusing.

I built an open source company, so I’ve thought a lot about the worth of contributions. A developer’s time on one project can’t be spent on another. Someone who writes documentation for your baby is giving up the opportunity to contribute elsewhere. It’s a conscious choice on the part of the contributor, and a constant interaction between the project and its constituents to keep people coming back.

I think Trailforks really understands the value of my contributions: If you do this, people who ride here will have higher quality data, and probably better rides.

I am super confident that Strava knows the value of my usage: I’ll get feedback from friends and I can track my speeds and feeds. But those aren’t contributions; that’s not something I’m giving up for the greater good. It’s something I am doing for selfish reasons.

The value of my trail ride could be for the greater good, though. Even my road rides and runs could be, as they could help people find routes, but the trail rides especially seem valuable, because the downsides of being lost out there are materially worse than not having the right route for your run.

It’s clear to me that Strava is not seeing my data as a contribution. They’re focused on engagement. That’s not inherently bad - lots of people use and love the app - but it is different. I find it interesting to think of what the experience would look like if that changed.

But after that, I thought: Why can’t I just share the data with both apps?

I mean, to some extent I can. I can just run both of them and let each record its own view of the world. This is what I did with Slopes and Strava in Mammoth, taking the lifts up and riding down. That made a little more sense because neither quite has the correct view of the world - Slopes doesn’t know what bikes are, and Strava doesn’t know what lifts are. It was pretty kludgy, but more importantly, I didn’t run into this conflict because the apps exist to do pretty much the same thing, just for different sports.

I could duplicate here, I assume, but… it seems stupid.

Beyond our relationships to service providers, I’ve been thinking about what it means to own your own data. It sounds awesome, but it’s rarely very useful in practice.

It turns out, I do own the data that I have posted on Strava. Great! So I’ll just share it with Trailforks, too.

Hmm. What would that look like? Can I… download the data, and then upload it to Trailforks? Is it a common data type?

Can I record it separately on my phone and post it to both apps? Is that what truly owning my data would look like?

It’s hard to imagine that world: You use apps that generate data, which by default is yours and only yours. It gets recorded in forms that are easy to share, understand, and manage. If you like, you can then contribute that data to other sites, and in doing so, you get to negotiate with them exactly what rights you’re passing on. Either way you have the data, but now they get a copy, too. If you don’t like their offer, you still get the data, and most likely, given you have all your delicious data, other apps will crop up with a different offer, because they can focus on that rather than all the data collection.

It would look a lot like the text editor I’m using to write this article, Ulysses. It allows me to publish, but is built first and foremost to make it easy to write. Sharing, contributing, engagement, and all of the other online stuff is left to other sites, other apps, like Wordpress and Medium. And yeah, those apps do allow both writing and publishing, but it’s a horrible experience, a great way to lose data, and if you only write there then your data is stuck in their system and is pretty hard to get out in a useful way.

The world of writing looks weirdly different from the world of recording rides. And a lot worse.

I’m not in control. Legally I own the data, but, ah, I don’t have it. Strava does.

I would never write directly in Medium, so why am I logging my rides directly in Strava? What am I giving up because of it?

I’m pleased to find that Strava will allow me to give other people the data - the data that I own! - and it turns out that Trailforks knows how to slurp it out of Strava.

So it all ends well: My rides are in both locations, and every mountain bike ride I post to Strava will now be automatically imported intro Trailforks. Probably.

But for that brief moment, in Bend, while watching the coyote… I saw what it would take for me to really own my data. I liked it a lot.

How to Neg a Founder

luke@lukekanies.com (Luke Kanies) — Fri, 07 Sep 2018 00:00:00 +0000

Is that a compliment, or an insult?

Photo by John Salvino

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

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

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

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

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

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

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

An alternative crypto-history

luke@lukekanies.com (Luke Kanies) — Thu, 28 Jun 2018 00:00:00 +0000

Filesystems, version control, and the blockchain

Image courtesy of Adarsh Kummur

This is the fourth, and possibly final, article in my series on the blockchain without blockchain.

I’ve always had a warm place in my heart for filesystems.

I taught myself shell scripting while automating the installation of Disksuite, Sun’s free but sadistic disk mirroring software. I barely recall the actual work, instead remembering a hallway. I undertook a literal journey to learn programming, a repeated pilgrimage to the desk of a friend who took visible pleasure in explaining to me what I was doing wrong.¹ It’s fair to say that if filesystems were less painful in the 90s, I would not be where I am today.

When Sun started advertising ZFS as the (finally!) successor to Disksuite and the filesystem it was built around, UFS, most of its functionality seemed obviously good - make the computers manage the disks, don’t demand people know up front how big a filesystem should be, don’t fail miserably when the server crashes, little things like that. But what was this data integrity thing? I’m embarrassed to say it took me a while to realize I needed it - who really cares if your filesystem is good at storing data, amirite? - and even longer to understand how it worked.

To explain it, I’m going to have to teach you cryptography. Just a little. You’re welcome to skip ahead if you’ve already got this part covered, but I expect most could use a little, ah, refresher. Step 1 in cryptography guides is usually: “Get a masters in mathematics from MIT.” I’m hoping to do a bit better than that. Cryptography really is just a form of math, and while we can’t all understand the details (I certainly don’t) we can at least understand the “algorithms happen here” flow diagrams².

Cryptography is most famous for its privacy utility: You use it to ensure you and only you can read your files and chat messages. It gets more complex once we need to read them on all of our different devices, but most of it is pretty similar in concept. Even more useful is ensuring both you and I can read some text, but no one else can. It’s more complex, but is essentially an extension of that first use.

Privacy is not the only use case for cryptography. It’s also useful for efficient validation. That is, it can be used to see if a file you have today is the same one you had yesterday. I sent you a document, you think it looks wrong; how do we make sure it did not get changed somehow in transit?

Obviously one way to do that is to just send it again. This is not a great solution, because if you did not trust it the first time, why would you trust it the second? That might also be a bad idea if bandwidth is expensive. You generally want a verification mechanism that takes less space than the original file, and less CPU power than directly comparing the two files.

Cryptography provides just such a capability, usually called a ‘hash function’. It’s an algorithm that converts, say, a large text file into a much shorter string. If you want to ensure the file is not changed in some way, just run it again and compare the output. The short strings are easier to compare than the long documents, and you could even read them over the phone to someone so they can check the file on their end. These algorithms generally produce a string of a fixed length, regardless of input - this makes them efficient for long term storage and comparison, and safe to run on any size file. Here’s an example hash from my files:

03f39f4bfad04f6f2cfe09ced161ab740094905c

As you can see, it’s just a long string of gibberish. It’s not only useful for comparison, not meaningful in it’s own right.

What’s critical about these algorithms is that given a unique input they always provide a unique output. If you and I each have a file that hashes to a given string, then we can be confident we have exactly the same file. Of course, this can’t literally be true: We could design a hash function that only had 256 possible outputs, and there are obviously more than 256 possible inputs. This would produce a lot of what are called collisions, when two files hash to the same output, and, ah, is not terribly useful.

All of the modern hash functions are incredibly long. It is possible in theory but not in practice that a collision would happen. You’d need to execute the function 2^128 times. That’s 3.4 with 38 zeros after it. So, mathematically possible, but you can expect the sun to swallow the earth before the most secure hash functions get compromised. I mean, you can’t. You’ll be gone by then. But your files will still be safe.

Now that you’re at least as much an expert on cryptography as most of the bitcoin hodlers, why does any of this matter?

We were talking about data integrity.

You’d be right to guess that ZFS uses these hash functions to provide it. It goes further than just validating individual files. A little bit of cryptographic genius called a Merkle tree is the key. These don’t just hash the content on disk for later validation; they build a tree of hashes, where the leaf nodes are hashed by the nodes above them in the tree, which are themselves hashed by the root node. If any part of this system is corrupted - because the disk is broken, or someone changed the content some other way - it’s easy to detect. It’s not just that the individual hash will be different; remember each parent hashes all of its children, so now the parent is wrong. And its parent is wrong, too.

If the content is changed by any mechanism that does not also also update the Merkle tree, then it is easy to detect by rehashing all of the content and comparing the results to the stored tree.

This is how ZFS validates data integrity. It can write a block to disk, then pull the block and ensure it still matches the hash. When it writes a block, it updates the parallel tree, and when you ask for the block later, it can tell you if the block is still correct. If it’s not, it throws an error instead of handing it back to you.

When I first learned of this, it seemed overkill, but over time I remembered just how many ways there are for data to get corrupted. The most obvious one is someone changes it for nefarious reasons, but far more commonly you have a failure somewhere in the writing or reading process. The old spinning disks were error-prone, and the new SSD drives degrade eventually. It’s the complexity of reading and writing that really gets you, though: There are multiple layers of caches, drivers, and connections, any of which could introduce corruption.

For the first time on a normal production system, you could at least detect any of those problems. It’s too bad no one ever used it.³

I know, I know, you came to hear about how you could get all the awesomeness of blockchain without using the blockchain and instead I’m giving lessons on two things you could literally not care less about, cryptography and filesystems. Don’t worry. It gets worse from here.

Long after I learned about and promptly forgot ZFS (after all, it’s not like I was using it), I adopted Git. It’s a version control system, used for storing and managing source code. Every geek knows about it, but most of the world only recently learned of it when Microsoft bought Github for $7.5B with a ‘b’. I was an early adopter, switching Puppet to Git in 2008⁴. Eventually I even learned how it works. I was titillated and a bit horrified that I had duplicated in Puppet one of the key features that made Git work: A system of storing files that allowed them to be looked up by their content (or rather, a hash of their content). Normally you store files by a name, but if lots of people (or, in Puppet’s case, computers) store the same file, they might not call it the same thing, so Git and Puppet instead stored them by their hash. This ensured we never backed up more than one copy of a file, saving a lot of space, and made it easy to check for changes in files.

For Puppet, we just used this to back up files we changed, in case people later wanted to revert.

Git did a lot more than that.

Like ZFS, it builds a Merkle tree of the entire file repository, with a similar goal: To understand what files have changed and how. After all, git is used to track and share changes to a collection of files. The sharing is a critical component; you can easily copy an entire git repository to another computer, or another person, and it’s important that they be able to confirm that they have a faithful copy.

Git stores the hash tree alongside all of the files. At any point, you can use the tree to validate every file in your tree. If there are changes (which is pretty much the whole point of a version control system), it can automatically store the new files and update the related tree.

Just like ZFS, one of the key features here is that the Merkle tree allows us to validate every file stored. We can walk the file tree and compare each file to its hash, and then compare the file listing to its own hash, all the way up. Any discrepancy is easily spotted.

This is my favorite kind of cleverness: It’s simple in implementation, yet makes Git more flexible and useful. It has power that other version control systems are missing, just because it relies on this basic mechanism for storage and validation.

Ok. Now we get to the point.

Again, I’m not actually interested in the blockchain. I’m interested in peeling it apart, putting the useful bits to work while avoiding the whole anarcho-capitalist aspect.

It would be easy to see the blockchain as a sudden revolution, a dramatic change in what’s possible. Viewed this way, it’s hard to separate the pieces from the whole. If all you see is the big picture, it’s easy not to notice that every individual component has its own history, its own value.

The blockchain was gradual, for both me and the industry. It was not one giant leap forward. It was part of a story, a sequence, and the most interesting aspect - Merkle trees - is decades old in math and now pushing decades old even in popular usage. Most of the interesting features touted in the blockchain come directly from them. Immutability (which isn’t) and trustless systems derive directly.

It’s worth understanding that history, to see which stages and steps apply to problems you have. The current cryptocurrency tech stack is built to solve problems I don’t think exist. Certainly they aren’t problems I have.

Unlike the blockchain as a whole, though, the individual technical components have been used for years, even decades, in production. Focusing on the current trend can blind you to the opportunity history demonstrates. I think you’re a lot more likely to find broadly applicable solutions there than in trying to replace currency.

Because I got here from the world of filesystems and version control, I see different benefits than you might if you approach thinking of currencies or exchanges. Or chat messages. That does not make me right or wrong, but it does, at least, mean we’re going to work on different problems.

I expect most of you think this is boring. That’s great. It will give me that much more time to build something.

My brightest memory is learning that of course the ’echo’ command resets the exit code variable. This was a critical early lesson in how your own debugging can dramatically change the behavior of a program. ↩
When people talk about the futility of trying to ban cryptography, this is what they mean: You can’t ban math. ↩
Yes, I know some people use and love ZFS. But never to the extent it should be. ↩
Resulting in one of our critical community members abandoning Puppet in protest, for some reason. ↩

The virtue of a tool

luke@lukekanies.com (Luke Kanies) — Tue, 19 Jun 2018 00:00:00 +0000

Vendor success should be about customer needs, not its own.

Photo by Philip Swinburn

I am a tool junkie. I love the effortless balance of a well-known chef’s knife, like my hands know what to do all on their own. Heavy usage builds callouses and tunes muscles, its usefulness evidenced by scuff marks and changed infrastructure. Failure leaves blisters or even hospital visits in its wake.

A good tool proves its utility. Knives slowly shrink with sharpening, work pants thin, machines need oil. If they don’t, you’re either not maintaining your tools, or barely using them.

This wear is proof of your usage. They should be scratched. Dented. Aged. Patinas should be acquired from the shop, not factory treatments. Their callouses should pair yours. Tools can not be precious. They’ll just live on a shelf, then retire to your attic. You should seek that perfect middle ground, where you spend enough money that your kids can inherit them, but not so much that you are squeamish about giving them a job.

Tools only deserve the label if they help you work.

You might say I have strong feelings about them. I’m assuming this love led to my focus as a software entrepreneur on helping people people work. Or maybe my experience with tools in the physical world led me to seek them in the digital world, learning to make what I could not buy.

Given my tool fetish, you’d think I’d have a solid grasp of what I mean when I use the word. Apparently, not so much. I was recently pulled up short by a simple question, asked by Jordan Hayles of the Radical Brand Lab: What do you mean by tools?

What do you mean, what do I mean? It’s a simple question, right? The above text gives one example, but I would have thought I could answer it in a bunch of reasonable ways, none of which seem terribly controversial.

But the more I explored, the less simple the question became.

I’ve been describing my goal as building power tools for people. This phrase comes from my time building houses with my dad, and ‘power tools’ just meant the things you plugged in. You know? Because they needed power? It’s a common usage, maybe the word choice here did not mean much.

Except… I’ve spent more than a decade learning product management, describing myself as a product-oriented founder, managing that function in a growing company, and attempting to teach it to others. Yet here I am ignoring both the term and the field entirely. Why am I so quickly dumping my work of the last ten years? Is it just creative branding? Cynicism about my industry?

Why not power products? That’s a motor boat of alliteration: ‘power products for people.’ Awesome, right?

Ok, maybe not.

Product management as we know it began in the consumer goods industry. You’re handed a train car full of dish soap and told to sell it. You’ve got to package it, set pricing, convince a local store to carry it, argue with them about location, move it away from competitors, all that. Every product you see in your local grocery store is loved by a product manager who fights for its shelf space, believes it is beautiful, and wants you to give it a good home.

Tide soap is one of the most commonly stolen consumer goods, but not because it’s soap. The strong brand makes it easy to resell, even allowing it to be used as a stand-in for money in drug deals. I wish I was that good at product management. For all that, it says nothing about the soap.

Product management can also be used for evil. Laser printers had toner cartridges you could just refill. Not very clean, but cheap and reliable to run once you plonked down the cash for the expensive printer. Modern inkjet printers instead use disposable cartridges. To sustain profit margins in a rapidly commoditizing industry, manufacturers started putting rules in place on the cartridges: You had to buy them from the manufacturer, they had to be replaced every year, you could not refill them, you could not print in black and white if any color cartridges are empty.

The user was getting hurt so the vendor could make more money. People got pissed of enough that the US Supreme Court weighed in.

That’s good product management. Well, it’s evil, but you know what I mean. It’s effective. We’re talking big-B revenue effective. Hmm. A moral distinction begins to reveal itself.

These are examples of companies forcing their business model onto their customers. There’s no difference between the dish soap sold at retail and the one sold in bulk, yet they’re separate products, differentiated through packaging, shipping needs, and labeling. You pay much more for the retail package than the wholesale one, primarily because the business model behind them is so different.

But when I think of a tool, these complications are missing. When I use a hammer, it just has to fit my hand and smash stuff. When I pick up my drill, it works with every bit I own, regardless of the logo. The battery and charger are proprietary, but the vendor’s most visible role in my life is color choice. My yellow drill works just fine with bits from the blue or green companies. (You probably visualized brands by my just mentioning colors. That’s still effective here.) It does not matter whether I bought the drill from Home Depot or inherited it from my dad; once in my hands, it just works.

I think this begins to answer the question of what a tool is.

It helps you do your job, without your worrying about the vendor’s needs.

I know that DeWalt and Mikita need to make money to sell me a drill, but I don’t think about it when I’m using their tools. Even after more than two decades without one, I can comfortably recite that “my” hammer is the Estwing 22oz waffle head with a straight claw¹, but none of those details mean I need the vendor’s permission to hit a nail with it. I make a decision about the right tool, I buy it, I use it. End of story.

It is small. If you call something a tool, not a product, you’re saying it’s less, it’s not as complete a solution. This can be belittling, insulting, but it does not have to be. It’s also a statement of independence. Of freedom. Of, and this is going to sound crazy, compatibility.

Products have an implicit, ongoing dependence on their vendor. If that’s me, I love it: I want you to pay me all the time, not just once. That ongoing relationship is how I afford to keep improving what I’ve built for you. This can be a great way to ensure we have a long-term, sustainable partnership. But it’s not always a healthy relationship. The more you have to deal with how I make money, the worse the experience is for you.

I think this is what I like about tools. They’re self-contained. Independent. Using them is fundamentally pragmatic, not a lifetime commitment.

That independence has downsides for me as a vendor. You don’t get any of those delicious growth-hacker buzzwords. Your product isn’t “sticky”, there’s no “moat.” Those are examples of my customers being constrained by my business model, and their absence means revenue is harder to build, to protect.

One might argue I’m better off because treating my customers with more respect makes a better business in the long term, and I’d probably agree. This kind of respectful partnership should deliver higher returns than one that traps and mistreats its customers. I think this is often the right answer, but it’s not a popular one. It’s harder to get funding, to get off the ground. I might be accused of not “wanting to build a real company,” or I might have Silicon Valley’s most dire insult hurled at me: “That’s just a lifestyle business”.

Tell that to Adobe. Or AutoDesk. These are great tools companies. They are the behemoths we know today because they knuckled down and solved their customers’ problems. They worried about that, rather than how they could extract maximum revenue over time. It was a different time, but people have not changed.

I don’t think that every product is compromised when the vendor’s needs show up in the customer’s life, but I think most are. Some of it is laziness, shoring up product limitations with business model innovations, but a lot of it is strategy, recognizing the value of painting your customer into a corner.

Honestly, some of it is just survival. A lot of those inkjet printers are unaffordably cheap, but buyers care only about cost, not value. Some markets are intrinsically dysfunctional, with users and vendors slowly killing each through bad deals and cynical behavior. But as a vendor, I get to make a choice about what markets to play in, and how to work with my customers.

I am a simple person with a simple dream: I want to build something that helps someone work. I have to make money while doing it, because that’s the nature of the job, but I’m more interested in my customers’ work than my own. I know I need a business model, a go-to-market strategy, a plan for growing and supporting my business. But my customers should not need to care about that, should they? If they like what I’m building, they should be able to buy it, and use it. And tell all their friends how great it is. They should not wake up one day to find they’ve accidentally gotten married to me.

I just want to build tools. And I’m proud of it.

We told with great pleasure the (most likely apocryphal) story that this hammer was illegal in Florida because the metal haft could cut your thumb off. ↩

Several short sentences

luke@lukekanies.com (Luke Kanies) — Thu, 07 Jun 2018 00:00:00 +0000

I have plenty to share. I can even write it. I just can’t publish it.

Picture courtesy of Cliff Johnson

Last year I decided to write more. Daily, in fact. One of my first actions was to ask Om Malik for advice. I had been following him since he was writing for Business 2.0, which was an actually valuable business magazine in the tech bubble. I am now lucky enough to know him through True Ventures.

When we talked, he shared a story about his first published piece. I did not find it helpful.

The magazine he was writing for (Fortune, I think) said his article was too long. He shortened it. A lot. It was still rejected. He compressed it more. Again. And again. I believe the original 1500 word piece became 300. Om’s punch line was that they told him it was their best-ever first contribution by an author.

I don’t think I’m cut out for writing 300 word articles. It’s not just that that kind of compressed writing is hard. It’s also about the missed opportunity: If you’re reading one of my articles, I want to take full advantage.

But my lack of desire to write short pieces is not why his story wasn’t helpful.

It’s one thing to say: “Write shorter”. Ok. I can see how that makes sense. Everyone knows the line, “I’m sorry this is so long, I didn’t have time to make it shorter.” It’s intuitive, implying that investing in the quality of writing somehow intrinsically shortens it.

But more than a year after this story from Om, I had still not found a way to put this principle into practice.

I could compress writing a bit. Programming taught me that shorter code is often simpler and clearer. Of course, it still took years to be good at it.

Stephen King had taught me that adverbs often indicate a problem. If you can get rid of them without losing meaning, your work is almost always better. One way to do this is to choose more expansive verbs.

I was able to translate my speaking coach’s advice into writing, too: She helped rid my talks of filler words. You might not think this is useful in writing - I never find myself typing out ‘um’¹ - but I am over-fond of long phrases that can be easily replaced with a single word.

I tend to over-qualify. This is an opinion piece. You know that. I can skip all the incidences of “I think”. One “maybe” is enough, I don’t need “should maybe”. Two examples suffice; I don’t need three and an “etc”.

For example, in this piece, I replaced the phrase “was still not able to learn” with “had not learned”. “I had learned as a programmer” became “programming taught me”. Both of them are clearer, simpler, just… better. In particular, the verbs are much stronger.

Again, it’s not that I had learned nothing over the last year. I just… I knew I was using tactics. Simple rules. My writing was shorter, but… not short. The Hemingway app was still harshly judging all my failures.

Then I got lucky. I ran into Lucy Bellwood - a fellow Reedie! - at an Indie.vc event, and we traded book recommendations while her partner patiently slept on his feet. She recommended a new book to me: Several Short Sentences About Writing, by Verlyn Klinkenborg.

It’s amazing.

Of course, I doubt I’ll ever finish it.

It reads more like poetry than prose. I do not like poetry. Nearly every paragraph is a single sentence. Almost none grow to more than one line.

Many books on writing can be summarized as: Sit down and write. Seriously. Now. Keep doing that.

Not this one.

I can’t summarize it for you. It’s, it’s… dense. But I can share a little I have learned. And how it has cursed me.

I received a new term from it: Transitions. I knew what adverbs were long before Stephen King taught me that they’re suspect. Not to be entirely avoided, but hold your nose when you use them.

I already knew my sentences were too long. Even when I broke them up, I knew I relied too heavily on words that connect them (like the phrase at the beginning of this one). This knowledge wasn’t useful, because I wasn’t able to translate it into methods of fixing them.

The first thing Klinkenborg gave me was a name for these words: Transitions.

Like adverbs, they’re usually a sign that you’ve failed somewhere. That you were lazy.

This labeling did not magically fix my writing, but it gave me something to track. An easy measure for how I was doing.

Then he delivered the kicker: Simple guidance on how to eliminate them. Or at least, reduce them.

Knowing sentences should be shorter is not useful if you don’t know how to get there. What makes a great short sentence, vs a crappy long one?

His answer is incredibly dense. I have to slow down when reading it: You should minimize the distance between the period of your previous sentence and the point of this one.

Those long, complex sentences I like to write aren’t bad because they’re long, or because they have too many phrases. They’re bad because their point is so far away from their start. The reader is left to wander through it, holding out hope for a conclusion.

What are you trying to say? Say that. Immediately. Did you leave something important out? Say that. Now. Keep it up until you’re done.

Your old, complex sentence is now a series of short sentences, in order of importance, each getting right to the point.

Of course, that’s not how the book describes it. My description would likely horrify its author. There’s far more to it than this. But it’s a start. And a huge departure from what I was doing.

It’s also why I can’t write any more.

The topics I’m working on now are incredibly important to me. They’re hard to reason about, to capture. And while I’m sitting here struggling with the content, the writing itself keeps getting in the way. The form. The structure of the sentences. The line breaks.

Where I put paragraphs.

It’s not that I’m embarrassed. It’s that the process of writing is distracting me from what I am trying to write.

So please. Forgive me a little writer’s block. I promise I’ll get better.

When I do, I hope you’ll also tolerate experimentation and failure in how to put all this to work. Expect wild oscillations in sentence length. Inconsistency between sentences and paragraphs. Confusion across pieces. I’m in that ‘conscious incompetence’ phase of short sentences, and it’s going to be a rough path for a little while.

I’ll come out a better writer, though. And hopefully you’ll gain something from witnessing the process.

I recently updated Om on my progress, sharing how much his story confused me and these tactical lessons I’d just received. Thankfully he appreciated the note, and was happy to see I took his story as a challenge, rather than a judgement. And he didn’t seem fazed in the slightest that it took more than a year to make anything of his help.

Except, obviously, in this case. Not never. Just not usually. ↩

Decentralize Your Data

luke@lukekanies.com (Luke Kanies) — Thu, 31 May 2018 00:00:00 +0000

What does owning your data even mean, and can the Blockchain help?

Photo courtesy of Dennis Kummer

Congress recently required Mark Zuckerberg to defend his lifelong practice of mistreating your private information. Movements to give you control of this critical data took the opportunity to claim they can prevent future such breaches. Blockchain is the new solution in search of a problem, and personal data is in the crosshairs.

But can the blockchain actually help secure your personal data? What would that take? And seriously, what do people mean when they say we should own our own data?

It sounds nice. Too bad it won’t help. The problem is not “ownership” (whatever that even means in a world of infinite digital copies). It’s centralization. Having one person’s data is a small threat, only to that individual. Having everyone’s data is a national crisis.

By now we’re familiar with the huge amounts that Facebook, Google, Amazon, and apparently everyone except Apple have on us. But how did they get it? Mostly, we gave it to them, through using their products. What we didn’t give to them, we gave to someone else who then passed it on.

There have been massive breaches at Equifax, Facebook¹, and many others. Even the general public is becoming aware of the real causes. Some of the the largest companies in the world exist purely to collect your information and sell access to you based on it. They might not sell your data, but they definitely sell your attention using it.

These are the problems you know about. Don’t worry; it gets worse from here. If you think your birthdate and pictures of your kids are personal, what about your DNA?

Anne Wojcicki is married to a Google founder, and she liked their data accumulation so much she started her own company to build a huge pile of even more personal data. 23andMe does not scrape the internet - or your cheeks - to get your DNA; no, people pay for the privilege of giving it to them. Yes, they offer a service in return, but do they clean house after? Hah! No. They keep it. (Hopefully somewhat more safely than Equifax does.)

What’s so wrong about there being a database of DNA from a big chunk of the population? Let’s ask the police.

You might not be afraid of the police. You should consider yourself lucky. I know anyone of color in the US is and should be. I know I am; I grew up on a commune, and policed raided us using helicopters and assault rifles in hopes of busting us for cannabis. I don’t mean to imply that hippies have been as systematically oppressed as African Americans (and certainly not in the south); just that I grew up with my own justified skepticism of exactly what that force was here for.

Even if you don’t fear the police, you should fear the consequences of DNA testing. The science behind most parts of DNA are absolutely rock solid². The police work is another matter. Beyond outright fraud used to wrongly convict people, the messy world of testing DNA at crime scenes just makes it hard to get correct results. Juries inappropriately treat a complicated test as foolproof. It could be compromised anywhere from the crime scene to police handling to the lab itself. The failure rate even without fraud is high enough that I would not want to trust my life to it.

Not to imply that DNA testing is worthless; quite the contrary. It has been used to exonerate many people who were incorrectly imprisoned and put on death row. It’s not that it always fails, just that you don’t want to finding yourself gambling on it against life in prison.

But remember: This is just for cases where someone has a single person’s DNA. Like having just your fingerprint. What happens when someone like 23andMe has a whole database of it?

“If you didn’t do anything wrong, then you have nothing to fear.” Pfft. Yes, it starts with requests for the DNA of individual suspects, but it escalates to doing a database-wide search for DNA that matches. And by ‘matches’, we don’t mean, “is 100% guaranteed”, we mean, “eh, it’s pretty close”. A DNA “match” directed the police to someone they thought was a relative of a suspect, who was then brought in for questioning. So I guess as long as you’ve never done anything wrong, and aren’t related to anyone ever doing anything wrong, you’re fine. Right?

I feel so much better.

I had investors literally laugh at the idea that collecting this data introduced security concerns. They grew up at Google, so it’s not surprising they could not see centralization as a problem. Just like Equifax started out wanting to make it easier to get loans, and now they’ve got so much power you can’t get one without them.

There is a world of difference between giving someone your data, and allowing someone to include your data in a massive pile of it. Any discussion of the risks of data needs to acknowledge that.

Now we see our discussions of owning your own data don’t quite have it right. What we actually want is decentralization of data. We don’t want a single company to have access to this much information about huge groups of people.

And now you see the problem.

New technology can’t break Facebook’s business model. It can’t prevent Google from scraping every web site on the internet and identifying you by connecting everything. Whether you give it to them or not, they’ll know what you look like, where you live, and who you hang out with.

Most importantly, it can’t prevent people from sharing all that data with these services. After all, they’re getting something valuable in return, like connecting with friends and family. Or figuring out their family tree.

The problem is not the centralization. It’s the effectiveness of a business model built on centralization.

So anyone who comes to you and says “The blockchain will allow you to own your own data!”, ask them in return, “How will you make it such a joy to use that Facebook will go bankrupt?” And please, record the conversation, because I want to see them stammer.

This is fundamentally a product and design problem, but the technofuturists are treating it like a technology problem. “Oh, if only those college students had access to better cryptographic tools they never would have shared that data with Facebook!” 🤯 No. People will stop using Facebook, and 23andMe, and Google, when there are better solutions. And unfortunately, they need to work ten times better, not just a little bit.

So talk to me about the blockchain. I really do want to hear how you’ll use it to help people own their own data, and remove the incentive to centralize all of this data.

But talk to me of products. Of user benefits. Of business models built around all of this.

Because people have to want what you’re selling, and the only way to get that is to build something they want to use. Only then will they be able to own their own data.

This is the third article in a series of indefinite length on The Blockchain Without Blockchain

Although technically not a breach, since their usage rules weren’t broken - that’s how little they respect your privacy. ↩
Although we’ve still got a lot to learn about the epigenome, so don’t think we’re done here. ↩

Trusting more with the blockchain

luke@lukekanies.com (Luke Kanies) — Tue, 22 May 2018 00:00:00 +0000

Society is built on trust, and improves or weakens with it.

Photo by Nathaniel Tetteh

I know I have trust issues. I don’t need the blockchain crowd telling me.

Trusting is scary. We’ve all been burned at some point. But we can also look back and see trusting someone helped us develop, personally and professionally. None of us could be who we are if we had not learned this critical skill. Knowing where and how to trust is critical to growth, to life. It’s not even just humans - we can see this in our pets, our livestock.

A cynic might say that trust limits us. That if we only had less, we could do and be more. I’m not exactly known for looking on the bright side, but even I know this is wrong. Trust is the infrastructure for our experiences. Removing it flattens everything, not just limiting what you can do but limiting why you would do it.

Our problem is too little trust, not too much.

We know the stereotype of someone who does not trust. Someone outside of society. We know a person who cannot trust is broken in some way, missing something critical, in need of healing. Many of us also know the allure of not needing to trust, or be trusted. “Ah, to be independent, to owe nothing to anyone…”

This is the dream of remembered childhood. It was always a lie. We were failing to notice the work being done in our name, for us. It was a joyous lie, made more pleasant with the golden tinge of nostalgia. Grown, we miss the lie, we reach for it.

But deep down, we know: More than anything else, life is about trust.

Great companies have been built on this truth. eBay could only exist by creating trust between unknown parties.

Some look at this and see failure. “If only eBay had not needed trust…”

One of the Blockchain’s great claims is enabling commerce between people who don’t trust each other. Never mind that of course you still have to trust something - the code, the packaging of what you’re buying, the exchange, etc. You might scoff and say these are a given, but none of those things can be trusted in the current world of the blockchain. Never mind that commerce has always been done between people with little or no trust. That’s not what matters.

It is philosophical, psychological: Given the recognition that life is enriched by trust, and more riches require more trust, what do you do? Find a way to add trust to your life, or look for a way to get riches without it?

I can’t say the blockchain people are wrong. Maybe they really do need some kind of trustless commerce. I don’t know them. Well, other than the drug dealers. I know why they want this.

But in my life, for my problems? More trust is the answer, not less.

Ironically, the blockchain can actually help with that. Without changing a thing. Its boosters are right about its utility, they’re just wrong about why it works.

I don’t like to trust people with my data. People talk about wanting to own their data, being able to share bits with Facebook but not the whole thing. It’s a nice, if naive¹, idea, but that’s not what I mean.

I don’t trust you to touch it. You’ll muck it up.

Heck, I don’t even trust myself. Actually, I was never given that choice. My apps don’t trust me with my own data. They keep it hidden away somewhere, behind an API, in proprietary formats.

Their distrust is reasonable. I don’t know how the app works. The data model is hidden, the storage internal. Most importantly, they can’t tell if I mess with it, and they can’t fix what I break.

Things were in some ways better in the age of documents, but now our data is all hidden. We ask them to give us access, and they sometimes comply with simplistic APIs. But they do not trust us.

What if they did? What if I were allowed access to my own data? What if I could share it with you, my close friend, because I trust you with it?

I mean, not entirely trust. I’m not stupid. We’re not that close.

With the right tools, I could see what you did, understand it, ensure it all makes sense. You could change it, query it, hand it back to me, and I could validate the whole thing. Get the best out of your work, but keep safety lines in place.

Again, a cynic would say call this an example of eliminating trust. But is it?

Is the key to this new interaction really that I don’t trust you?

No. I don’t want just anyone to have my data. It’s for you. My close friend. Who I already trust. Mostly.

This change does not entice me to share with psychopaths, strangers, or, god forbid, the people I went to high school with. It provides just enough of a bridge that I’m willing to give you, my good friend, who I just met on the internet, rights that I’d otherwise hold back.

Of course I know this is not what blockchain people mean when they talk about trust. Meh. I’m not interested in making capitalism even less moral, less human. I don’t even want to hang out with the people who do. But I am interested in making data more useful. And I’m especially interested in connecting with other people.

And this certainly does that.

Now my applications can expose their insides. They can be slugs instead of snails.² I can use the apps I love, but my tools can fill their gaps. I can script my way around their missing APIs and limited reporting. Heck, I don’t need their interfaces at all. Just because they’re provided doesn’t make them good, and I can get there faster using the tools I already know.

I can pick the best app, without committing to a long-term relationship. I can give you my data, take advantage of what you offer, and if I want to change later, I don’t lose everything.

There’s a great example out there: Github. If they went away tomorrow, I would lose almost no data I care about. They host, but do not control, my most important data: my source code. I get some utility out of they’re hosting it, but they don’t get special rights.³

Github actually created a new kind of trust relationship: Because its users can trust the data store, they began to trust strangers to contribute code. If I were using Subversion, I would have to give you all or no access; in Git, I can give you qualified access. Github calls these ‘pull requests’. “Yes, you can contribute code, but I get to read it first.” That enables a flowering of trust, potentially leading to a deep relationship. That path to complete trust is much narrower, much harder without this infrastructure of gradual trust.

You can choose whether to see this as more or less trust. You can’t argue with the new bonds created, the new groups formed, all through the help of tooling. Almost like how commerce starts with low-trust exchanges of money and can lead to deep and meaningful relationships.

What would a world look like if all of my applications had just as much, or as little, ownership of my data as Github does?

Of course, the apps won’t like it much. Their trusting me with my data also gives me power over it, where today I have none.

With enough usage, our expectations start to change. Given two otherwise equivalent accounting apps, wouldn’t you pick the one that trusted you? That gave you equal access to your data, simplifying automation and reporting?

I would.

This is the world I want.

This is the second article in a series in indefinite length on The Blockchain without Blockchain.

Facebook does not have all of your data because you provided a massive dump at once; they’ve painstakingly collected it over the years, bit by bit. You can be sure they’ll store every little piece you selectively reveal to them. ↩
Honestly I don’t know if slugs are more useful, but they’re certainly more vulnerable. And I could not think of a better analogy. ↩
There is some data that only they have. This is a limitation in git, more than the plan of GitHub. E.g., my follower list is not in my repo, which is probably good, but it’s not anywhere else I can access, which is probably bad. ↩

Blockchain without Blockchain

luke@lukekanies.com (Luke Kanies) — Wed, 09 May 2018 00:00:00 +0000

There is powerful technology hidden in the blockchain. Just strip out the parts everyone cares about

Image courtesy of MemeGenerator

People are very excited about the blockchain, convinced it’s going going to replace cash, or gold, or credit cards, or even the internet. I’ve even read claims that it’s the most important invention since little things like money and democracy. Starving through a failed attempt at utopia has taught me to align with the skeptics who point to the lack of proven use cases (other than fraud and crime), and with the pranksters who make fun of the claims of salvation.

That doesn’t mean I think it’s worthless.

The economic use cases (cash, gold standard, “sound money”, etc.) rest somewhere between unproven and conspiracy theory. None get any love from me. Just because I don’t respect the Austrian school of economics doesn’t mean I don’t understand it. They’re so stuck on their commitment to not learning from history that they can’t let go of the switch away from the gold standard. I am also not silly enough to think that the anti-government libertarians are in it for anyone but themselves.

I’m only here for the tech, people.

The world of the blockchain is in a state of flux. This is normal for movements, and especially so for the definitions of words to be shifting quickly. I experienced this directly as Puppet was helping to create the DevOps space. Today, when we say ‘blockchain’ we mean a specific set of features provided by the code underlying Bitcoin; some might add the requirement for smart contracts, as added by Etherium.

This definition won’t last.

I think that when we look up in five years, the word will mean something quite different. As the conversation inevitably shifts from hype about its universal applicability to finding practical use cases, I am convinced the term ‘blockchain’ will invert from its maximalist form, including all possible features, to a much more minimal form, defining a base set of functionality that is suitable to solving far more problems. Different implementations will layer features onto that base set, but all of these derivatives will be called ‘blockchain’ (which will soon have purists crying we’re not using the “real” blockchain).

It’s that base set of functionality that I’m interested in. I’m hoping the world’s excitement over the complete package can turn into momentum around a more flexible solution. What can we take away, and what can we do once we strip things down?

Let’s start with the most obvious thing we don’t need: Lack of trust. Free markets are built on trust, so it’s silly to try to build one that doesn’t. I just don’t run into many problems that can only be solved if I never trust anyone. Even writing that out makes me cringe.

I’m interested in power tools, user productivity, and helping teams, which inherently means I’m interested in people who know and trust each other. That isn’t to say data validation and simple synchronization are never helpful, but trust between people is not a problem. So take out that whole part of the story.

Next up is consensus. Let’s be honest: You don’t really want the world to have access to most of your data. And most of you who do, well, it probably doesn’t want to see it. This solution for deciding whose copy of data is right? I don’t need it.

That isn’t to say there aren’t important consensus problems; it’s just that the blockchain’s version of them is not useful to me. I do actually struggle with managing conflicts in my own work. I’m writing this essay on one of the six devices I regularly work from, and I obviously want it to transparently synchronize between the rest. I can dream about never having conflicts, but in the real world I need a simple way to handle them when they happen. That’s my consensus algorithm. If I use the Blockchain’s, then one chunk of work wins and the rest of the work gets thrown away. That might work well in some environments, but is obviously a non-starter for my personal work. Instead, I need an algorithm that gives me control over managing my own work streams.

I expect a blockchain hodler would flip at calling this a “consensus algorithm”. It’s not. It’s more like a tool for managing merge conflicts. If you buy into the blockchain, you’ve added a ton of complexity that can and should be handled by a person.

It’s not a big leap from managing conflicts between one person’s devices to managing conflicts within a team. This is still an important problem, one wrestled with by anyone building online collaboration tools, but requires nothing like the level of infrastructure built into the blockchain. After all, I trust myself. I trust my team. I like to be able to verify, but I’m more worried about mistakes and data loss than I am about intentional subversion of the system. And actually, the current solution is horrible for teams. It’s one thing for someone else’s work to cause yours to sit in a queue for a bit, it’s another thing entirely to have your code thrown away because someone is in front of you.

Taking out the trust-less consensus allows us to remove the worst part of bitcoin: Proof of work. This is how parties in a blockchain transaction fight to have their work accepted and others’ rejected. If they win, they are rewarded with a token, which is how they’re “paid” for their work.

We don’t need any of that.

We’ve already established we don’t need an automated, trustless process for deciding who gets to update the database (and we’ve concluded we don’t want conflicting just thrown away). As a result, this whole mechanism can just be removed. Good thing, too, because bitcoin is in the process of consuming all of the world’s natural resources in the name of never trusting anyone. This also simplifies the problem of scaling these databases. Bitcoin is stupid slow because its proof of work system is stupid slow. Remove that, and any iPhone can trivially record new data as fast as you want.

Now that we don’t need proof of work, we also don’t need, surprise!, the currency itself. In a trustless system, tokens are used to compensate the networks recording the transactions. This is now so cheap we don’t need to reward people to do it.

There you go. Now you’ve got the blockchain, except without cryptocurrencies, trustless transactions, consensus algorithms, or proof of work.

The blockchain without blockchain.

It’s important to note: It’s not that I think none of these features are ever useful in any case. It’s that none of them are necessary to get the most important features out of the blockchain, and each of them should only ever be added to a system if they’re truly needed. In most cases, YAGNI.

What can we do now? Well, obviously, now that we’ve removed so much functionality we can do a lot more. General purpose languages are more powerful than specialized ones, and a more flexible database is a more powerful one. The current set of blockchain features can really only be used for a narrow set of use cases, and even those seem to be more theoretical than actual.

What’s left?

A database. That’s what the blockchain always was anyway. It’s built on Merkle trees, which means you can validate every change back to initialization if necessary. This makes it kind of trustless: I can validate your work, rather than just trusting your word of what you did. This ability actually encourages me to trust you more with my data, though.

Check back later for more about what I mean.

This article is the first in a series of indefinite length. I’ll explore the consequences of this stripping away. I will also address some of the potential I see for full current blockchain feature set. I look forward to approaching this topic from a different direction.

The power of better tools

luke@lukekanies.com (Luke Kanies) — Tue, 24 Apr 2018 00:00:00 +0000

There is a solution to wage and productivity stagnation. Just don’t call it automation

Image courtesy of Washington Department of Transportation

I don’t know what the rest of the world thinks when they use the phrase ‘power tool’, but for me it’s visceral, literal. My experiences using them and watching them transform my family’s work permeated my time building Puppet. These power tools aren’t little plugins to expensive frameworks, they’re large capital investments that dramatically change your job.

I grew up building houses with my dad. The worst task he gave me was trying to paint a set of louvre doors for a closet while in high school; I had to flip the doors over every 90 seconds to catch drips getting through the slats. After three days of misery, my father relented and rented a paint sprayer, with which we finished the job the same day, at a much higher quality.

Around the same time, my dad would rent a pneumatic nailer for big framing jobs. By the time I finished college a few years later, that critical tool went from borrowed to owned and traveled everywhere with him. Initially used only for large jobs, most contractors now have multiple nail guns to cover framing, trim, and every other use case, and the air compressor needed to power it is as important as electricity.

It might not be obvious, but both of these are examples of automation. You replaced a very manual process - applying paint, or nailing things together - with a machine. If this were a factory, these days you’d call those machines robots, but because it’s a construction site, we just call them tools.

And these tools were expensive. Even with how much faster we finished that painting job, I expect it cost more to rent the sprayer than to finish the work manually, because of how little he was paying me. (This does ignore the soft costs of listening to me complain, which were likely high.) Even today paint sprayers and nail guns are often rented rather than purchased, because good ones cost a lot of money and aren’t needed all the time.

It’s no surprise that discussions of tools and productivity are easier to understand from my experience as a carpenter than as a sysadmin. There’s plenty of room for arguments about what is or is not a software power tool, but when it costs more than a week’s wages, it trails a bright orange cord everywhere it goes, and it can nail your hand to the wall while you’re standing at the top of a ladder¹? It’s a power tool.

There’s a common story about what robots and automation do to people like my dad (and both of my brothers, who followed in his footsteps): It steals their jobs and ruins their lives.

What utter poppycock.

If you think of your job as driving metal spikes into wood, then a nail gun is a mortal threat. But if this is your value add, your biggest danger was never automation. My dad never sold his ability to join raw materials together quickly; he sold homes, he sold the opportunity to enjoy your house and family more. How did these new power tools affect that?

They were awesome. Painting and nailing are classic examples of menial, low-value work, and yet we spent most of our time on them. All of the differentiation we offered to our customers was packed into a narrow slice of work, because implementation took so much time and money. As we were able to bring more powerful tools to bear, the menial work shrank and larger portions of our time could be spent on design work, customer interaction, and tuning our customers’ homes.

Interestingly, my father’s next career step was even more pointedly about experiences enabled by tooling. He took a job with a state hospital in Tennessee, fabricating custom furniture for severely disabled patients. Suddenly he was using industrial sewing machines for upholstery, and partnering with medical professionals to design multiple beds for each patient, enabling them to be happier and more comfortable (and also avoid bed sores, thus saving hundreds of thousands of dollars per patient). Given the tragically minimal budget allocation for this kind of work, every dollar saved through automation and tooling directly delivered health and happiness to his patients.

It’s no wonder I see the value in power tools, that I am more conscious of the benefit they can deliver than the loss of low-value menial work.

I had a similar experience as I was building Puppet. I would meet executives and salespeople (I don’t know why it was always them) who would say, “Oh, automation? Great, you can fire sysadmins!” No. Beyond the obvious reality that I was selling directly to my users, who would never buy on the promise to fire their coworkers, that was just not why we were valuable.

Puppet gave people a choice between lowering cost but keeping the current service quality, or keeping your costs flat while providing a much better service. “Wait, making things better is an option? I didn’t know that!” Most companies were aware that their IT sucked, but they only knew how to measure and manage cost, so that’s what they did. Once you believed in the power to make things better, power tools turned out to be great investments for both the user and the buyer.

By letting people spend more time on the parts of their work they enjoyed, the work that makes them special, we also delivered higher quality experiences for their customers and constituents. “Spend less time firefighting and doing menial work, and more time shipping great software.” If the heart of your skillset is clicking buttons or responding to outages, Puppet might have been a threat to you, but our users knew where their real value was. We helped them spend more time there and less time on the boring, low value stuff. The sysadmins hated the work, the customers hated to need it, and the executives hated paying for it. Great, done, don’t worry about it.

When you look around the software market, though, power tools are out of style. There are big data companies building for the non-existent average user, minimalist companies building solutions that do little for almost everyone, and there are power tool companies of yesteryear still hanging around. There just aren’t that many modern software companies building large, clunky, expensive tools that just might cut your hand off if you’re not careful.

That’s partially why productivity has stagnated². The world has not changed that much - some of the greatest improvements to productivity come from making large capital investments in tooling for your workers - but how we spend our money has. People balk at a $5k computer, when the Mac IIci would cost more than $13k in today’s dollars just for the hardware, yet was a powerhouse in desktop publishing. This is to say nothing of how the mobile app stores have driven down what people are willing to spend on software.

Yes, Adobe’s software is expensive, but it’s that price because it delivers so much value. If it didn’t, no one would buy it. Every large market should be so lucky as to have the collection of power tools that graphic designers get. It sounds crazy, but we’re suffering from not enough expensive software. Instead of building the most powerful software possible and finding customers who see its value, companies are building the simplest thing they can and trying to get everyone to use it.

There are bright spots in the industry, like Airtable and Superhuman. I’m hoping they help to shift momentum back to automating away the tedious work and enabling focus on what humans excel at.

More powerful tools improve your life, but they also make you happier even if you can’t buy them. They tantalize you, promising you great returns, if only you can come up with the cash. And they’re maybe just a little bit scary, warning you that buying them is not enough. You must master them.

A friend of ours managed to do this when working alone in the time before cell phones. ↩
Yes, I might be being simplistic to make a point. ↩

The Market Is Wrong About Your Problems

luke@lukekanies.com (Luke Kanies) — Tue, 17 Apr 2018 00:00:00 +0000

What Voltaire and the Flaw at the Heart of Economics Have to Teach Us About Software That Doesn’t Exist

Voltaire’s Candide juxtaposes an optimistic philosophy with unbelievable tragedy. He was angry at the 19th century philosophers who proclaimed that we lived in the best of all possible world while destruction and death unfolded around Europe on an epic scale.

We might hear the claim that we live in the best of all possible words and scoff. Of course, we’re too enlightened to be such naïve optimists. But are we? Isn’t the belief tempting? Or even, doesn’t the behavior of those around you make more sense if you realize they believe this, at least a little bit?

Economists are theoretically rational, analytical, big picture thinkers, but at the root of modern economics is a belief shockingly close to Candide’s parody of optimism. They have what they call “The Efficient Market Hypothesis” (EMH), which roughly states that all assets are valued fairly. This is built off the idea that asset values in an open market are fair because they include all available information, and all the actors in that market are behaving rationally in regard to both the asset and the available information.

This theory tends not to trigger the cynicism that Voltaire does. Intuitively, it sounds not just right, but defined as so. Isn’t an open market essentially a mechanism for finding the fair value of an asset? It’s not so simple. And when it goes wrong, it does so spectacularly.

Modern economists cannot be as destructive as the great thinkers of the 18th century, whose big ideas justified eugenics and many other horrors. Just because they cannot as easily be used to justify mass murder does not mean they should not be accountable for the downsides of their obviously incorrect theory.

“No”, I hear you say, “the EMH is not wrong; it’s correct by definition.”

Economists have convinced us of what Voltaire was protecting us from: We live in the best of all possible markets, where all information is public and all assets are fairly valued. If the market does not value something, that it must actually be worthless.

But of course, if that were true Warren Buffet would not have become a billionaire buying stocks that were worth more than the market was paying, the finance industry could not have been built on advising clients about public stocks, and you’d have no need for lemon laws or other regulations that fight information discrepancies. Nor would Kahneman and Tversky have won the Nobel Prize for demonstrating that actors in an economic system behave anything but rationally, puncturing the EMH for good. Thankfully, this has forced the field to begin to grapple with its flawed underpinnings, but many modern beliefs are implicitly built around these bankrupt theories.

You might be patting yourself on the back right now for not being silly enough to draw Voltaire’s ire, but it’s baked into the value system of the world around you, especially if you live in the US.

The market moves from irrationally ignoring new technologies like the blockchain to irrationally dumping money on them, without any fundamental change to justify the shift
Investments are made based on proximity and serendipity rather than rationality and opportunity size
We tend to claim that the rich earned their status through hard work, rather than recognizing the role of privilege, inheritance, and luck in their status

Of course, not everyone in the market operates with such optimism, but each of us is biased in this direction. It affects our thinking whether we want it to or not.

“Ok”, you say, “even if I accept some people make optimistic investment decisions, what does that have to do with software?”

Great question. If we live in the best of all possible markets, where all information is public and all assets are fairly valued, then we can trust the market’s assessment of what software should and should not exist. Lack of software to solve a problem is a sign that it’s not worth solving.

If, on the other hand, our world could be better, or if our market is imperfect at valuing assets, then we can’t trust intuitive conclusions about where value resides. This is most true when it comes to valuing unsolved problems. It might be that a given problem has no solutions because it is not worth solving, but mundane reasons are more likely to be at fault.

Most great companies exist because they provided something the market did not know it wanted. Their founders encountered a flaw, and managed to build something great in the opportunity created by it. Henry Ford claimed if he’d have given people what they wanted it would have been a faster horse. The market knew how to value them, but not cars. Before Apple, the market did not value personal computers. Before Google, the market valued directories but not search engines. Before the iPhone, the market valued expensive phones for professional use but not personal.

These value statements were market failures, and their resolution generated billions of dollars for the companies resolving them. Now, of course, the market sees great value in what these founders have created, but not because the market is so smart; it’s because it can no longer fool itself.

It’s easy to grow despondent in the face of such obvious market failures. If the wisdom of the crowds, the great invisible hand of the market, can be so wrong, what hope does a lonely entrepreneur have? I take a different way.

I luxuriate in these misses.

They surround us. We bathe in them. Yes, many great companies have grown into critical market gaps, but even with all these successes, there are untold problems whose solution should be valued but is not.

Only once you reject the market’s flawed opinions about what matters, you begin to see nearly limitless opportunity. There are so many more unmet needs than there are perfect solutions. These are your opportunities.

Of course, just because the market dismisses a space doesn’t mean there’s a great opportunity there. It’s your job to know the problem, your customer, your user, your buyer well enough to draw your own conclusions, to develop enough certainty that you don’t need someone else to tell you what to believe.

Because that’s the real point: Trust yourself, not a bunch of paternalistic optimists.

Owning my writing

luke@lukekanies.com (Luke Kanies) — Fri, 13 Apr 2018 00:00:00 +0000

It’s the message, not the medium

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Why We Hate Working for Big Companies

luke@lukekanies.com (Luke Kanies) — Tue, 10 Apr 2018 00:00:00 +0000

Modern capitalism raises the flag of the free market while pitting centrally planned organizations against each other

It’s quite a journey from being born on a commune to raising more than $87m in funding at a software company. This journey forced me to wrestle with existential questions about my true beliefs, and how they intersected my life as an entrepreneur. One’s work is rarely a pure reflection of ideology, but companies need a clear and authentic strategy, which requires a tight alignment between company operations and the founder’s philosophy. I have discovered more about those differences between what I believe and the best ways to grow a corporation while studying economics - that is, how money is made and exchanged - than any other area.

A worldwide conflict between communism and capitalism defined the latter half of the twentieth century. The United States’ ideological battle was the central drama of my childhood, and it was with a combination of glee, pride, and “told you so!” that my fellow Americans watched the wall fall in Berlin, and the USSR dissolve shortly thereafter. I expect few would deny that the US is the standard bearer for capitalism.

Yet, there’s a flaw at the heart of this claim. While the United States operates as a free market economy, the key agent within modern capitalism - the corporation - works more like an authoritarian state. Given how much of our world is built around corporations, this truth and its impacts are critical.

I grew up apart from America’s passion for capitalism. In the era of Reagan, I was living on a commune. My parents did not earn money for their labor, and we didn’t have personal property. My family left the Farm when I was 8, and as I matured, my ideological roots were in conflict with the US’s nonstop pro-capitalism message. As I joined the workforce and eventually started my own company, I found myself attached to neither the communal roots of my childhood nor the Wolf of Wall Street world I moved into. I grew slowly in convictions, as I encountered problems in the course of scaling a company.

The first real conflict came when it was time to hire managers. I founded a company primarily because I did not thrive as someone else’s employee, so what led me to think others would? More importantly, anyone who has ever operated at the front line is aware of the severe costs imposed by the separation between the people who do the work and the people who make the decisions in hierarchies. Hiring managers was just going to make the company do worse, not better, right? Right?

I expect three of you are gleefully shouting, “Yay, holacracy!” right now, while the rest are confused and either offended or think I’m an idiot. I did consider a manager-less world, but a little research provided only examples of disaster, because the only available options just replace an explicit power structure with an implicit one. In other words, it’s still hierarchical with the founder on top, but now decision making is opaque and the system is easy to exploit because of the lack of controls (which looks surprisingly like the cult/commune I grew up in).

Those who are confused or offended by the idea that managers make performance worse would be informed by a deep dip in economics. One of the core principles of the free market is that central planning committees can never be as efficient or as effective as the people doing the work. By definition a free market economy lacks a decision-making hierarchy; the ‘free’ means every agent (individual or corporation) can decide for themselves, without needing permission from a manager above.

While there are many aspects of modern American capitalism I reject, this one I wholeheartedly support¹. The downsides of a strong central executive were taught to me early.

Like many other communes, the one I grew up on routinely failed to feed its people - my parents speak with horror of the ‘wheat berry winter’, when we lived on little else. While his people were short on food, the founder of the Farm was off touring Europe as the 3rd drummer in a band, “bringing our message to the world”.

Thankfully none of us starved to death, but the failing was similar to what most communist countries experienced: The central organization could not feed everyone. For years, I assumed this was just incompetence, whether at the scale of the Farm or China. The truth was far more structural. Millions starved during the Great Leap Forward because the central organization was trying something impossible: Managing the productive output of an entire country. The Planet Money podcast tells a great story of how this central planning was walked back in China, but the general point here is that these communist countries did not just nationalize the means of production, they tried to centrally control all of it from within a small group.²

When people talk about communist countries not being a free market, this is what they mean: They tell the farms what crops to produce and in what quantity, rather than letting them decide for themselves. China even went so far as to dictate what hours a farmer should start and stop working, and then directed managers to ring a bell for transition times to control every little group of farmers. Anyone who’s ever had to punch a clock into a rigid, dysfunctional hierarchy is likely getting painful flashbacks about now.

It should be immediately obvious why this fails miserably: The distance between the central planning committee and the farmer is so great that good decisions are nearly impossible. It’s nearly impossible for critical feedback to make it from the edge, where the farmers are working, to the central planning committee in time to affect decisions, and then for those decisions to make it back to the edge in time to be useful. The podcast linked above also points out how unmotivated the farmers were under this regime, cutting productivity even further. Those who have studied lean manufacturing, agile development, and DevOps are likely seeing parallels here.

The result was catastrophe. When a corporation is painfully inefficient it loses money and might have to do layoffs, but when a country fails at growing food, its people starve to death. I don’t mean to imply that central planning was the only cause of famine under communist rule - there were political operations that led to mass starvation, just like in the West - but learning more about these helped crystallize what I do truly prefer about capitalist models. It also converted the phrase ’the free market’ from a catchy slogan into something meaningful to me.³

The most important feature of free market economies is that each person within them is able to make independent decisions in their own best interests⁴. If you’re a farmer, you can decide what to grow, how much to grow, and when to work to develop your crop. Heck, you can even choose not to be a farmer any more. Success is merely dependent on your finding a buyer for your work at a price you can tolerate. Any given year might not be perfect, but your decision making gets better over time as you learn to respond to customer demand.

This pattern is easy to understand in any system where the people doing the work make the decisions. If you’re a jeweler, you can decide what to make, how much to sell it for, and what to spend your time on. Same if you run a small restaurant, lead local tours, or are a one-person shop doing house remodeling. It’s a free market, where you can charge what the market will bear, and you can quickly and efficiently respond to its whims, ensuring that you are getting the best use of your time.

This was a powerful organizing principle for a long time. The history of human commerce developed largely this way: One person, or as many people as could fit in one shop, would turn labor into a product, then find a buyer for it. Most large-scale efforts were organized by the state of the time: Monarchs and the landed gentry, who were the only ones capable of marshaling enough resources to build palaces, roads, and other large construction projects.

This began to change in the 17th century when corporations like the Dutch East India Company were able to deliver massive windfalls to investors by pooling money and using it to extract resources from colonies. There was a step change in the 19th century, as corporations went from generating wealth to building and owning infrastructure. It’s one thing to outfit a single ship for a year-long voyage, yet another to maintain railroad schedules across the United Kingdom, or run a telegraph network around the whole US. These aren’t just short-term money-making exercises, they’re long-term commitments with big capital outlays and large returns over years and years.

We still live in a free market economy, but it’s not one Adam Smith would recognize. Instead of individual or small operators, ours is composed almost entirely of corporations. Really big corporations. And these companies, they use the same kind of central planning that we so despise in communist systems. I know. I’ve done it.

By the time my company got near 500 people, we had a multi-week planning process, where the leadership (i.e., me and my lieutenants) set out top-level goals, built a top-down plan to accomplish them, then drew information from the front line to see where it needed change. We called this a bottom-up plan, but it was only bottom-up from the perspective of numbers - how much money we’d have, what our costs were, etc. - rather than from the bottom of the organization. We could see no way to have a system where the people doing the work built a plan for the organization. Even thinking about it now, my reaction is, “How would they know what my goals are?”

That’s the kind of question you can only ask in an authoritarian state, not in a free market economy. My goals became my company’s goals, and the only real way to ensure people worked toward them was providing a plan. You might argue that a corporation should focus on shareholder value, but that doesn’t help make decisions about what the company should actually do.

Great leaders find a way to listen to everyone in the company, but in the end, leadership is about making decisions. That’s essentially the definition of the word. And we all know leaders who did not bother to listen, or just did not need to in order to be great; today’s most vaunted tech leader, Steve Jobs, was famously disrespectful of the opinions of others, yet made a lot of world-changing decisions (not all for the better).

This is exactly why working in a big corporation is so stifling. If you’re in a small company, the executives are close enough to the front line that it’s more like working in a tribe, but in a big company, the leadership is so removed from whose who do the work that executive teams operate like the politburo we so decry in communist countries. Certainly the bureaucracies are no more enjoyable or forgiving.

I find it both ironic and painful that my inability to work for someone else resulted in my creating a company that involved a lot of smart, capable people working for someone else.

I wish I had a solution. If this were an easy problem, its solution would already be pervasive, because the benefits are massive. Just in terms of efficiency, we’ve seen how much better the free market is than planned economies, but it also has a hugely positive impact on quality of life. People are happier when they’re in control.

I know the solution is not more freelancing and contract work, which America’s corporations are addicted to. That’s the worst of both worlds: The exploitative nature of capitalism with the inefficient bureaucracies of communism. Transactions on the free market work because they’re good for both sides, but most people only accept part-time contract relationships today when they have no other real choices.

Holacracy certainly isn’t the answer. It’s fundamentally flawed because of its implicit power structure - Tony Hsieh still runs Zappos, even if he does not use a central planning committee to do it - but the biggest problem is it makes no mention of economics. Without a clear system for scoring the transactions (i.e., money) it’s impossible to build a free market.

This problem of how to handle economics within a non-hierarchical company might lead some to think of using blockchain tokens as an internal currency. This is impossible today, beyond the fact that the world of blockchain is mostly about fraud and black market sales. The biggest problem is that we have no idea how to value most of the work people do. I mean, we might know that what a developer should get paid for a year’s work, but how much is that work worth? The majority of the work done in modern corporations is incredibly hard to value, which is partially why companies are so inefficient and make so many bad decisions.

That brings up an even bigger problem - companies today hire workers to make money from their labor. In other words, they generate profit because they pay their employees less than they’re worth. If everyone could trade their labor for exactly the amount of money it was worth, the corporations that employ them would have a much harder time making money. Instead, in modern corporations the shareholders and the executive team - again, the central planning committee we so despise - make the majority of the money, while the front line does all the work and makes very little. This is true even at the big tech firms; software developers might be well paid relative to hotel workers, but they’re paid a pittance compared to the founders and executives. This might speak to why we have no solution yet - free market corporations would tend to reduce concentrations of wealth, which would be terribly disruptive to the current system.

Like I said, I don’t have a solution. But at least now I know what makes the current system so painful, and it gives me some hope that we actually can come up with a better answer. I know I’ll be working harder in the future to manage the downsides of what we have today.

Although I might stress the “well regulated” part more than most modern economists. ↩
Of course, capitalism is just as capable of killing its citizens, whether through starvation or lack of health care. ↩
Note that I’m not taking the capitalist side of the cold war here; while Americans were decrying the oppression of the Soviets, we were actively clawing back progress on civil rights and knocking over democratically elected governments. This article is about principles, which political regimes rarely show a great track record in following. ↩
But not so independent that you should be as pathological as Ayn Rand. ↩

Abandoning Trello

luke@lukekanies.com (Luke Kanies) — Fri, 06 Apr 2018 00:00:00 +0000

On the value of change and focus

I have been a passionate advocate of Trello almost since the day it came out. Visualizing the work is incredibly powerful, and its use of priority by ordering is so obviously better I could not imagine using anything else. I have brought Trello into companies, and caused hundreds of people to use it. Recently, though, I stopped using it in key functions, moving my personal tasks into Things and other work into the applications that own it. It started as an experiment, but quickly snowballed into a full transition as I realized how much better it would be for my core use cases.

I am a productivity junkie, from GTD to Deep Work, and while I know the tools aren’t the work, they’re one of the fastest and easiest ways to change a system, bringing new perspective and abilities.

I initially adopted Trello for managing my personal tasks. From there, it slowly spread to group and company use cases, and by the time I left Puppet in 2016 it was baked into our core business operations.

I had considered switching away from it for my personal tasks a few times, because it’s been obvious for years that it was not a fit for how I managed and processed my life’s flow of work. Where I had always taken great pride in my productivity system, I could no longer muster the discipline it required, which meant it was extraneous process and I was also failing to do my job. I sank so low that I began sending person to-do items to my inbox. shudder However, my life as CEO was busy, yet not really built around task execution, so it was never worth the cost of the tooling change. Or so it seemed.

While I abhor tooling changes for their own sake, sometimes you just have to experiment, and when I had a run of open space I decided it was time. Even if other places were worse, I was better off spending time elsewhere to get out of my funk than I was continuing to stare at this board that just wasn’t working for me.

As I looked to move away from Trello, I wanted to switch to OmniFocus, but the timing is wrong. I recently downloaded the current version, but it reminded me why I stopped using it years ago: It asks too much of me¹. The biggest disconnects were the need for contexts, and the inability to set priority by dragging items around. It looks like the impending next version will be a great compromise for me, but I can’t use it until it arrives.

As I began moving tasks into Things, I was slowly reminded what it was like to have my task app be, well, an app. Before Trello I used Asana, at a time when its mobile experience was just a badly packaged web page. It’s been years since I had the pleasure of working with someone who bothered to build for the platforms I used. What a difference it makes.

Processing this small but meaningful change took over my brain for the rest of the day. I could not let go of the transition, but I also could not stop thinking about its consequences. “Thinking” is being too generous. I had not seriously looked outside of Trello for years; all of my habits and instincts are built within its constraints, its physics model. That meant wide open opportunity to construct whatever world I wanted, but also the need to do so, and embarrassing mechanisms for getting in and out. Creating a quick task in Trello is most easily accomplished by sending myself an email, which tells you how seamless the core experience really is. Telling Trello of work to be done in another application usually required custom applescripts to connect the two (e.g., creating message:// urls).

The keyboard’s change in utility keeps hitting me. I did not realize how rarely I used Trello shortcuts for their sheer disagreement with my hands. Well, partially, they were insane - ‘c’ archives cards, where I kept thinking it would create them, and repeating mistake kept my hands off the keyboard - but also, they were just different. I keep visualizing myself sitting at Things, fingers poised over the keyboard, in a world that makes sense to me. It’s pleasant.

I have a lot of work in Trello. Basically everything I’ve recorded in the last 4 years about what I could or should do is there, and it’s been the platform for organization all of that information. I’ve always been pragmatic, so even when I built it I would not have said it was the “best” answer, just that it worked at that time for my use cases.

Now I am questioning everything I’ve done recently - not to ask if I’ve made a mistake, just wondering what the world would look like if I had done that work differently. Are there projects languishing from sheer friction, that would suddenly become easier if migrated?

The answer in at least one other case is ‘yes’. I had a Trello board for managing all of my writing ideas, and I had a standard right-to-left workflow from idea to writing to done. I just never really used it. Instead, I did all of the management of writing in the same place I did my actual writing: Ulysses. I built a workflow from folders² instead of lists³, and eventually I realized that the Trello board was hurting, not helping. The ideas I put in there languished, and Ulysses is just as good at capturing a sentence or two about a post as it is for writing the entire thing. The board is now closed, and my writing is in the same place as all of the work needed to manage it.

Tools do not make the difference, but tools can make a difference. A thing can go from undoable to tractable with a small change in tools, just as a math problem can go from impossible to trivial if you flip the equation around a bit.

I know Things won’t work for many of the use cases I have in Trello, partially because it’s so obviously a single-person tool, and much of my work does not have a home I can move the organizational work into. E.g., I have a list of lists in Trello of all of the day trips I could consider taking around Portland, and I can’t think of where I’d move that. I don’t know where those other problems get solved now. Maybe they don’t change.

But I know my standards have been reset. I know I made a mistake letting myself sit in one tool for years, unhappy but unwilling to invest in the change. It’s a wonderful feeling to be looking at the world through new eyes again.

To be fair, I also stopped using it in the days when it took 45 seconds to open the app on an iPhone, because that’s how slow the data synchronization was. ↩
Which they call ‘Groups’. ↩
Really, are they any different? ↩

Great design is ruining software

luke@lukekanies.com (Luke Kanies) — Tue, 03 Apr 2018 00:00:00 +0000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Putting OKRs Into Practice

luke@lukekanies.com (Luke Kanies) — Tue, 20 Mar 2018 00:00:00 +0000

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

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

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

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

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

Here’s how we did it.

Startup Days

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

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

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

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

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

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

Scaling

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

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

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

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

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

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

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

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

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

What might come next?

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

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

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

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

Conclusion

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

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

Where does your work live?

luke@lukekanies.com (Luke Kanies) — Tue, 13 Mar 2018 00:00:00 +0000

Most of our software is confused about what job we’ve hired it for

I’ve really enjoyed playing Zelda: Breath of the Wild, but my life has been changed more by one of its reviews than by the game itself. The review had a unique view on what made the game so great. It contrasted Zelda to other games - Destiny, for example - saying that while others tended to distribute gameplay across multiple areas (e.g., in Destiny, the radar is a critical part of the game), Zelda really focuses the game into the main screen where you walk, glide, ride, and fight.

The review (which I unfortunately cannot find, because of the quantity of posts online that all use similar words) called this “where the game lives”. I love what this phrase evokes. I absolutely loved the game Borderlands, but I was deeply frightened of ever finding out how much time I spent at its store screen, because item collection and management was such an important part of the game. A lot of its fun was specifically from the collection, rather than the playing, but that meant a large chunk of the game lived in the store, as opposed to out in the world.

Most of our software could use a similar dissection.

Like Destiny and Borderlands (which are both great, and quite similar), the tools we use show a surprising distance between what they help us do and what we’ve hired them for. If I may be permitted to steal from this review, this distance is a sign that our software is confused about where our work lives.

To pick a counter-example, I’m writing this post in Ulysses. People who choose this software laud its simplicity, which makes it easy to focus. What they really mean is, all you can do with it is write. There’s almost no formatting, very little organization, very little anything but writing. The work lives in the writing. (My first draft was written on an ipad, which further simplifies that focus.)

Contrast that with any task or project management tool. My wife and I are in the middle of planning a bunch of camping, and we’re using Trello to organize many of the options. What is Trello’s opinion about where the work lives?

Last time I looked, my wife had three browser windows open, each with about fifteen tabs. She’s also working in RoadTrippers (Pro, natch). To get this work into Trello is a process of copying, pasting, writing copy about why you pasted it, and then using Trello to file it so you can find and manage it later.

In this operation, where does the work live? It’s scattered across maps, calendars, browsers, and applications like RoadTrippers. Does Trello know that? Does it agree? How does its opinion of where the work lives affect its utility? Brief introspection leads us to conclude Trello has no idea where the work lives, and the humans using it are entirely responsible for connecting the two.

Here’s a simple exercise for anyone using a task tracking app: Envision yourself going into that app and just marking everything done, even though you obviously haven’t done the work. It hurts to even consider, doesn’t it? Your brain has absorbed that these tasks are representations of work, and it’s your job to match the representation to the work, because you know the tool won’t do it for you. When you mark something done, of course nothing goes out and does the work; you’re just lying to your software about the state of the world. And it has no idea! This disconnect is what leads to an allergic response to the idea of marking work done in software that is not yet done in the real world.

I’d like to say that Trello was just a bad example, but I think all task tools share this confusion. Bug trackers and project management tools are specialized examples of this, and they obviously have no idea where the work lives. If I’m writing code, all of the work is done in my text editor, in files on disk, and maybe in my testing tools to ensure the work is done and done right. I then go somewhere entirely different to mark the work done. Why? Shouldn’t GitHub know it already? Why do I have to explain it? The answer is because these trackers think tracking is the work, when of course, the work is the work.

It’s no better in personal tools. I just started using Things 3 for my own tasks, nearly all of which end up being expressed in email or calendars, yet Things 3 has no conception of either. It has no idea where my work lives, and expects me to put out all of the effort necessary to connect them.

Speaking of email and calendars, they have their own role in this conversation.

Email is interesting. Everyone hates it, because it’s so important to everyone that we use it constantly, yet this animosity is a result of its utility and criticality. In other words, people hate it because it works so well. But when you’re doing email, what work are you actually doing?

I’m not sure I know. You’re communicating. But usually, you’re communicating about some other kind of work, like a document, a meeting, or some kind of activity that takes place outside of the inbox. A well designed application will remove the need for communication via email - Google Docs is a great example of this. Its sharing and commenting features have allowed many discussions to move from email to where the work is, in the document itself; their addition of suggestions has doubled down on focusing on the work, rather than talking about the work. (Note that this is completely different from Slack, which advertises that it gets rid of email, by which it means it moves the conversation, not that it does a better job of bringing the work into the software.)

Of course, how do you have Google Docs tell you someone commented on your document? Email. :)

What about calendars? Why do calendars exist? As a tool, where does their work live?

I am thankful to have had to try to explain to a friend my position on this, otherwise I’d think it was easy to understand. It’s so counter to how people work today that a relatively obvious truth is impossibly counter-intuitive: calendars are about how I spend my time.

When using a calendar, the work is what you actually do. You, a person, out the in the world. That’s what the calendar is about. Its job is to ensure you do the right things at the right time, with the right people, in the right place. It’s about doing, not documenting, managing, or notifying. You can put something in a calendar and not do it, or do work that’s not in the calendar; any of us would say, obviously, that it’s what you do that matters, not what the calendar says. Merely creating an event has no effect, and thus no value; it only matters if it then affects your behavior. The work lives in what you do. But does your calendar make even the slightest attempt to directly manage how you spend your time? What would that even look like?

To pick a small example, my calendar apps seem to not care what city I’m currently in, or where I’m physically located. Isn’t this weird? The tool whose primary job is to manage where I am physically located makes no attempt to represent or take into account the core fact it is meant to control. It still dumbfounds me.

Yes, they can tell me in real time when I should leave for a meeting based on travel time (as long as travel involves driving, rather than walking down the hall to a conference room), but they can’t say, “Given that on Tuesday you’ll be in Portland, working from home, you should block out travel time to get downtown to lunch and back”. That is, they can alert me in the moment, but they can’t do their core job - reserving time to ensure I’ll be doing the right thing in the future. Because they can’t do this, I have to create those blocks myself, else I’ll find myself choosing between skipping one appointment or being late to another. The whole point of a calendar is to manage time, but in this simple example they fail to ensure I will have space to transition my corporeal existence between physical locations. Shouldn’t that be step one, rather than an exercise left to the human?

I also reserve time for tasks I do alone every day, like working out and writing. I do this primarily to ensure it gets done, rather than because those times are special (although I do get a bit jittery now if I don’t write first thing in the morning). There’s no way to explain to my calendar what I’ve actually blocked that time out for, and thus no way for it to respond to whether I’ve done it or not, even though my computer knows if I’ve done my writing, and my watch knows if I’ve worked out. Wouldn’t it be great to see your calendar dynamically rearranging your day because it noticed you missed your workout?

My calendar is confused about what work I’ve hired it to do, and therefore does not know it needs to look in those places.

We’re so used to the idea that our software represents the work that we seem to have lost hope that it will actually help us do it. Most of the tools we use are entirely disconnected from the work they’re supposed to help us with. Marking something done does not do it, deleting email does not indicate communication has happened, sitting at your computer while your calendar says you’re writing does not produce text. The representations are not the work, yet we forgive our tools for only dealing in representations, not actual work.

I don’t know if that reviewer was right about why Zelda: BoTW is so great. I can’t even imagine what all the software I use would look like if it were built around where my work lived, rather than merely being used to model and manage it.

What I do know is that our software can and should be built to help us do the jobs we’ve hired it for. But because it is confused about why we use it, what we do every day is lower quality, less fun, and just downright confusing.

This also shows just how much opportunity there is to improve the software we use on a daily basis.

Founding Myths are Pernicious Propaganda

luke@lukekanies.com (Luke Kanies) — Tue, 06 Mar 2018 00:00:00 +0000

It’s only safe to learn from true stories

Every startup has its founding myth, the story that it uses to help draw in and motivate employees, customers, and investors. In most cases, those myths were cultured years after the company’s founding, and bear little relationship to reality. When you dig deeply into a company’s true origins, what initially looked like the product of far-sighted genius deflates into a mix of insight and smart decisions meshed with a series of serendipitous events.

This gap between myth and reality in no way diminishes the achievement of these companies and their teams, but it collapses our ability to learn the true lessons from those who made it and those who did not. If we can shift our story-telling from creation myths to capturing the collisions actually necessary to germinate greatness, we can better recognize what it will take to support it next time. Even better, it will allow us to pull forth those organizations not lucky enough to get all the draws, enabling our ecosystem to address neglected founders attacking neglected markets.

As I was building Puppet, I assiduously sought founder stories, trying to understand what it really took to do what they did. Over time, this turned from a quest to build “Good to Great” for startups (which was silly anyway, given how stupid that book is) into a collection of more-true founding myths:

Facebook: From judging girls on the internet to billions of dollars
Google: Good thing Yahoo! didn’t want our search algorithm
Patagonia: No one else will pay me to surf (at least he actually admitted it)
Intel: We really hate our boss

I find these funny, but the true goal is to puncture the story people want you to buy so you can understand what it really took. When you do that, you find that yes, people had to work hard, they had to be smart, they had to be creative. Those are necessary, but as testified by the thousands of failed companies full of hard-working, smart, creative people, they aren’t sufficient.

When you can find true founding stories, such as Phil Knight’s excellent Shoe Dog, you gain critical insight that might help you build your own business better, but you also realize how much of building a great company is expertly riding the tide of luck and opportunity.

On first blush, there’s no problem with this, other than the ridiculous levels of delusion necessary to turn serendipitous opportunism into genius founding myths that manage not to include the lucky bits.

On reflection, though, erasing the role chance plays causes systemic problems throughout the startup world.

We’ve already seen that human nature abhors a vacuum, refusing to accept that people don’t always deserve their circumstances. Luck is obviously not the only contributor to a startup’s success, because how they play the hand they’re dealt is at least as important as the hand itself. But let’s not lie to ourselves about the role of randomness in a startup’s circumstances.

When we do, it limits our ability to understand what it really takes to make a great company. This is similar to the deep structural flaws within “Good to Great”: If you just ask the great companies what they did and try to do the same, you sound smart but have only made your readers dumber. I recommend The Halo Effect for a more complete discussion on how this business-book analysis of success fails its readers. You can fatally pierce the concept by focusing on one kind of failure:

“The Delusion of the Wrong End of the Stick - successful companies may do various things but that does not mean that doing those things will make you successful”

As I was trying to build Puppet, I found this discrepancy between the stories and the realities immensely frustrating. I was uninterested in being valorized for something I felt lucky to be doing, but these myths were a screen obscuring information I knew was valuable. My goal in studying my predecessors was to improve my own chance of success, but it’s impossible to learn from propaganda. Instead of a community of founders learning from each other, with each iteration being better than the next, you get cargo cult companies that manage to copy every part of a successful business except the parts that made it work.

As just one example, Google’s own data now shows that its vaunted hiring practices did not actually help, but a whole generation startups copied their worthless brain teasers and discriminatory ivy league requirements. For years, Google’s dominance was partially explained by their great hiring, but what happens when it turns out they weren’t actually better than anyone else? Nothing to see here, please move along. Let’s just start another round, this time copying Netflix and Amazon. Forgive me for thinking that Amazon’s success has more to do with their taking Walmart’s extractive business strategy to the web than on their use of internal APIs.

What I found again and again when I peeled these myths back was far more genius in how people responded to their circumstances than in how they were created. Oracle is a perfect example: Larry Ellison was smart enough to realize that IBM had invented this great new database concept but weren’t trying to sell it, so he took advantage of that to build it himself. You can bet that’s not how Oracle tells its founding story, but only once you know it can you see that Ellison’s true strength was pushing hard and fast enough to ensure that Oracle was the first one to market with this free idea. I don’t look up to Oracle’s founder, but you can bet I learned from that story.

Google is another good one: One of the best CS schools in the world bashes together two random guys, who then go on to invent something and get lucky enough to fail to sell it. What you can learn from Google looks pretty different once you know that. Again, it does not diminish what they did after that failure, but it turns their stories of manifest destiny into a more true telling of wandering any icy landscape looking for safety.

When they say history is written by the victors, they mean both that only the the stories of the winners end up getting recorded, but also that the stories themselves get morphed, corrupted, to present those winners as just and deserving. That corruption is as pervasive in the world of startups as it is in the wider world.

There is tremendous value in understanding the real stories behind the great successes. Good luck getting companies and founders to tell them.

Apple Has a Focus Problem

luke@lukekanies.com (Luke Kanies) — Thu, 01 Mar 2018 00:00:00 +0000

But it’s not what you think

The iPad has made great strides in the last few years toward being a full-time computing platform. While many still cry that it’s just not very useful yet, others are out there using it as their only computer, or have at least shifted significant usage from desktops and laptops to it. I have been traveling at least a third of the time over the last few years, and the iPad is my only companion on the majority of those trips. It is by far my favorite computer, but it has one glaring defect.

Obviously, the heart of the iPad is its touch interface. The direct interaction is exactly what makes it such a joy to use for so much of it can do. However, even Apple has finally acknowledged that a keyboard is a necessary companion for many iPad uses. While their keyboard has some issues (or rather, their keyboard connection technology does), the overall experience is quite nice. Except for one little detail.

Unlike touch, keyboards are inherently targeted. While touch is powerful specifically because of your ability to directly manipulate the software you’re using, keyboards must first be pointed at a place that needs text. They need focus. And here’s where the iPad falls down.

It has no concept of focus. Or rather, it obviously does, but its designers are in denial about it. Keyboard focus is littered throughout the platform, from the presence of a cursor when inputting text, to the software keyboard auto-hiding when no text field is in use. When you’re producing text, this generally works pretty well.

But the keyboard is used for far more than typing. Whether it’s command-tabbing between applications or using shortcuts within them, the keyboard is a critical control device. And it just does not work right on the iPad.

Honestly, it does not work that well on the mac these days, either. Apple’s Mail application can’t seem to figure out how to pass focus between emails, especially when deleting them, and there are plenty of other situations where focus within a window - as opposed to between them - can neither be perceived nor controlled.

But because of its orientation around touch, the iPad is much worse. The vast majority of the time that I want to, say, delete an email, the delete key just literally does nothing. I can even touch the email I want to delete to “ensure” it’s focused, and yet still the keyboard is useless. I have to resort to touch for interacting with applications the vast majority of the time. Many iPad-specific apps now advertise keyboard shortcuts, but they’re useless. I mean, sometimes they work. But that’s not good enough when you’re trying to get something done; we learn, eventually, to do what’s consistent, rather than what’s fastest when it works but often fails.

I have so many memories of using my keyboard to tell some app to do something, and just starting at the iPad until I realize nothing is going to happen. I tap around, hoping to tell it, “start here”, but it’s usually no use. My expectations collapse, and I feel crippled, reduced to the level of those who just click around their GUIS. It’s not wrong, but it can be so much better.

I follow every conversation I can find about the iPad as a productivity platform. I’m deeply interested in the thoughts of people who are bought into it, such as Federico Viticci, so I am cognizant of the general thread of how this is progressing. As so often happens to me, I seem to be the only person concerned about this problem. Here are all of these people talking and writing about the iPad as a general purpose computing platform, yet they don’t mention this problem of the inconsistency and invisibility of focus at all. Do they just not use keyboard shortcuts? That’s not possible, right?

And don’t tell me it’s my iPad. I’ve had literally every version ever made (I currently have both sizes of the iPad Pro), and every few iterations I do a clean install. I’ve tried every variety of keyboard, from Apple’s to Logitech’s to a $15 piece of junk I bought at Brookstone at the airport one time because I managed to leave mine at home. I’ve changed every variable. The only explanation seems to be that others just don’t care about this.

I’d also like to see people rallying for Apple to shift the default orientation of the iPad Pro to landscape, because the keyboard is so central to its use, along with an automatic disabling of the rotation lock when the keyboard is connected, but these are minor compared to the core utility of a keyboard.

To me, one of the central reasons to want a keyboard, one of the primary purposes of the keyboard on my computer, is to control the computer. At that, the iPad is currently failing miserably, and it deserves better.

I fear that this can only be fixed by introducing completely new design concepts to the iPad. Obviously the OS understands focus, but the design team has worked hard not to ever indicate that to you. That has meant application developers have not bothered to manage it effectively, and has trained users to rely on touch rather than the keyboard.

While Apple is a design powerhouse, they’re also into brutalist design, always opting for less, always preferring to forego a capability if they can’t make it perfect. This causes me to despair that they’ll make material strides on this any time soon.

I’d love to be proven wrong, but for Apple to start caring about this, its customers need to first.

What’s your story? Do you just not use keyboard shortcuts? Do they work great for you? Or they’re totally broken, but the other broken stuff is just so much more important you haven’t mentioned them yet?

My Computers Are All Broken

luke@lukekanies.com (Luke Kanies) — Mon, 26 Feb 2018 00:00:00 +0000

Software’s focus on world-dominance has crossed with my incessant tinkering to result in a computing environment that is failing me utterly.

I’ve tried everything, and it still doesn’t work.

My first computer was from basically the worst era Apple has ever produced, starting with MacOs 7.6.1 and finally quitting around MacOs 9, switching to BeOS. While I was using these for fun, I was learning Solaris (and AIX, and HP-UX, and FreeBSD, and Debian) for work. I know some are frustrated that the Mac has lost its spacial finder, but I’m frustrated when I have to touch my mouse, because I spent years in a fine-tuned X-Windows interface that allowed me to do essentially everything from the keyboard. It was only marginally graphical; all of the windows except the browser were different kinds of text interfaces, from the terminal to vim to irc. I controlled everything with a Sun Type V keyboard, which relegated the caps lock and backslash keys to some far away corner like God intended, and gave prominence to control, escape, and delete, which matter quite a bit more. I honestly have no idea what mouse I used for the first ten or fifteen years; I don’t normally care about them, so I don’t normally notice them.

As I gradually switched from a sysadmin-turned-developer to a CEO, my computing needs changed dramatically. I spent all my life in email, calendar, and chat rooms, instead of text windows (notice they’re all still text, though). I did not even have a desktop computer for years, because a laptop was a better compromise.

As the iPad got more powerful, though, and Apple’s iMac computers turned from lickable toys into their most powerful computers, I moved most of my computing from laptops up to desktops or down to tablets. For a little while, all was fine, because I still wasn’t spending much time on the computer - as a CEO, most of my time was spent directly communicating with people, either in meetings or via email and chat. Being present means not being on your stupid devices. That was my computing experience.

Once I left my CEO role, I shrugged. I changed a few things (started writing in Ulysses, for example) but basically kept the tools and practices I had.

It’s become clear now that I have a solid decade of debt that’s built up in how I use my computers.

I really hate it.

Some of it is obviously just bugs. Or something. The keyboard (a KÜL tenkeyless with some kind of Cherry MX switches) and mouse (some large Logitech thing) just don’t work most of the time. The keyboard has to be unplugged and plugged back in 90% of the time the computer goes to sleep, and the mouse icon just does not seem to care about my needs, even after swapping mice, mousing platforms, hair shirts, and everything else I can think of (turns out that moving the mouse’s wireless adapter from a USB hub to the desktop might have fixed the mouse).

Beyond that, the software is out to get me.

Am I seriously the only person in the world who cares about keyboard focus?

I just deleted an email in Apple’s Mail.app on my desktop (running the latest os and patches, but this problem has persisted for as long as I’ve used the app), and I literally have no idea where the focus went. I hit delete, the email goes away; I hit delete again, and literally nothing happens. An email is highlighted, but, oh, I see, it’s a gray highlight instead of a blue one. I click on it, now it’s blue, and suddenly delete works.

I have essentially the same problem on my iPad (which I work on at least as much as my desktop). My only feature request for the iPad is to make keyboard focus predictable and functional. You can be scrolling through emails with the arrow key, and suddenly it will just stop working. Delete an email, no idea where focus is. I don’t even know how to tell where the focus is.

I’m in this insane world where I can feel utterly defeated by the need to click on an email to delete it, but if I zoom out, just about every other part of my computing experience causes similar frustration. I’m apparently the only person in the world who has quality studio monitors on my desk, based on how much everyone is freaking out over the HomePod price. I have separate audio installations in 7 parts of my house, and the HomePod in my bathroom is the cheapest one, beating the thirty year old (purchased used, recently) NAD and M&K kit in my bedroom by about $100. Nothing can cause you to lose hope that your needs will be met like the entire internet agreeing your needs don’t exist.

I don’t consider myself an audiophile, but I know enough to know that decent speakers start arriving at around $300 (each, not a pair), rather than topping out there. I never bought into Sonos because that required my believing they could deliver a good speaker, amplifier, and software experience for the price of a single decent speaker. Oh, and I had to join their walled garden; I’m willing to consider that, but it’s got to be worth it, and it never was for them.

So now most rooms in my house have audio streamed to them from an unsupported device that is going to become obsolete any day now.

Getting back to computers, it just could not be more clear to me that I’m in the shitty middle ground of the computer world.

I’m not a specialist any more. When I was a sysadmin, I was a specialist and I could build my computing environment to match that. (Although good luck finding specialized sysadmin hardware these days.) When I was a developer, I was a specialist, and my computing showed it.

Now I do what everyone else does: I email, browse, handle my calendar, chat a bit. My writing is a touch specialist, but not really; I’m using a specialist tool that’s great for writing books, but I’m just producing blog posts instead.

Even though I’m not a specialist, I’m still weird. I know that I’m using all of my tools differently than most of you are. I know we all think we’re special, but I’ve been around enough to know I am. Not in a good way, just in a “why are you doing that?” way.

Take my calendar. I’ve now twice written tools to tell me whether I’m meeting my goals in terms of how I spend my time. Sure, you have some sort of tomato timer to remind you to stand up or something. Amateur. My calendar should be a statement of my priorities, of how I will and do spend my time, and I want to hold myself accountable to my goals. I appear to be the only person who wants this, based on the searching I’ve done. Thankfully Google Calendar has APIs available, but why should I have to write this?

I have tried every email client I can find, but they’re all written for someone else. They all seem to offer, “How can I help you do email without email?” I don’t want that. I want the vim of email clients. I want the Photoshop of email clients. Can you imagine telling a graphic designer that you want to help them make graphics without making graphics? It’s stupid. They’re designers. They design graphics. I’m a communicator. I communicate. I read and write. A lot. Make a client that’s better for that. But nope. Instead you have the modern equivalent of a lickable interface that still can’t do inline reply and only has 5 keyboard shortcuts. _BZZZT_DELETED!

Some of it is just stupid. I have LED strips mounted to the back of my monitor, so I can get ambient lighting while I work. It’s actually an awesome feature, and I totally recommend it, but it’s a bit of a mess of wires with a ridiculous interface (a switch that keeps falling off my desk). I get not everyone has their monitor against a wall, but this seems so great it should ship by default. Can I just get all the LEDs you want in my keyboard moved back there? And, of course, I want it all connected to the computer so I can control it via software. Instead I’m wiring it all together myself and hoping 12V can’t catch my desk on fire. Yay.

I wish it was just that I’m a curmudgeon, that I can’t give up the old ways, but the truth is I like my iPad more than any other computing device I’ve ever owned, and honestly, I always hated the old ways. I’ve been hating software for as long as I’ve used it, and I’m proud I’ve been able to keep my edge as my career and the world it’s in has changed. I hated X-Windows. I really, really hated MacOS. I loved BeOS, but honestly, I held it to a very low standard. I loved every part of Solaris except the parts that actually existed or that I ever used, and I quit using it just when it stopped sucking quite so much (god, remember having to use Veritas to get decent clustering? Even worse, remember Disksuite?).

So it’s not that I miss the old days. I want to live in a different universe. I want a different physics model for our software world.

I know I can’t have it. I know I won’t get there.

But I’m an optimist. I’ll keep fighting.

Software At the Coal Face

luke@lukekanies.com (Luke Kanies) — Fri, 23 Feb 2018 00:00:00 +0000

Software should be for the people who do the work

I’m not a technologist. I’m a software person, but not in the way people mean when they say that. I believe in the power of software to improve lives in big and small ways, and I have a hard time imagining doing much except through software.

I’m less fond of the software industry itself. I think it is too slow at solving problems that matter to people, too myopic to see how much it could really do.

I ran a software automation company for twelve years, and when I explained it to executives or salespeople, they would respond, “Oh, so you can fire sysadmins!” (Draw your own conclusions as to why these are the ones who consistently said this.)

In fact, our strategy was the exact opposite: I set out to turn sysadmins from tactical tools into strategic assets, to make the individuals more capable, and thus more valuable and harder to fire.

It was always easy to show my strategy was the right one: Let’s say I can produce software that can either reduce cost (fire some part of your team) or improve service quality (help that team do better work), which do you pick?

Nearly every time, people pick a higher service quality. “Wait, that’s an option?”, they would say. (The rare exceptions to this response usually came from organizations I did not want as customers.)

Software sucks. It really, really sucks. It’s so bad that when people look at their software investments, and especially the infrastructure layer my previous company lives at, they really only know how to talk about cost. Sure, they know the software is critical, they can say how many nines they have in uptime, or what their NPS score is, but they can’t measure quality in the way, say, a car maker or theme park would. Turns out, though, it’s easy as all get out to talk about cost. So, people naturally gravitate from the stuff that matters into the stuff they can measure. It always reminds me of an old joke:

A policeman sees a drunk man searching for something under a streetlight and asks what the drunk has lost. He says he lost his keys and they both look under the streetlight together. After a few minutes the policeman asks if he is sure he lost them here, and the drunk replies, no, and that he lost them in the park. The policeman asks why he is searching here, and the drunk replies, “this is where the light is”.

It might not matter, but it sure is easy.

You could argue that what Puppet did was weird, was special; that I found a seam of critical work that was undervalued, incorrectly measured, and ripe for both automation and an increase in human capital.

I don’t think sysadmins are that special.

There’s been this wicked, stupid, and brutal trend over the last few decades to devalue people. I don’t just mean, to replace people with automation; I mean the practice of reducing the value of individuals in service to financial strategy. It might be my age, but I assume this all started in the 1980s when corporations were compensated for having fewer costs on the books (which also led to idiocy like building an office tower, selling it, then leasing it back; some realtor makes bank, and your stock goes up because your balance sheet looks better according to the skewed spreadsheets of some hedge fund manager). The claim of many companies that their people are their greatest asset is contradicted by their behavior.

This becomes more true as companies get bigger. Most large corporations have spent decades finding ways to rely less on their people, and then use the results to demonstrate the people deserved it. Under-train them, then over-supervise them because they don’t have the skills. Don’t give them any power, then consider them easily replaceable because they can only do small things on their own. Refuse to invest in better tooling, then complain about their productivity.

I have a different perspective. You might might think I’m antiquated, or silly, or just naive. Meh.

My perspective is that people have always mattered, and that they always will.

My perspective is that there will always, forever, to be money made by making people more valuable.

Further, just as a nice bonus, I believe that the things that make people more valuable are generally congruent with the things that make them happier, which means that success for me helps the company and the individuals both financially and personally.

Don’t worry about people stealing an idea. If it’s original, you will have to ram it down their throats. - Howard H. Aiken

Considering that it’s this perspective that’s led to me to what success I’ve seen in life, and I’ve done enough work now to realize it’s also the only thing that I care about enough to put another decade into, it’s worth considering hiding this little gem, this little kernel of wisdom that others can’t seem to spot. I’m not worried. At the least, it goes against decades of corporate training: “People don’t matter, you should replace them, expect them to fail, they’re just cogs”. That kind of mental conditioning is hard to resist, especially when it’s imprinted on our financial system itself.

Beyond that, it just sounds too nice for others to see its value. Modern finance inherently distrusts anything that’s good for people, because they figure if you can do this thing and help people, you’ve got to be able to make more money by doing that thing and not helping people, right? Right?

No. In many cases, the thing that makes it valuable is exactly that it helps people. If anything, you could argue the entire software industry is about helping people spend more time on what makes them special, rather than helping people do something they could not do before.

Photoshop didn’t enable people to make drawings they could not have before; if anything, in many cases it’s less functional than using pens and pencils. It just enabled people to be far more efficient with the time they spent.

The difference between a great editor for coding and a bad one is not that you write better code with a great one, it’s that you can write good code that much faster and thus get a lot more high quality work done.

Often, the difference in speed is so great that the quality of work is actually dramatically better, but it’s a result of the user having far more time to spend on the problem, rather than the software itself directly improving the work.

It’s not a coincidence that boring, low-value work is easy to automate, or that people enjoy their jobs more when that work goes away. (Of course, this is assuming the job sticks around; in too many cases we use this as an excuse to fire someone rather than promote them.)

This was exactly Puppet’s goal.

Spend less time firefighting and doing menial work, and more time shipping great software.

I bet you can think of an industry or two whose people could stand to spend less time doing menial work, and more time on the things that matter.

I am not naïve enough think that every role a human plays today could be improved by better productivity tools; some roles become obsolete over time (not a lot of chimney sweeps these days), they really are just menial work or in an industry that cannot remain relevant. (Although, even in those cases I’d argue that both the people and the industries would be better off trying to find a way to work together on the transition, rather than the companies seeing the people as a sacrifice to the gods of productivity.) At the level of industry rather than individual roles, though, everything could be better through this kind of investment.

And in the end, I don’t have to believe every industry, every role is better off.

I just have to be able to find enough people, companies, and industries that are better off that I can keep doing great work.

And that’s what I plan on doing.

Strategy Is Culture

luke@lukekanies.com (Luke Kanies) — Thu, 22 Feb 2018 00:00:00 +0000

How you work determines your destiny

Peter Drucker famously said, “Culture eats strategy for breakfast”. This is often interpreted as culture being more important than strategy. These might not even be his words, which makes it hard to know his thoughts, but having built a company to almost 500 people, it’s obvious to me that culture isn’t more important than strategy, it is strategy.

I am confident he knew this. He worked with the Japanese manufacturing companies in developing their culture of kaizen, which helped them to dominate the automobile manufacturing world, and their practices have gone on to fundamentally change manufacturing as an industry.

Your strategy is not what you’re trying to do (those are your goals), but rather how you plan to do it, and your culture determines how you work. Pick any great, differentiated strategy, and you’ll see that how it translates the company culture is what determines its efficacy. We tend to think of culture as being about how people feel, or how they treat each other, but that’s a bare shadow of its importance.

Southwest is an amazing airline. In an industry with a long history of losing money, they’ve managed to make money year after year. How? Their strategy is simple: Be the lowest cost carrier. This isn’t something that the management says to the team who then try to interpret it; it shows up in every decision made by everyone in the company. It’s baked into the culture. If it weren’t, costs would creep in at every level of the organization. They could not be the lowest cost carrier without a culture of parsimony at every layer of the company. You will not be a culture fit at Southwest if you can’t be cheap.

Toyota is legendary for helping to drive a revolution in manufacturing, and their success is based on tight integration between company strategy and behavior at the front line. Many of their practices work against human nature, such as their “Five Whys” tactic, which seeks root causes for quality issues by refusing to blame individuals. Their culture is so unique that one of its standout features is how reliant they are on training and mentoring, from the front-line worker to top executives. Managers get promoted based on their ability to train their teams up, not just for driving results. Toyota understands its success is reliant on its management chain to connect company strategy to front-line execution, and it invests accordingly.

Atlassian has built an amazing business, not by being better at selling, but by ensuring the customer can sell themselves. The entire company maintains the cultural discipline of removing barriers to a sale, of asking why a customer needed help, hit a roadblock, or didn’t buy. This sounds easy, but it’s fundamentally hard, and more importantly it’s directly in conflict with the sales culture of modern software companies. You have to choose whether you care more about this deal or all deals, and Atlassian’s rare choice, and how that has permeated their culture, is a big part of why they’ve done so well. I expect Atlassian has lost countless great people who could not make that shift.

These companies demonstrate the inseparability of culture and strategy. Your strategy is how your company plans to win, and your culture is how people individually behave in alignment with it.

Some might argue that the above are the company missions, not their strategies, but they’re very different. Toyota’s mission is to build great cars, and a culture of kaizen is how they do it. Southwest’s mission is probably something like “Enable access to air travel to all”, and being low-cost is how they do that. Atlassian’s mission is clearly around enabling collaboration between teams, which they support by making their products easy to acquire.

If you’ve got competition, then your strategy needs to specify how, exactly, you’ll beat those competitors. You and your competition can have the exact same mission, but by definition your strategy needs to be different from theirs - you both have the same goal of taking the market, but you necessarily will be approaching it differently. If you don’t have competition, your strategy needs to clarify how you’ll win in a market where no one has thrived before. Neither of these is a simple question of setting goals; it’s about clearly stating how you’ll accomplish them.

Too often, strategies are placed on a pedestal, gesticulated at from afar and never allowed to get dirty, when a strategy’s value is entirely determined by how it hits the ground. Napoleon was one of history’s best military strategists, and he knew the importance of how it translated to individual soldiers. When he gave orders, he demanded they be repeated back word for word, and would do it again until they were right. He knew a strategy’s value was determined where it met the enemy, not when it was laid out in the command tent.

Contrary to what you might hear, I don’t think I’ve ever met a founder who didn’t have a strategy, and usually a pretty good one. In contrast, I have yet to meet an early-stage founder who can explain how that strategy will translate on the ground, or who invested hours every week in ensuring that his or her team was operating according to it. Even basic things like having better usability are hand-wavy at best, relying on constant input from founders rather than permeating the organization’s culture.

Simon Sinek has helped lead the charge in the value of ‘why’ as a force for motivation and alignment. Your strategy for how you plan to win is just as important, and is much harder to align a team around because it necessarily involves daily discipline. It’s not enough to have a great strategy or a great culture; they have to be one and the same.

Your culture is how your strategy is executed, and you’ve got to put in the time to make it work.

If You Take Venture Capital, You’re Forcing Your Company To Exit.

luke@lukekanies.com (Luke Kanies) — Tue, 20 Feb 2018 00:00:00 +0000

To understand VC, you must understand the consequences of how they make money for their investors. Part 2 of a series.

Originally published on NewCo Shift

Modern venture capital is obviously successful, as demonstrated by the fact that five of the world’s six largest companies were funded by it. However, success is as much about what you say ‘no’ to as what you say ‘yes’ to, and venture capital is no different. In addition to delivering massive collateral damage in the course of its work, the current model rejects all ideas that do not fit within its narrow definition of suitable.

The primary contributor to this wholesale rejection is how VC delivers returns, so to understand why it’s broken we must understand how it works. In this article we’ll go deep on how VCs get their money, how they turn that into more money, and what that all means in terms of what ideas they can and will back. Note that we’re focusing here on the ideas not the people; the structural biases against women and people of color will be discussed in later essays (but it’s worth recognizing that they’re just as baked into the model). Ross Beard’s The Innovation Blind Spot goes into great detail on this topic.

Venture capital firms generally have managers and limited partners; the managers are the people we think of as the investors (they sign the checks), and the limited partners are the investors in the firms; they’re “limited” in the sense that they have ownership but no real control. They don’t actually invest in firms; they invest in an individual fund, and all of the roles are built around the fund, not the firm. This is partially why you might seen an investor leave a firm but stay involved in investments from the old firm: the investor is still on that fund even if they’re not at the firm.

Most limited partners are very large financial institutions, like CalPERS, and they work with venture capital as part of a diversified investment strategy. They have pockets of money in all kinds of places, and VC is added in to ensure they have some high risk/high reward investments. These don’t necessarily even deliver better returns (and in general, VC as an asset class does not do that well), it’s there to get the right mix of risk in the portfolio. In most cases, the LPs are represented by people who would not fit in at a venture firm, because they’re usually finance people at governmental institutions.

A fund is raised by investors (“managing partners”, in this context) seeking money from high net worth individuals, institutions, and anyone else with a lot of money lying around. Money is committed for the life of the fund; except in rare cases there is only one way for an investor to get the money back.

One of the strange things about these funds is not just that they are planned to be locked into a fund for a long time, but it can be awkward if they aren’t. Limited partners invest with VCs as a means of putting money to work over something like a ten year period. If the money all gets returned quickly because of an exit, it throws off the spreadsheets and they quickly have to find somewhere else to put the money. This sounds silly, but it does have a real impact.

Venture capitalists then take this money, and use it to buy stock from startups. So now, the fund holds a bunch of stock instead of a bunch of money. Crucially, this stock is all in private companies, which means it’s generally illiquid (i.e., you can’t easily exchange it for cash). It’s also usually preferred stock, which means the investors get a few extra terms around control and how cash is distributed if there’s a below-value exit.

If this were a normal fund, there would be plenty of ways to make money, and the investors could deliver returns however they wanted; they could rely on growth, dividends, sales, or anything else. However, VC funds are limited partnerships with strict rules about what can be done with the money. No matter where you are in a fund cycle, if a company gets sold for cash, you have to distribute that cash to your investors (keeping 20% for yourself, of course). You can’t reinvest it in another company. (This is only generally true; firms that don’t have this restriction are called evergreen funds, and are usually funded by a single institution or family.)

This distribution on an exit is the primary mechanism for VCs to return capital to their investors. The other way is for a company to go public. This is a weirder one — it’s discussed as an exit, because it allows investors to return capital to their LPs, but it’s not a sale of the company. The difference is that the stock is now liquid, which means it’s basically equivalent to cash; the VCs give distribute the now-public shares to their LPs, who can now all trade it in for cash whenever they want.

Ironically, distributing shares to LPs is a big risk to the company — if 50% of a company’s stock is owned by investors, and they distribute all of that stock to their LPs the day a company’s lockup period ends, what do you think the LPs would do? Well, they’re not experts in tech, or high growth companies, and more importantly, this stock doesn’t fulfill the same needs as the VC fund did in their asset allocation, so they sell it. Of course. And what happens to a newly public company who finds that 50% of its shares are suddenly sold on the public market? The stock gets hammered, because a huge upsurge in supply means an equivalent drop in price.

That’s why VCs distribute shares over a broader period of time, usually 18-24 months. They have some flexibility in how this is handled so they can protect these newly-public companies.

Ok, now you understand how it all works — how venture capitalists get money, make money, and then give it back to their investors in turn. Why does that matter?

It matters because there are only two ways for a VC-backed startup to be a success for its investors: Go public or get bought. As the CEO of Puppet, I always said any company has four options: Go broke, go public, get bought, or stay private indefinitely. If you take VC money, that last option is off the table.

It’s worth saying again: You take VC, you are committing to getting bought, going public, or going broke.

Crucially, that means that investors must push you into one of those outcomes. The reason they deride private businesses that generate cash isn’t because they’re bad businesses, it’s because they’re structurally incapable of profiting off of them. Their system is limited to valuing sales or IPOs; nothing else can have value to them, because nothing else allows them to make money.

This means that if you’ve got a great company that’s taken some VC but is at real risk of settling into a mere 20% growth rate with a sight to profitability but only making, say, $30m a year, they’re going to push you out of that comfort zone. They have to. They’ll ask you to raise a “growth” round so you can “really scale this thing”, or they’ll try to sell the company. If that doesn’t work, they’ll just fire you and put someone in place who will do it for them. It’s not because they’re evil, it’s because their contracts essentially require it. They can’t return the stock of a private company to their LPs, so what choice do they have?

Now that we understand how investor behavior is driven by how capital is returned to investors, let’s discuss what it means to the technology startup ecosystem as a whole. (There are VCs for things outside of tech, but the asset class was basically invented for technology, and that’s where it is centered.)

If you’re seeking funding for your technology company, you essentially have to promise that you can and will sell your company for an outsized return, or that you can and will take it public. In reality, almost no one invests with the expectation of a sale; they’re all betting on an IPO, recognizing that a sale is a good second option. It doesn’t matter if you can generate a ton of profit; they have no use for that. In fact, it might get awkward if you started distributing dividends.

This has two big consequences. The first, of course, is that companies that don’t have a realistic shot of going public can’t get venture capital. This is a striking constraint, given how much of our economy consists of small, profit-generating businesses that generate jobs and cash locally, whereas the ranks of public companies that distribute returns only to the investment class have been shrinking for decades. The story they’ll tell you is that only those really high-growth companies “need” VC money, but it’s much simpler than that: Their business model doesn’t work if your company doesn’t sell or go public.

Bank loans do ok at providing funding for low-risk actions by mature companies, and VC does well at funding high-risk companies with the chance to be huge, but there’s a huge gap in the middle that struggles to get any funding. (Both of these funding mechanisms in the US also suffer from being overwhelmingly biased toward only funding white men, but that’s a different essay.) Medium-risk companies often do need funding, but can’t get it, which in many cases means the businesses either don’t exist or end up much smaller than they could be.

The second major consequence is that a lot of companies are able to convince themselves, and thus investors, that they could get big enough to go public. Yes, this is sometimes true, but in so many cases it is instead a lie that both parties tell in order to get the funding done. If you love your company, and the only way to keep it alive is to promise to keep growing, you will. You understand the risks, but they’re better than just letting your company die.

In too many cases, this absolute demand for continued growth is exactly what kills companies. They never learn the operating discipline necessary to generate cash (which, in the end, actually still is king), and they get too big to sustain themselves. At some point, the lie gets out, they can’t get more funding, the fundamental unsoundness of their business model becomes clear, and the whole thing deflates.

When you hear a VC say you should focus more on growth than cash, what they’re saying is, you should worry more about my ability to return capital to my investors than your ability to still have a company in a few years. It might be that growth is the right thing to invest in, but it isn’t automatically the right thing, and it’s at least fair to say that the investor is not a neutral party in this recommendation.

So now we see that so much of what we find poisonous in the world of venture capital is actually the result of how returns are distributed to investors. The growth-at-all-costs mentality, the huge amount of dead companies, pushing employees to work to the bone until you get an exit, and much more can be laid at the feet of this simple constraint.

I don’t know if there is an alternative model that will work in the world of high-risk tech startups, but I do know there are plenty of other investment models that are able to deliver returns without introducing this kind of dysfunction. Conglomerates like Berkshire Hathaway are able to own significant chunks — or even the entirety — of companies and deliver great returns whether via growth, dividends, or anything else. This provides them the flexibility to let their portfolio companies choose their own best means of returning capital to investors. Coincidentally, Berkshire Hathaway is the one non-VC-backed company in that list of six largest companies.

This essay series is an attempt to capture what I’m learning as I’m looking for a new way to invest in great startups. I think it’s possible to build an investment model that directly attacks the weaknesses of VC; success in this quest would mean both huge returns for whoever cracks it, but also a sudden increase in new companies with completely different promises and risk profiles.

One Investor Isn’t Enough

luke@lukekanies.com (Luke Kanies) — Tue, 20 Feb 2018 00:00:00 +0000

The success of companies and founders in modern venture-backed startups is highly reliant on peer validation of investor decisions. Part 4 in a series.

Originally published on NewCo Shift.

Say you’re an entrepreneur building something new and different, and you know you need capital. After pitching up and down Sand Hill Road (and all over South Park), you’ve finally found a believer, someone who sees what you’re trying to do and thinks you and your team are the ones to do it. Great! Now you can focus on building your business, right?

Nope. Get used to more of the same. You probably raised just enough to get to your next milestone, not enough to get to self-sustaining profitability, which means you’ll be raising again soon. After all, on average startups raise more than three rounds of funding. I know what you’re thinking: But this investor is a true believer, and given how hard it was to convince others, they’ll sign up for the next round instead.

Nope. It does happen, but it’s rare. In general, every round you raise has to be led by a new investor. Part of this is about dollars: Your seed-stage investor writes $500k checks out of a $50m fund, but your A-round investor writes $5-10m checks out of a $300m fund. That seed investor will participate in the larger round (doing what’s called their pro rata, to keep their ownership share the same), but if they led the round they’d burn through their fund too quickly and would not be able to lead enough investments to make their model work.

Even if dollars aren’t the restriction on your first investor leading later rounds, you’ll still likely find yourself pounding the pavement again. Imagine you’re an investor, and you see a peer investor leads follow-on rounds for most of their portfolio companies. One of those companies comes knocking on your door asking you to invest, and of course your natural question is: Why isn’t your existing investor leading? There’s no good answer to that question.

You can’t say, “Well, they’re a bad investor, and I really need new blood”, for pretty obvious reasons. Even if it’s true, badmouthing existing investors will never get you new ones. You can’t say, “Well, they like us, but even though they lead follow-on rounds in 90% of their companies, they don’t like us enough to lead one for us.” You’ve just told this new investor that you’re in the bottom 10% of your investor’s portfolio. Now there’s no chance they’re going to invest. If the investor that knows you really really well doesn’t want to write a check, no one else will.

To prevent this problem, the industry has the habit of not leading follow-on rounds. Again, not that it never happens, but it can’t be the common pattern, because the company that breaks it gets a black mark. I’ve had many investors (including those invested in Puppet, the company I founded) tell me they follow this habit religiously, for exactly this reason. “Nope, as much as I like you, you’re going to have to get the money from someone else.”

Out you go.

Thankfully, venture investors recognize the downsides of this and build deep networks of firms and individuals who frequently work together. There are even later-stage firms who specialize in following specific investors whose track record they trust. But while this pattern was developed for good reasons, it also has downsides that no amount of networking or help can compensate for.

First, of course, it means most CEOs spend a huge percentage of their time either directly raising money or doing the work necessary to do so later. You might not have wanted to become best friends with tens of investors, but if you’re taking venture capital, that’s your job now. Given that investors are professional meeting-takers, they’ve got time to meet for coffee any time, so this can be hugely time consuming. Then when it comes time to actually raise a round, you should expect it to consume your life for at least three months. And that’s the success case.

This time sink is pretty bad if you live near all the investors you need to meet, but what if it’s a flight to the bay area instead of just a drive? Oh, if you’re one of the top companies they’ll come to you, but if you’re not, it’s one more way you have to work harder than the ones they love. It was only in our late-stage rounds we had luck getting investors to come to us, and we were only in Portland, an hour and a half flight away. I can’t imagine trying to raise money in a place that shudder needs a connecting flight to get to. I nearly killed myself in a rented PT Cruiser (the first available car at SFO) trying not to be late to an investor meeting, and of course, he passed on us anyway because I could not convince/did not want his buddy to join us as COO.

This all adds up to a massive tax on the companies that do succeed, where CEOs become experts in fundraising rather than experts in building great companies, which is, of course, stupid. But it has a much worse impact on who and what can get funding in the first place.

Again, put yourself in the head of an investor. You look at tens of potential investments a day, and you have far more opportunities than time or money, so you have your pick of what to invest in. On the one hand you’ve got a woman or a person of color pitching a company that sells to markets they deeply understand, maybe something more focused on customers who look like them. On the other hand, you’ve got a Harvard-educated CS grad who’s found another great use for AI in the cloud.

What we want is for the decision to be made based on what’s the best investment, who’s the best founder, but it’s not. It’s obviously not. If it were, you wouldn’t see such rank discrimination in the world of VC, where women and people of color are almost entirely excluded.

Instead, a key factor is whether the investor believes this person can raise another round. Note: It’s not whether the person actually can, because you don’t know that until you try it. It’s whether the investor thinks they can. And, of course, investors know that women and people of color don’t fit into the pattern of other investors, so they pre-discriminate in expectation that later investors would have anyway. I mean, why give someone $500k if the company won’t be able to raise another round anyway? You’ll lose all your money.

Like with all patterns, it’s as much about the company as it is about the founder. It’s not just about who gets money, it’s about what kinds of problems are worth solving, and what kinds of customers make good markets.

Silicon Valley has a well-known fondness for investing in products that solve the needs of white boys who just got out of college and are having to learn to live on their own, but less obvious is that this means they often consider other customers to be worthless. It is fantastically hard to convince an investor to back a product built for women, or people of color, or international buyers, when the investor is none of those things.

That is, it’s not just about investing in people who are different — it’s that their ideas are different, the problems they care about are different, and the markets they want to attack are different.

In a world where you’re taking risks, where you’re actually focused on brilliant founders in big markets, those differences would be positives, they’d be signs you can do something ground-breaking. But when that world requires multiple rounds of belief, where failure at any round destroys your company, suddenly those differences become reasons for people to say no, for companies not to get funding, for founders not to get support.

There are some firms out there, like K9 Ventures, who make these bets anyway and recognize that it turns their job into finding follow-on rounds for existing investments rather than just finding new companies. Too many investors either don’t see the consequences of this pattern, or preemptively admit defeat and just don’t even consider investing in a company that they are concerned couldn’t get another round.

Once again we see how a key aspect of venture, one that exists for good reasons, has pernicious consequences that help to explain how the world of venture works today, in all its glory and misery.

There’s no obvious fix to the problem, as either an investor or an entrepreneur, if you truly do need capital to grow but you don’t fit the pattern. One of your best defenses is to focus on profitability first, so you don’t need those follow on rounds and the levels of approval required to make them happen, but that’s not possible for every firm, and even when it is it can result in heavy compromises on growth.

Thankfully, there are now firms out there focusing on founders who are women and people of color. These firms will help in multiple ways. First, of course, they’ll provide the direct funding that is not currently available to so many great founders and companies, but second, they’ll begin to build out those networks of social proof that will enable these companies to get as many rounds as they need, rather than just the ones they can provide.

We’re going to need a lot more firms like that to truly unlock the potential of venture capital, to bring world-changing solutions to those who can get the most benefit, wherever they are and whoever they are. I’m hopeful that the competition these new firms bring will change the behavior, and the opportunity, of the existing ones enough to make the difference, but what’s really going to shift behavior is when the companies invested in by these companies start to deliver outsized returns specifically because they don’t fit the pattern.

That’s what I’m looking forward to.

Unicorns Distract Us from a Graveyard

luke@lukekanies.com (Luke Kanies) — Tue, 20 Feb 2018 00:00:00 +0000

Venture capital’s reliance on unicorns provides cover for the huge failure rate of startups, and investors make no effort to reduce it. Part 5 of a series

Originally published on NewCo Shift.

Venture investing is fundamentally uncertain. You’re making big bets on people, ideas, and markets that might never work out, and there are more ways to fail than succeed. As a result, investing has to take into account the likely failure of many efforts. If your financial model assumes each of your investments will be a success, you will have a short career indeed.

Many investors have written about how they need some companies to win big in order to cover for other companies failing completely. As a simple example, Fred Wilson at Union Square Ventures tells his investors to expect 1/3 of his investments to fail, 1/3 to return their capital (which is also failure; they sell for a small enough amount that investors just get their money back, and in most cases the founders and employees get nothing), and 1/3 to “succeed”, where his definition of success is that they return 5-10x the original investment.

He says his actual record is a bit better than that, but like Warren Buffet, he’d apparently rather set achievable expectations.

Let’s use some concrete examples. Remembering that most companies raise more than three rounds of funding, and keeping in mind that investors usually get about 20% of your company through each of those first few rounds, here’s what needs to happen to deliver that 10x return:

Your seed round is $500k at a $2.5m pre-money valuation, so you have to sell for $25m dollars. The investor gets $5m, and founders split $20m.
Your A round is $5m at a $25m pre-money valuation. Now your company has to sell for $250m. Each investor gets $50m, and the founders split $150m.
Your B round is $15m at a $75m valuation. Your target exit price is now almost $750m. By this time the founders own less than 50% of the company, but hey, if you can exit at that price everyone is pretty happy. Notice also that while this is a solid 10x win for the last investor here, it’s delivering close to a 300x return for the first investors (not counting pro rata costs). It’s nice work if you can get it.

Beyond three rounds, investors usually have smaller return expectations (e.g., 3-5x) but also have a shorter time horizon. That growth round investment of $50m is only expected to turn into $150m or so, but it needs to do it in 3-5 years instead of 7-10. Tripling a $750m valuation ends up being pretty hard in any time horizon.

It’s worth noting that if the company sells for $20m after that B round, then the founders get nothing. According to the preference stack (where the later investors all have priority over earlier ones), even with the cleanest term sheet the B and A investors get all their money back, but the seed investor, founders, and employees get nothing. In practice, the buyer will usually negotiate something for the employees and founders — you rarely buy a company without wanting some kind of golden handcuffs on the people who work there — but it’s basically a pittance. You’ve always got to manage your downside, even while you build toward the upside.

Note how quickly the exit price for the company escalates as you raise money. Realistically, it’s only once you’re around a billion dollars in valuation that you can consider going public, so if you’re smaller than that your only choice is to sell the company.

This model helps to explain the industry fetish for unicorns. The returns you get from a billion dollar exit swamp all the failures. And if those unicorns hide a lot of ills, the really big ones overwhelm even the successes. WhatsApp returned $3b to Sequoia on around $60m invested for a 50x return, which means every other investment in the portfolio could have failed and they’d have still made a ton of money.

You can see how the unicorns make or break a firm. How does this affect how they treat the rest of their portfolio?

When you know that a small percent of your bets end up mattering, you don’t worry much about any individual one, and that plays out in the world of venture capital.

Obviously investors don’t actually ignore the other firms; after all, they don’t really know which ones will win big. Equally, though, there’s no evidence they care whether any given startup succeeds.

Of course, investors would say otherwise: They’d say they work incredibly hard to help their companies, they work massive hours, answer the phone late at night, etc. Sure. I mean, they don’t put in nearly as many hours as the founders they’re helping, or even as much as a typical financier does (just thinking of the hours bankers put in these days makes me shudder) but I do believe they work hard. I do have a couple of anecdotes that show it’s not as hard as they’d imply, though.

I had one investor tell me that he loved the transition from operator to investor because the lifestyle is so much better. Again, this is from an investor class that publicly derides “lifestyle” businesses that generate cash for its founders but don’t scale massively. When I asked him about the hypocrisy of him working 9-5 but demanding his founders put in crazy hours, he defended it as their needing to lead from the front. Guess that tells you where the investors aren’t.

I also know a great investor who left a top-tier firm because he said he could not spend any more time working three days a week and being paid for five. Pretty honorable, if you ask me.

But mostly, yes, I do think many investors work hard.I just don’t think the work they’re doing helps their companies much.

Let’s walk through a couple of obvious examples.

Given the high probability of failure of a given investment, you’d think that the industry would be great at reducing the risks for their companies and thus increasing the survival rate. Not so much. For example, many investors have told me that the most likely reason for a company to fail is the team. Ok. So what do they do to reduce the probability that a founding team will fall apart?

Ah… nothing. No coach for each founder, no coaching plan, not even a packet providing best practices. Nada.

Their explanation for this is pretty simple: Coaches are expensive, and the investor can’t afford to have them on staff because the measly 2% on their $300m fund just can’t support bringing on staff to help founders. They could have the company fund it, but then that’s less money going to build the company.

This is the highest risk to your investment, and you’re literally not willing to spend any money mitigating it? Further, you’re tacitly recommending that your founders also avoid this easy bit of risk mitigation? Huh. Ok.

Investors will also tell you that the most valuable resource at a company is the founder’s time, and he or she needs to be laser-focused on building the business. It’s obvious they don’t actually believe that.

We’ve already established that founders will spend about a quarter of their time fundraising, rather than building the company. You could argue that this is the most valuable use of their time, but that’s only true in the sense that it has to be done and there’s no one else to do it. Most founders suck at fundraising and are tortured by their need to focus on that rather than building their business. Investors do help a little with this, but not so much that it implies the founder’s time actually is a precious resource. There’s a pretty clear sink-or-swim attitude around fundraising, even though success at it has little to do with the ability to build and run a company.

You see this same disregard for the founder’s time when you look at what they end up spending it on.

There’s a vanishingly small part of any business that’s truly innovative — maybe some part of your market definition or your solution itself — and everything else you do is disappointingly similar to what every other founder ends up doing. Great, so investors have figured that out and as part of their investment they deliver a playbook that uses the collective intelligence of their portfolio to help founders avoid having to make all the rookie mistakes, right? Hah! Nope!

The best firms do enable founders to talk and work together, but it’s all ad-hoc, and let’s be honest, that’s pretty minimal help. Every founder is basically doing a random walk around the possible solution space for “how to build a great company”, taking on huge technical risk with untried platforms and experimenting with idiocy like holacracy rather than focusing on the most important parts of their business, the one or two bets that will make or break the whole thing.

It shows how little investors are willing to do to help founders mitigate the biggest risks in their business, thus improving its probability of survival. If they cared about their portfolio companies making it, they’d specialize in helping them navigate the different phases of the company, minimizing probability of failure at each phase and especially when transitioning.

So now we see that it’s not just that investors are focused on unicorns, but also that the failure rate that those unicorns cover for is just irrelevant to investors. They know most of you will fail (again, they expect 2/3 to at best return their capital, which is failure in their model and even then only accomplished by a fire sale of the company). Heck, if you don’t fail and instead just continue on being neither a big sale nor a failure, they’ll have to push you into one or the other category in order to close their fund.

As I found running a growth company, success hides many ills. One of the biggest problems in venture capital is how much they let the success of their unicorns hide their indifference to the rest of their companies. This fails their founders, their employees, and the whole market, for no reason other than that it’s easier this way.

I’m convinced that a firm that directly invested in reducing its failure rate would have as many unicorns, but would also have more positive returns throughout their portfolio, and in the midst of building more companies and making more money, they just might do a little good at the same time. That would be a nice change.

Venture Capital Is Built on Serendipity

luke@lukekanies.com (Luke Kanies) — Tue, 20 Feb 2018 00:00:00 +0000

Software has the potential to increase productivity as much as electrification or steam power did, but its impact is stunted by its reliance on random interactions. Part 6 of a series.

Originally published on NewCo Shift.

The venture capital ecosystem bills itself as a meritocratic miasma of genius, with smart founders getting smart money from smart investors. In reality, there is an overwhelming reliance on privileged people bumping into each other at just the right time. This serendipity has spawned some great companies:

Warby Parker was started because someone in an elite graduate program lost an expensive pair of glasses.
Apple was started by a couple of guys who met at a hobbyist group in the computer heartland.
Google’s founders met when one of them gave a tour to the other when he arrived at Stanford for a CS graduate program.

But how many great problems are being ignored because we didn’t get that lucky alignment of particles?

The remodeling industry is a perfect example. It’s an 83 billion dollar market, yet it’s only now starting to see software solutions. The industry itself bemoans neglect by the software industry. The article linked above has some impressive stats about how much waste they experience:

“…studies suggest 30 percent of the construction process is re-work, 60 percent of labor is wasted, and only ten percent of losses are due to wasted materials”

Shouldn’t there be companies fighting tooth and nail over that market? Shouldn’t there be tons of solutions out there, spending money like Uber and Blue Apron are to acquire new customers and take a cut of the productivity gains?

Yet I’m in the late-stages of having a garage built at my house, and as far as I can tell software was only used during design, not actual production. One of the contractors we considered seemed to be an Excel wiz, but wasn’t using off-the-shelf software. How many months of productivity could have been added back into these teams’ lives if they had better tools? How much less disruption could I have experienced, and even, how much less could I have paid if my contractor could get three jobs done in this time because she was so much more productive?

(Did you notice that even I’m relying on the serendipity of my building a garage to illustrate my point that VC relies too much on it?)

In a rational world, every reasonably sized market would have a well-funded ecosystem of software companies vying to take it into the information age. When I got my home equity loan for the garage, I should have been inundated with offers from software companies to help improve the project. Heck, someone should have offered me the loan interest-free if only I required my contractor use their software. Instead, my project is late, costs me more, and makes less money for all the workers because it’s left out of the information technology revolution.

And that’s just one industry, chosen at coughrandomcough. What about all of the other industries the software kings have not yet anointed as worthy, filled with deeply skilled and energetic experts who aren’t lucky enough to run in the right circles, or live in the right zip codes?

Venture investors famously want passion for the problem they’re investing in solving, so much so that the companies also then demand that any employees also be passionate in turn. And we want our software companies started by developers, by product people, not by business analysts. Or carpenters.

So now to start a company you’ve got to have a software developer thrilled about and experienced in a problem, able to accept the risks that come with starting a company (e.g., health insurance and wage loss), who is living in or can move to San Francisco, and hopefully is a white dude who went to Harvard or Stanford. One way to look at that is how discriminatory it is, but another way is just how much you’re relying on everything lining up just right. It might be that you’ll find a Stanford-educated software developer who deeply cares about building houses and can take the leap into entrepreneurship. But what are the odds that that person has the right insight at the right time, and then can find the right people to partner with?

Twenty years in I’m still awed by the opportunity for software to connect, educate, and empower people, but I’m incredibly disappointed by how little of that opportunity we’re progressing against. I think our inappropriately slow revolution is in large part thanks to this reliance on randomness. We have got to get past this if we truly want to get the most out of software before the heat death of the universe (coming more quickly now with all the power being consumed to mine bitcoin). If we can build an environment that does not use serendipity as a crutch, I am convinced we can generate more great companies, and importantly these companies can cover a broader swathe of the economy, and be run by a more representative sample of the market.

Let’s look to biology to see how much of a difference shifting to a constructed environment can make. Living creatures are full of enzymes, which are basically proteins that speed up the rate of a reaction. These reactions are critical to the function of the organism, and without the enzymes speeding them up, life as we know it could not exist. (Conveniently, I did my senior thesis at Reed College on protein structure, so I’ve got some knowledge here.)

In most cases, the reaction that they catalyze (that is, cause to happen) would happen without the enzyme, but it would do so at a far slower rate. For instance, mammalian milk contains the sugar lactose. This sugar will break down in water into glucose and galactose of its own accord, but not quickly enough to digest all the lactose in milk you drink. Mammals have evolved the enzyme lactase, which causes this splitting of lactose into simpler sugars to happen much faster.

Enzymes are incredibly complex — lactase has 1927 amino acids in five separate groups, arranged in an amazing 3D structure: A rendering of the structure of lactase This huge structure is all necessary to enable the protein to place a lactose molecule near a water molecule in exactly the right arrangement to ensure the reaction happens immediately, every time, instead of eventually, sometimes. For all this structure, the site where the reaction takes place is quite small, just big enough for the two target molecules. Those 1927 amino acids mean the protein is about 37,000 atoms. Lactose is 35 atoms, and water is, ah, 3.

That’s a lot like designing a building the size of a sports stadium just to catalyze a meeting of two people.

How much quicker does the enzyme work? About 75% the world’s human population is lactose intolerant, meaning that if they drink milk as an adult, the lactose will cause adverse reactions instead of safely being broken down in the intestines. The rest express enough lactase that they are able to comfortably metabolize lactose, and thus can drink as much milk as they want. Again, remember that lactose breaks down in water on its own, just too slowly to be useful.

So here we have a situation where one of the major sources of calories around the world — cow’s milk — is enabled by this enzyme dramatically speeding up reaction rate.

What does this have to do with venture capital?

Again, venture today is heavily reliant on serendipity; that is, the right people bumping into each other at the right time in the right context. This is exactly how chemical reactions happen normally: Two molecules (e.g., lactose and water) live near each other, and every so often they bump into each other in a way that enables the reaction to happen. Most of the time, however, they fail to hit exactly the right setup, and nothing happens.

When the enzyme is present, though, its unbelievably complex structure ensures that the water and lactose molecules are placed into exactly the right orientation every time, and bam, magic happens.

The probability of a great company getting founded today is a lot like the probability of lactose degrading naturally: It happens, but slowly and infrequently.

I smile at the idea of complexes the size of sports stadiums built for speed-dating founding teams, but that’s not necessarily what I’m recommending here (although if that’s your plan, I’d love to consult on the project).

Even if we wanted to, I don’t think we could build a structure (physical or otherwise) like this, because we don’t yet understand yet what it takes to build a great software company, which means we can’t construct or evolve a perfect environment in which to make it happen.

All I really know is that what we’re doing now isn’t working. We’re not attacking the right markets, we’re not including enough people, and we’re not having a big enough impact on the economy.

For our ecosystem to be healthy, for it to be effective at transforming the industries that need it most, it has to do something differently. We can really only increase the rate of great company creation by increasing the rate of experimentation, or increasing the rate of success. Incubators and early stage investors are doing what they can to run more attempts in parallel, somewhat like a generative algorithm, but this is bound to have little impact because the goals — “be worth a billion dollars” — are so separate from the founding event. Investors are starting to figure this out and pull efforts back accordingly.

That leaves us the challenge of finding ways to increase the rate of success.

Of course, I have my own ideas for doing so, but I was always told as a leader my job was to present the challenge to the team and leave the problem of solving it to them.

Consider yourself challenged.

Venture Capital Is Ripe for Disruption

luke@lukekanies.com (Luke Kanies) — Tue, 20 Feb 2018 00:00:00 +0000

It’s time to develop new sources of capital for founders, to help them generate wealth through solving their customer problems without the massive failure rate. Part 7 in a series.

Originally published on NewCo Shift.

The venture capital world that funds the technology ecosystem appears to be specially designed to back the best founders working on the economy’s most important problems. This series has shown that it has instead evolved over time, with no higher purpose in mind than any other financial instrument.

This evolution is in many ways a strength, as by definition it is built on the successes of the past, but it leaves our ecosystem more blind than we realize. We can fear the fragility this engenders, but should instead see it as an opportunity to reach beyond its artificial limitations, to solve hidden or devalued problems. Technology funding’s demonstrated ability to change should give us confidence we can stretch it further, clearing new paths to success.

Wikipedia covers the history of venture capital better than I could, but it’s worth highlighting key epochs. The system as we know it was birthed by the windfalls from early funding wins, including DEC and Fairchild Semiconductor, so by definition there was no technology funding system in place at that point. Every deal involved people flying around the US collecting enough money to back a new venture.

These early big successes motivated a few people in the west to set up firms dedicated to funding technology companies — prior to this, the vast majority of American capital was in New York. Within a couple of decades, partially enabled by some regulatory changes in the US, there were enough firms around (including modern heavy hitters like Sequoia and Kleiner Perkins) that we had what felt like the first stable system, which of course led to over-investment and the first pull-back in the late 1980s.

What survived went on to fund the internet boom in the 90s, when a huge amount of wealth was created (and then destroyed) and this new ecosystem first made it into the public consciousness. Much of what we believe about venture capital comes from those days, but it was still changing quickly, with no seed funds, relatively small amounts of funding for software companies, and no obvious pattern of success.

Right now, the system looks dangerously stable. There are hundreds of seed and venture funds, all following the same playbook: Try to get their investments to the magic number of $1m in annual recurring revenue (ARR), raise an A round of funding, and keep on the funding train until you go public or go bust. There’s so much pattern matching going on that founders are contorting their companies to fit the funding schedule rather than discovering their destiny.

It’s important to recognize that this appearance of stability is a recent arrival. We might tell a story of how it’s a natural consequence of previous eras of success, but much of current best practice is cargo culting, copying the behaviors of the successful rather than understanding what made them work. If you step back even a little to gain perspective on the industry, you quickly see how much the system is still changing, and still needs to.

Don’t get me wrong: the system we have works. It is, essentially, functioning as intended, and any ideas or recommendations need to take into account not just what we dislike, but what makes it work. I hope this series has educated you somewhat both on how VC works, and why it works that way. As usual, when we dig deeper we find no villain at the heart of a web; we might not love venture capital, but it makes sense, and it works this way for good reason. And indeed, the system is working very well for a few people, and in the process is driving huge change in our economy and lives.

As much as the system of venture capital makes sense, we must ask: What sits outside? The industry generates money through positive feedback loops, but absence from the industry is merely an indication that something hasn’t worked, not that it can’t. What are we missing by doubling down on what we know, instead of exploring the unknown?

Investors are reliant on people near them, who resemble them, and who can absorb the weighty downsides of entrepreneurship. We’ve seen that investors don’t really know what separates great companies from bad in the early days, so they don’t strive to create the conditions necessary for gestation, and once a company is started, they do little for the winners and even less for those who fail. But don’t worry, all of this is hidden by the massive profits that the biggest winners generate for the top-performing investors, and the rest of the industry (while failing to meet its investment return goals) glides along in the afterglow.

(To think I was asked recently if I had become cynical about venture capital.)

It’s a funny thing. I grew up a communist (literally, on a commune) but have become a pretty big fan of well-regulated open markets (although they seem to exist only in theory; in practice we have lost the taste for effective regulation). A self-respecting capitalist can and should argue that this is a market, and it’s performing exactly as it should. I can hear it now: “Capitalism is inherently Darwinian, where evolution gives all prizes to the winners and the losers don’t live long enough to make it into the archeological records.”

It’s a fair point. Humanity can afford stretch goals like less collateral damage than the battle for life and death on the savannah, but we could ask for better even without that ideal. It took millions of years for nature to come up with the Dodo, only for it to promptly die off once it encountered outside species. How convinced are we that our apparently stable system is any more safe from an outside force?

The ultimate weakness in the Capitalist defense of venture capital is that for all the apparent competition we have a homogenous system. Shouldn’t we have multiple types of funding competing for the best companies and the best outcomes? That is, not competition between VCs who all work the same, but competition between different funding strategies?

Because there is no open market here. At best we have a dysfunctional oligopoly (is there any other kind?) with some churn at the top. For all the talk of disruption, everyone is trying to win by copying the winners, rather than seeking to disrupt them. The only people willing to step outside the current system are those who don’t have a choice because they aren’t allowed to succeed within it. Unsurprisingly, they find it challenging to compete not with another investor but with a whole system of funding.

As just one example, the most common barrier I hear to starting a new kind of venture capital is that the limited partners — that is, those who invest in the venture capital funds — would not be willing to support a new kind of capital. This is a perfect example of an ecosystem limitation, rather than a problem with individual players. I hear no argument that founders, employees, and customers don’t want competitive models; only that the source of capital would need to be educated, and that’s just too hard. Except… this whole industry is only a few decades old, and its creation required that same kind of education. Why should we expect a new kind of financing to be any easier to start, require any less systemic change, than the one we’re fighting against? And isn’t it ironic that an industry built on stories of disruption finds the idea just too hard for its own work?

That competition will show up eventually, though. We need it. There are too many software markets lying fallow, unfundable in the current model and thus deemed to be of no value. Someone will figure out how to finance those companies. And just as the first winners in venture were big winners indeed, the first few investors to step out of this world into a new one should make out like the oligarchs who laid the groundwork for our current world.

I’ve said before I don’t have the solution, but there are some market truths give me confidence there are better answers available:

The best way to make money is to hold high quality assets for a long time. If nothing else, Warren Buffett has demonstrated this is both the best way to make money and indefinitely scalable.
The majority of employment and wealth generation is provided by companies too small or too closely held to be public.
The steady state of good companies is cash-flow generation managed by long-term teams who take pride in their work. This is literally the entire history of for-profit enterprises. Any other solution must either fail or revert to this at some point. None of these realities show up in modern venture capital. Companies can’t run on venture capital forever (although try telling that to Uber), and do usually need to show a profit to be sustainable (I expect Amazon begs to differ), but the companies that do either of these are explicitly leaving the world of venture capital.

It’s unquestionable that the financing structure of venture capital is tied in to this separation from market principles. The risky software companies we build today are funded via a structure invented to support the risky ventures of the 19th century: whaling. Suddenly the term ‘venture’ in venture capital makes more sense, doesn’t it? (Tragically, even though it was the days of slavery, those whaling fleets had better representation in some ways than current tech companies, with up to 20% of their employees being African American. Wow.)

We’re using an incentive structure that works perfectly to support individual voyages that might last a couple of years. Is it any surprise it is not great at building companies that last for decades, or have a high survival rate? In fact, whaling had a better survival rate than current venture capital, with more than 80% of the fleet surviving, and delivered better returns (14% IRR on average, and 60% IRR for the best). The funding perfectly matched the ventures.

I should not need to say this, but whaling is unlike company building. It’s unrelated to developing a product, it has nothing to do with creating a new market. It’s inanity to expect a funding mechanism built for one would work as well for the others. The fact that it’s making some people rich, and it hits a jackpot once in a while, should not confuse us.

Venture capital’s apparent stability convinces me it’s at its most vulnerable. Instead of continuing to fund disruptors, I think it will itself be disrupted.

If you’re a founder given a choice between a firm that kills most of its customers and one with demonstrated success at creating long-running companies that generate wealth for everyone involved, why would you pick venture capital? The only reason you do today is because it’s your only option.

Founders want this competition right now. Some want to build Facebook, but most want to build a great company, help their customers by solving a critical problem, and hope to get rich along the way. They don’t want a lottery ticket; they want upward mobility, entrepreneurial fulfillment, and to feel like they made a difference. Unfortunately, low-probability gambling is all the venture world sells.

The new models will start at companies run by women and people of color, because they’re the ones shut out of the current system, but as they start to succeed, they will start to pressure to rest of venture capital, and we will see just how stable the system really is.

I have tried in this series to help you understand not just what venture capital is, but that what you love and hate about it are intrinsic to how it works. I hope this deeper knowledge will help you make higher quality decisions about how to involve yourself in this world. Even more so, I hope it convinces you to seek out, or even create, other ways of funding companies, other ways of building them.

It’s time for founders to have truly competitive options for funding. Let’s go make it happen.

Why the Most Successful VC Firms Keep Winning

luke@lukekanies.com (Luke Kanies) — Tue, 20 Feb 2018 00:00:00 +0000

In an industry built around investing large sums in uncertain ventures, the best companies seek out the best investors, and gains accumulate at the top. Part 3 in a series.

Originally Published on NewCo Shift.

Investing in software companies is inherently an uncertain activity. It’s called high risk, but highly uncertain is a better label. Yes, you’re taking a risk with money, but the real problem is the widely variant potential outcomes. If you invest in a restaurant, you are taking a risk but you will pretty much end up with a profitable restaurant, or lose your money. If you invest in a software company, you can go bankrupt, have a small but profitable company, sell for five times the money in, or end up with a world-spanning multi-billion dollar behemoth that turns everyone it touches into a millionaire. That dramatic range is why you can get a bank loan to start a restaurant but not a software company. It’s exactly why people invest in software, but also why it’s so difficult to do well.

There’s no proven method for managing that uncertainty. The most successful investors frequently get it massively wrong, and a playbook that worked perfectly in one circumstance falls flat on its face in so many others. Yet, even when they frequently make monumentally bad investments, the best investors keep delivering the best outcomes. If no one knows what separates the best from the rest, how can some firms or individuals keep winning?

Of course, many would disagree with my claim, they would say the best keep winning because they can tell a great company from a bad one, but if you look at the trends in venture capital you can see the industry as a whole has given up on a clear system, even if individuals still cling to deserving their greatness. Fantastically successful investor Paul Graham once said that he can be tricked by anyone who looks like Mark Zuckerberg. He’s since claimed that was a joke, but he built his empire by making more bets than anyone else, which is a strategy explicitly designed around the fact that he doesn’t actually know why some things succeed and others don’t. Disgraced investor Dave McClure started 500 Startups with the similar goal of just making lots of bets, rather than making any attempt at making “good” bets.

Even those who invest in venture capital firms have given up on knowing who’s best. Given a pot of money allocated to VC, limited partners will distribute it across many firms, knowing that they have to play many hands to get a winner. After all, the industry average return for venture funds is, ah, absolutely nothing. The winners win big, and the rest balance that out, so LPs need to put money in enough places to be confident they end up with the winners.

If no one knows the difference between the best and the worst, why do the winners usually keep winning?

Access.

Venture capital is all about access: Founders having access to capital, and investors having access to the best deals. If you’re a founder today and you have a choice between taking money from a top-tier firm that keeps delivering hits, or another firm you don’t know and who hasn’t done well, which do you take? Of course you take the best firm with the biggest network and most well-known brand name.

Similarly, if you’re an investor who’s helped take lots of companies public, how does your deal flow compare to those who are just starting out and who don’t have a reputation for building big companies? Of course the best companies come to you.

In other words, there’s an implicit matching algorithm, where companies that are obviously doing really well are able to work with what look like the best firms, and as a result they are able to reinforce each other’s success. The best firms look better because the best companies seek them out, and the best companies do better because they’re getting the chance to work with the best brands. (For all that I am skeptical of repeatable investment skill, I am a deep believer in the value of brands.)

Venture capital is defined by the asymmetric stresses pressed on investors and founders by the need for access; every entrepreneur stresses over how they’ll get access to capital, and every investor’s business model is built around managing deal flow. Entrepreneurs who already had a great outcome magically have no trouble raising huge amounts of money, and yesterday’s great investors have no trouble convincing today’s great companies to work with them.

This focus on access also helps to explain some of the churn the system experiences. If no one knows what makes a great company, how can the best investors always get access? They can’t. There are plenty of great companies that fail to get first-tier support early on. If they do raise money, then those who backed them end up looking like tomorrow’s geniuses, and the cycle starts over with them closer to the top.

This access-based sorting also helps to explain how the VC industry is so discriminatory. Less than 5% of investments go to women-led companies, and just having a woman founder ruins a team’s chance of getting funding , and the numbers are as bad for firms led by African Americans, for example. If we believed investors actually knew what they were doing, then we could only conclude that they were correct to exclude women and minorities from investments, that these founders just couldn’t build great companies.

Of course, the data clearly says otherwise: Founding teams with women on them significantly outperform male-only teams. Because investors don’t know how to pick a good company from a bad one, they are relying on access and reputation, and because they’ve never let women or minorities in before, they can’t now. Their “pattern matching” doesn’t hit here.

This matching algorithm that runs our industry is reliant on privilege and luck. Venture firms and founders are almost exclusively white men from expensive schools (with a huge proportion from just Stanford and Harvard), and if you were lucky enough to be an early employee at Facebook or Google (who have historically used the same sourcing requirements), then that’s a big leg up, too.

To be clear, I think some investors are much better than others, and entrepreneurs haven’t built huge, successful businesses out of sheer coincidence. It’s not that there’s no skill involved, or that the people who get so rich instead deserve nothing. It’s that skill is an over appreciated (and often small) part of what determined their success.

You will rarely find communities admitting that privilege and luck are what determine outcomes. Human nature itself has a deep aversion to accepting this. Instead, we do what humans have done forever: We develop myths.

Humans deeply believe that people get what they deserve, and deserve what they get, despite the evidence to the contrary. So many of our cultural biases are a story created to justify a reality we would like to perpetuate. For millennia we’ve been told that royalty was special, and that’s why they were in charge, when it was patently obvious that their ancestors were just the best and most ruthless at organizing enough troops to control a chunk of land. Genghis Khan was history’s greatest murderer, which enabled him to spawn kings and kingdoms that lasted for seven centuries, but you can bet his descendants didn’t use his skills at genocide as justification for their lofty positions.

Similarly, myths have grown around venture capital exist to explain the winners and losers. Somewhat like royalty, these myths help convince us that VC is more than privileged people using their positions to make lots of money. They must be winning because they deserve to win. Equivalently, people lose because they didn’t deserve to win. You could waste your life reading about how this founder got rich because they were smart and worked hard, or that investor succeeded because of their investment strategy, but you couldn’t consume a whole morning with the stories of equally smart founders who worked just as hard but went broke, or investors who applied that same strategy but somehow didn’t make it on the Midas list.

Thankfully, we’ve seen some really interesting experiments focused on eliminating access as a criteria for investing. Social Capital recently launched a programmatic investment algorithm, and Village Capital uses peer decision making between entrepreneurs. Backstage Capital was founded explicitly to invest in those who can’t get capital from the system as it exists today.

With these and related efforts, I’m optimistic that we can begin to peel back the myths about what makes a great investor, entrepreneur, or company, and instead begin building a more open market around investment and company creation. Only then can we hope to see venture capital include, enrich, and benefit all parts of the economy.

The Tension at the Heart of a Freemium Business

luke@lukekanies.com (Luke Kanies) — Mon, 30 Oct 2017 00:00:00 +0000

Giving something away for free can be a fantastic way to achieve adoption, but it raises a permanent conflict. The conflict is even greater when the free products are open source.

Driving adoption is a key requirement for any product business, and a popular tactic for doing so is hooking people with something free in order to sell them products once they’re invested. The most famous example is Gilette “giving away” razors, but this model is now widely adopted by software companies striving to grow quickly but cheaply. Splunk and New Relic are examples of fantastic businesses who allow their products to be used for free in some circumstances in order to drive long-term adoption and revenue.

Success with this tactic requires mastering the tension that it introduces: The thing you give away must be valuable enough that it drives adoption, but not so valuable that people don’t eventually need to upgrade.

If it is insufficiently valuable on its own, no one will use it, but if it is so valuable that people can succeed without ever paying, then you have users but not customers.

The goal of a freemium business is to separate the commitment from the buying decision. I want you to become so successful with my product that you become committed to it, which means when I finally ask you to pay the sale is both easier and more valuable.

For you to become committed, you must be successful. You must achieve whatever goal caused you to download my software in the first place. However, in your success, you must also hit some wall that requires you to upgrade.

Managing that balance is crucial to success with freemium. Give too little away and you don’t get any adoption, but give too much away and you have a passionate community but no money to pay for building the software.

This balance is complicated by the fact that the best communities are built around authentic identities, so changing what you give away involves changing who identifies with your company and why, which is much more fraught than tuning your business model. It’s a sufficiently complex operation that it’s one of the key dials that a freemium business will manage throughout its existence.

As difficult as this balance is in a proprietary software business, it’s much harder when dealing with open source. After all, when you decide to open source something, you’re not just choosing to make something free, you’re giving your community permanent rights to something you own. While you technically have the right to keep private any further updates, in practice once you open something up you have to either keep that project free forever or let it die.

Your community considers the opening of your code a permanent commitment to maintain this software for free forever, and anything less than that will generally be considered betrayal. They didn’t adopt you, or your revenue streams; they adopted this free thing that you promised would work well for them, and they’re going to raise hell when it doesn’t. They don’t care that your business model requires that you charge for analytics, or for clustering. They need those features to be successful, you implicitly promised them success, and now you’ve got blood coming out of your ears.

In some sense, successful open source software companies require lightning to strike twice: They need to free something that it is so great you’ll adopt it without paying, then they need something else that’s also so great you’ll pay them. Most OSS companies try to provide this extra value at the margins, because getting that second lightning strike is so hard. Proprietary software companies can provide hard limits on how you take advantage of their most useful features, but if those features are open source, then of course you can’t limit them in any way. You’ve got to develop additional features instead.

It’s not a coincidence that we’ve seen so few open source software companies build large revenue streams. Most end up shifting their focus from the open source that started everything to proprietary software that drives their business. The best companies remain community-oriented, but that is by no means a given.

If you’re considering building a freemium business, you must treat the success of this balance as a key business metric. It underpins the unit economics of your business, determining how big the funnel is based on adoption and how many convert based on the willingness to pay.

Getting it right is worth it because it enables a fantastic company with low marketing and sales costs, an engaged community, and easy upgrade paths for your best users.

Should You Open Source Your Product? That’s the Wrong Question

luke@lukekanies.com (Luke Kanies) — Mon, 23 Oct 2017 00:00:00 +0000

Don’t get stuck on a solution until you know what problem you’re trying to solve.

I often get called in to help companies make decisions about their open source strategy. They want to release key parts of their software as open source, but they need some help figuring out the best way to make it happen. I always ask them the same question:

Why? Why are you planning to open any of your code?

They rarely have a good answer. They’ve already decided that this is the right decision, because a board member, founder, or customer has said it’s necessary, and they are just trying to figure out how to do it. But it’s impossible to build a strategy to accomplish your goals if you’re unsure what they are.

Are you trying to build a community? To get public review of core functionality? To grow adoption? Something else entirely? By now most people have realized that open sourcing software isn’t a route to magically get free contributions so you don’t have to write your own software, but there are plenty of other myths around it.

I’m a huge fan of open source. I’m an even bigger fan of the companies behind it building a sustainable business so they can stick around for the long term. Open source is a tactic, taken to accomplish (hopefully) a key goal for the business. It has upsides and downsides, like most tactics, and it has to fit your goals.

There are damn good reasons to open source software, either as a business or as an individual. Most motivations I’ve heard from founders don’t stand up, though. Companies have built healthy communities (Github, Atlassian, VMware, Microsoft) and scalable freemium models (Github, Splunk, Slack, Trello), all with no notable reliance in publishing open source software.

The fact that these businesses have been built with proprietary software doesn’t mean yours should be. But it at least shows that your goals have multiple routes to accomplish them, and you can’t just say you need to open source your product because you want the same adoption path as MongoDB.

Many open source software companies don’t have the luxury of starting with goals and working backwards. If your project started first, and you only built a company once your community made it clear you should, then many hard questions are already decided, and you have to work around the reality of your situation. Docker is a great example of a company being built in response to community demand, because an existing project got adopted broadly enough that the opportunity arose to build a business (or in their case, shift the focus of an existing business), and some of their struggles can be attributed to the path they took.

I open sourced Puppet through a combination of ignorance and confidence. It honestly never occurred to me that I could build a company around commercial software, since I really only knew the OSS world well, and when I started Puppet, around 2005, there seemed to be plenty of great examples of successful business models around open source so I assumed I’d figure out which of those made the most sense when it came time. In the mean time, I did exactly what needed doing: I focused on building software that people loved, and then convincing people to use it. By the time I realized how hard it really was, we were too far down the path to dramatically change our strategy.

If, however, you are early enough that all options lie before you, you need to take the time to ensure you have the highest probability of success. It’s hard enough to build a company from scratch; don’t make it harder. Your team should actually view open source as a liability, in the financial sense: You’ve made a commitment (usually implicit) to your community that you’re going to spend money indefinitely to make sure this software gets better and better. Just like other financial liabilities, like office leases, employee contracts, and partnership commitments, these can be fantastic successes. But like any liability, they can just as easily be a painful drag on your work if done poorly.

I think open source can be a huge help in building community, widening your marketing funnel, increasing the quality of your code, and building software people love. But you have to do it with clear ideas of what you’re trying to accomplish and what you’re willing to do to make it happen.

Moving Beyond Silicon Valley Software Companies

luke@lukekanies.com (Luke Kanies) — Mon, 02 Oct 2017 00:00:00 +0000

We need a new financing model to build new, better companies. Part 1 of a series.

Originally published on NewCo Shift

Two decades into a software career, I’m still moved by its potential to improve people’s lives through connection, automation, and access to information, yet I’m less convinced than ever that our financial systems are built to get the most out of it.

This is the first post in a series I’ll be writing on the structural problems in venture capital. These problems aren’t a condemnation of the industry, they’re an attempt to outline where the industry fails the market. This failure helps to explain people’s experiences, but I think also helps to outline the opportunity and need for other ways of funding companies. These ways will also have flaws - they’ll likely not be great at building unicorns - but they’ll be finding people and markets ignored by the current environment.

Like the general financial industry, the world of venture capital has become adept at using money to create more money, but it does not consider of the wisdom of its actions. It chooses easy answers, thus leaving harder but better questions unexplored, and accepts high collateral damage to the employees, customers, and industry that at best is painful and at worst is pure exploitation.

I am pulled to build more software that, like Puppet, helps people get higher quality work done in less time and with more joy. But that kind of utopian phrasing is used by every company in silicon valley, whether they do advertising arbitrage or sell you pet food, all while asking their workers to work crushing hours for lottery pay, no safety net, and 19th century ideas of labor force participation. The devaluing of women and minorities as either workers or buyers is both discriminatory and bad business. It’s true I’ve heard no overt support for child labor, but I expect that’s mostly because kids don’t have CS degrees from Stanford or Harvard.

I believe it is possible to design a kind of financing vehicle that is less subject to these flaws. There is a lot of money to be made in enabling the whole market to participate in the technology economy, and given that productivity has stalled since 2004 (coincidentally around the time that social networks and attention-seeking advertising-driven business models took over), there’s a lot of opportunity to deliver value by increasing productivity.

The major concern about increasing productivity is that it generally means fewer jobs, and the lowest-skilled workers tend to be first and hardest hit. I do actually believe in reeducation and the movement of labor to new opportunities, but you can’t ignore the trauma of career changes and industry churn. My work at Puppet showed that empowering people at the front line is how you drive both change and value. Too many industries focus on getting rid of the experts at the coal face, when instead they should look to elevate them. This would improve productivity while developing careers, instead of destroying them.

Unfortunately, venture capital is structured to require trauma to everyone involved except the investors. Too often, even the limited partners who are the source of capital suffer, with only a few firms delivering the kind of returns that the asset class purports to offer. The industry is built around making many bets and expecting most to fail. Even worse, every company who wants to participate must make a claim to be able to reach these heights, even if they don’t believe it, and then they must risk their own death attempting to keep that promise.

The model itself requires that companies either go public or kill themselves. Nothing else fits in the spreadsheets. Again, this guarantees trauma to nearly everyone involved - even the ones who make it out suffer the whole way, leaving a trail of burned out employees and failed customers.

I think there are amazing companies waiting to be created that can deliver life-changing benefits but can realistically “only” generate $30m, or $50m, a year in revenue. At 25% margins for software, these can be huge sources of profit, but a venture capitalist would derisively call that a lifestyle business and either not fund it, or force it to kill itself in an attempt to scale beyond its natural size. These can be great businesses, but because business funding generally fits into either conservative bank loans, or 10x-oriented venture capital, there’s no model today that respects them. Jason Fried and DHH at Basecamp have done a ton of great writing on this.

Jennifer Brandel, Mara Zapeda and others have launched the Zebra movement, focused on helping founders shut out of the VC world start companies that enrich themselves and their communities rather than their investors. I think this is an awesome effort, and has been an inspiration to me.

It’s true that this kind of company could not have as high a failure rate as venture capital does, but, ah, that’s not exactly complicated. I mean, VC literally requires failures of most of their companies, so I’ve got a nice anti-pattern to work against. There are well-worn practices for improving operations, people, and efficiency at even young businesses, but VCs haven’t bothered to invest in any of them, because again, they expect most everyone they work with to fail. Vista Equity, among many others, has shown that being more than dumb money can be more than just talk.

You might say there aren’t enough entrepreneurs out there, and all the great ones are focused on building unicorns in silicon valley. I say phooey. Tell that to the millions of people who start restaurants, corner shops, and franchises around the US. Frankly, tell that to all the people who pitched the valley but weren’t white men, or couldn’t afford to live in the bay area, and thus could not get funded. Because the valley itself refuses to believe great entrepreneurs can be women of color, or uneducated, or have a humanities degree, there is a long waiting list of great people ready to be given a little money and a little trust.

Silicon Valley today is baseball before Jackie Robinson, golf before Vijay Singh and Tiger Woods, tennis before Arthur Ashe and the Williams sisters. It’s the World Series with only North American teams, the World Championship game with only American athletes. It might do great things and be a great spectacle, but it’s weak sauce, because you know you’re not really competing with the best. In fact, you’ve structurally guaranteed you won’t, with all your stories of pipeline problems, lowering the bar, and various other grandfather clauses.

I do not believe in the primacy of ideas. I do not believe great entrepreneurs are in short supply. I do not believe we will run out of awesome opportunities in software in my lifetime.

I want to collect funding that will enable those unsupported entrepreneurs to reveal and develop their greatness, I want to build software companies in spaces that currently have no software, and I want to generate great returns for everyone involved without hemorrhaging people and money.

Yes, I know that means I have to find a different way to deliver returns to investors, because I don’t want my portfolio companies to have to sell. Yes, I know that means I will be creating a new asset class, with all the complications that entails around convincing LPs to invest in it.

The fact that others dismiss it out of hand for being impractical is exactly what excites me about it.

Please follow along in the rest of my series as I delve into the individual structural flaws in venture capital that I think outline what a competitive funding instrument must find a way around.

Stopping the Software Factory

luke@lukekanies.com (Luke Kanies) — Thu, 28 Sep 2017 00:00:00 +0000

It’s only a good practice if you have the cultural discipline to make it work.

Stopping the factory used to be sacrilege - companies figured they were only making money if the line was moving - so when Toyota adopted this practice on their manufacturing line is was a huge shift. It was taken so they could resolve quality problems immediately, which saved them time and money because otherwise the problems occurred in many cars and had to be fixed later. It was better to pay the price of stopping the line now than the price of redoing the work later.

This was a huge cultural shift throughout the organization. Management had to recognize the cost of fixing quality later, and change their short-termer mindset around the moving line. The workers on the line had to learn not to let problems slide by, to ask for help immediately and not rest until the problem was truly resolved. Everyone had to learn to diagnose problems in the line without blaming individuals, otherwise trust was impossible and the real problems could not be diagnosed. (This is also where Toyota developed their ‘Five whys’ practice for getting to the bottom of problems.)

While we’re obsessed with individual techniques like Kanban, the team at Toyota knows that it’s culture that allows them to win, not the tools they use. That difference is also exactly why it took decades for the rest of the industry to catch up: You can adopt technology quickly, but culture? Not so much.

We experienced the same problem when we tried to adopt this practice in our software teams. People loved the ability to stop the factory, and they used it all the time. Often, it did actually increase the quality of the work we did. But overall, it made things worse for us, not better. It was causing arguments, bad relations, and most importantly, was reducing our long-term efficiency, not increasing it. It became nearly impossible to ship software.

What went wrong?

We had adopted this practice without developing the cultural discipline to make it work. People weren’t stopping their own lines to resolve systemic quality issues; instead, they were stopping the work of other people to question their decisions. A technique for improving our work became a technique for attacking our strategy. Disagree with the product that team is building? Stop the factory! Don’t like the database they chose? Pull the cord!

Yuck. That’s not how that’s supposed to work. It didn’t help that I’ve always pushed hard for people at the front line to be opinionated and educated about as much of the product as possible. Suddenly they’re applying those opinions to the work of others, and we’re not building higher quality products, we’re just arguing non-stop about what we should be building and how.

This required that we develop a couple of new cultural skills. When you read about the Toyota system, it’s striking how much of what they accomplished was essentially cultural technology - that is, tools for developing and sustaining culture - rather than manufacturing tech.

Our failed experiment at letting anyone stop the factory showed that first everyone needed to understand the value in stopping the line. We started to point out that they should be focused on their own work, not others’, and thus should only be able to stop their own line. Most importantly, remember back to the point of pulling the cord: You’ve discovered that your own work is compromised because of a quality problem in the system, and you need time and help to fix it. That had to be why we stopped the line, and nothing else.

That being said, people’s concerns about decision making in other parts of the organization needed to be heard. Expert teams should being given the power to build what they think is best. But even the best teams need outside reviewers, need other experts to question their assumptions and conclusions.

Our work cycle needed to include productive, constructive feedback opportunities. The best process like this I’ve ever seen is in Pixar founder Ed Catmull’s Creativity, Inc, where he describes their “Brain Trust” system for helping directors make great movies. This is such a great system that it’s worth reading yourself, but the aspect that stands out is the responsibility of the team giving feedback to the director:

Your job is to help them see the flaws in their proposal. You can not and must not propose solutions, and you can not demand that they agree with your complaint. Even if you’re the CEO. You are a collaborator helping someone do their best work, not a competing director trying to get your ideas into the movie.

See the parallels to the value in stopping the line? It’s about improving the quality of work, not making a power play, or being right about something.

Pixar has a critical second layer to this process: Management decides whether to ship the movie. This allows them to give the director full responsibility for the movie. If directors don’t agree with the team’s list of flaws, that’s fine, but in the end, you have to convince the management team that the movie works.

The thing I love about this is it gives you concentric circles of iteration and control. The movie team makes decisions constantly about what to do and why, then they loop out to the Brain Trust to get feedback on what they’ve done, and finally there’s a business cycle that determines whether the movie should ship. Everyone gets to contribute, but your business concerns are isolated from the work cycle, giving teams the freedom they need to build something great.

I was never able to figure out how to adapt their process to software, but I hold out great hope that there is a way, it just requires a lot of evolution. Pixar gets to take five years to make a great movie, but you never get that kind of window to make software. They also kept all of the iteration inside the building, where modern software should be built in layers, in collaboration with your users and the market.

Even without being able to directly adopt a better practice, we recognized the need for two layers of process. We thinned down people’s ability to stop the work of others, and at the same time built feedback loops at larger intervals and in different forums for strategic concerns to be heard. We also began building cross links between teams that allowed those with concerns to collaborate with those doing the work, rather than leaping in and shouting ‘stop!’.

There are many great inspirations for how to build better software, faster, but all require some level of adaptation. I am absolutely convinced we will see a software production system as coherent and clear as Lean Manufacturing, but I also think it’s going to take a long time, a lot of experimentation and failure to get from here to there.

Hopefully our experience, our successes and failures, can help you get there faster.

Framing the Risk in Your Business

luke@lukekanies.com (Luke Kanies) — Sun, 11 Jun 2017 00:00:00 +0000

Growth requires risk. But don’t overdo it.

Originally published on NewCo shift

I was asked by a CEO recently, “How do I know if my product is ready to scale?” He thought he was ready to raise money and start growing the company, but he didn’t really know how to be sure.

Venture capital exists to invest in enterprises that have a huge opportunity but are also a big risk. Yet VC firms tend to actually be pretty conservative, relying on pattern recognition and social networks to make their decisions. This turns investor pitches into bizarre encounters where you have to help them see the huge risks in your business and how this risks can generate massive returns, but you also must convince them that you have all of that risk managed, so there’s no reason to be afraid. I’ve been turned down so many times by investors “until we’d taken the risk out of the business,” and every time, I’d sit in the car outside their office park thinking, “But don’t you exist specifically to make big bets?”

I can’t tell you how to raise money, because no matter what it’s hard, and there’s no special trick to it. Well, there’s one trick: Sell a company for a billion dollars. Do that, and you’ll never have trouble raising money.

This article is only for those who are not quite so lucky.

What I can help with is framing your company so that you can more coldly see and explain where the risk is, and with that hopefully you can help others get excited about the vision in your head, the beautiful thing you’re trying to build.

Step one is understanding your market risk. If you’re raising money, you have to convince your prospective investors (if you’re talking to typical valley VCs, anyway) that you can build a company that can do $100m in revenue at some point. So, convince me your market can support a company that can hit that scale and still grow. That means the market needs to be hundreds of millions, and probably billions. With Puppet, we knew the overall management market was between $6B and $25B a year, depending on your definition, which made this part pretty easy for us, but lots of companies are creating a market, so they have to spend a lot of time on this topic.

The next big question is why you, particularly, will win. Sometimes this is called technology risk, but companies win for many reasons other than technology, especially these days. Puppet didn’t necessarily have the best tech in the world, but we had a focus on the user that no major player in our space had. Everyone else was worried about the buyer, and we focused on helping the individual users succeed. Other companies have a cultural edge, or even just a mindset that others can’t copy. Whatever it is, though, there needs to be some reason why you’re going to take this big, awesome market.

I call this strategy risk. You’re planning to take the market in a particular way, and you think it will work but you don’t really know until you play.

A high-growth company usually trades off strategy and market risks. If everyone else agrees this is a great market, then you’ll have lots of competition so you need a unique strategy that sets you apart. If it’s a mature market with clear revenues and margins, you need a great strategy to fight against big incumbents, who won’t go quietly. If, on the other hand, no one else agrees this is a good market, and you get it all to yourself, then the strategy doesn’t need to be differentiated, so you can run the least risky strategy you can think of.

You can’t walk into a VC’s office and say there’s neither market nor strategy risk, because that business is just too obvious. It’s either so obvious it’s actually stupid, or so obvious that you’re one of a hundred players running the same game - both of these are bad bets. You’re not getting that funding round.

The last piece is execution risk. You’ve got a good market, you’ve got a solid strategy. Now convince me that you, particularly, can build a team and make this happen, within the window you have available. This is 99% about the team. Can you hire people? A lot of them? Get them working together? Do you know how to ship software, sell software, market it, etc? Some of this you can do through force of will, some you can do by just being smarter or faster, and some requires that you really nail a couple of pieces, but most of it is about building and scaling a company that can execute your strategy. This is the grit, the work, the hard part. The best strategy in the best market is worthless if you can’t do the work.

There’s one more critical point about risk. It should be obvious, but somehow it’s not.

You want to minimize the risks you take. There’s something about what you’re doing that’s unlikely, probably scary, and quite possibly stupid. That thing has to exist, because it’s what makes your business valuable. Without that huge risk, you can’t possibly achieve the massive payoff you’re looking for. Take that risk, put it on a pedestal, love it.

And then do everything you can to not let other types of risk into the rest of your business. If you know your major risk is strategy, why introduce a massive execution risk at the same time? No. Your work is scary enough that you should be conservative everywhere possible. Pick something you know works when you have that luxury, because you won’t get it very often.

This frame should at least get you the first three slides of your presentation. There’s plenty more to know before you can convince someone you can go out there and win, but being able to clearly talk through the risks in your business and how you’re managing should at least help you get a seat at the table.

Productivity Is Not About People

luke@lukekanies.com (Luke Kanies) — Mon, 22 May 2017 00:00:00 +0000

How best to combine “software” with “management”?

First published on NewCo Shift

You’re doing productivity wrong. Actually, it’s worse than that. You have no idea what it is. And no, this isn’t some sort of technical, jargon-y sense where I’m arguing over whether to measure it in terms of lines of code, hours spent typing code, or something else. Your core understanding of productivity is entirely wrong, and it’s making your company worse at everything it does.

Productivity in the software world is discussed in terms of the individual, and usually phrased as getting more of a person’s time on the thing they were hired for. “Hey, I didn’t hire you to talk to users or attend training! I hired you to write code!” Even the developers join in: “Every minute I spend in meetings instead of writing code is wasting company money.”

This is stupid and wrong.

I had a conversation with a CFO recently who asked me why his company should use Puppet. I asked him in turn, what does it cost you to ship software right now, and what’s the value of lowering that cost? He said, not surprisingly, that he could not answer that. This isn’t to pick on him - most software CFOs would say the same things, since their job rarely delves into software operations.

Can you imagine having the equivalent job description with a manufacturing company? Picture the CFO of GM saying their job doesn’t require they understand the financial aspects of building cars. They’d be shipped out in disgrace. Yet somehow the software world tolerates ignorance of the financial implications of their core work product, software.

Sure, you might say, our finance teams can’t help us build more, better software for less money, but we don’t need their help because we intuitively know that more time spent writing code equals more productive development teams. Right?

No, you don’t. Again, you’re wrong. This is exactly, specifically how you’re wrong.

Toyota showed decades ago ensuring everyone is busy all the team is a great way to lower productivity. Yeah, you read that right. Lower. If you can’t shut the factory down (thus making everyone idle), you can’t fix problems at their source, which means every car you make is broken in the same way.

As another example, teams can almost never be perfectly balanced in output. Maybe you make doors much faster than you make engines, so if your door team is always busy, you end up with too many doors. Just like in development: The interface team might work a bit faster than the backend team, so they build an interface on a myth and then you can’t ship their work because there isn’t coverage on the backend. Oops. But hey, at least that interface developer didn’t spend any time in training, testing their prototypes with users, or bringing fancy coffee to the backend team.

The stupid thing is modern industry figured this out with its very first business consultant, Frederick Taylor, who developed a thing he called ‘Scientific Management.’ His ideas sounded good: I’ll hold a stopwatch and find ways to encourage people to get more done in a given amount of time. Seems reasonable, right? Probably more advanced than how most software companies do it today. In fact, he was really successful: He spawned our nation’s first management consultants, and they’ve continued to make tons of money on the fraud that he perpetrated more than a century ago.

Because that’s exactly what he was: A fraud. He was fired from his first gig because it ruined actual productivity, yet managed to convince corporate America that it was such a good idea they should ignore the little problem of it not working. Here we are a century later and the Harvard Business Review is still giving advice using Taylor’s own language.

But, you ask, what do I focus on if I’m not allowed to just track what the developer works on?

Now, Grasshopper, you set foot on the path to wisdom.

These are examples of waste in the form of rework (fixing quality problems later) and inventory (the built but unshipped interface work), but there are many other kinds that pervade modern software development. Lean Manufacturing is our most complete and coherent philosophy of productivity, and its name isn’t just decorative. It reframes the problem of optimizing productivity into the practice of reducing seven (or sometimes eight) kinds of wastes, including those above.

The funny thing, though, is that none of these wastes are visible if you just look at the individuals involved, so measuring what the people do isn’t just worthless, it’s actively counter-productive. See what I mean about all the wrongness?

Transport is a great example. You might have a person at your company specifically tasked with this (the most famous example from this is certainly from Office Space, but there are rational reasons for such roles in modern software teams). Intuitively you’d want this person to be 100% busy, yet optimizing the system to need more transport hurts the system even while it makes your individual stats look better.

Our world of software is fundamentally confused because it can’t move past thinking about the people to seeing the system. The first page of results on software productivity pretty much exclusively focus on the people, and even developers will say they should be spending more time writing code and less time doing other stuff (like in meetings with product managers or customers).

This is the challenge of our industry over the next few decades. It took around two centuries to get from the first industrial mills in the 1700s to the development of lean in the late 1900s. There are times where I think we can do better, learn faster, but then I realize how much more complicated our problem domain is, and I start to wonder. At least in factories you can physically measure inputs and outputs, and you’re consuming and producing discrete, easily measurable work. With software - especially SaaS built on the public cloud - discreteness is impossible, and even measuring the cost of inputs often approaches impossibility. It’s much harder to optimize systems that extend far beyond our own data-centers (if we even have them).

Nonetheless, this is our challenge. The first step is to move away from this focus on people, from this view that the developer’s precious time at keyboard is our main concern. Only then can we start to truly get better at building better software, faster, and for less money.

Leadership Is Direction Plus Constraints

luke@lukekanies.com (Luke Kanies) — Mon, 15 May 2017 00:00:00 +0000

How I went from a capricious boss to a powerful partner.

Originally published on NewCo Shift

Early in my tenure at Puppet, I had one of my employees, José, make laptop stickers. He said we already had some, and I said, yeah, but they suck. So he designed something different. I said nope, still not right. Finally, in frustration, he said, “You clearly know what you want, can you just tell me what it is?”

I expect many of you will recognize this problem. It is sometimes called “Bring Me a Rock”, which pretty well captures its absurdity. Becoming a better leader required I find a way past it.

To my chagrin, I am often described as having “vision.” I hate this. It implies I know what I want, that I have some kind of clarity. I don’t. If anything, I pride myself on my uncertainty. I am a deep believer in open-minded, unsentimental experimentation and I think one of my true skills is knowing where to focus that research, rather than knowing what the research will find. This is pretty much the exact opposite of having a vision. So why did so many people think I had one? Why did everyone around me look to me for answers, instead of doing their own exploration?

I was tempted, but Kanies’s Razor kept me from believing it was just because I was so smart. Finally, someone partnered fantastically with me and helped me see that these are the same problem, solvable through better communication on my part.

In 2014, Puppet moved into a large, new office in Portland, OR, and we had the opportunity to strip the building down to its bones and build out the space we wanted. We were lucky enough to work with Corey Martin of Hacker. He and his team were great at really listening to me, and pulling out what I truly cared about, never getting frustrated or giving up when I was equal parts opinionated and incoherent.

I don’t always know what I’m talking about, but I’m pretty much always sure that I’m right. - Mojo Nixon

Corey quickly realized that I didn’t know what I wanted, but there was something worth extracting from all of the beliefs I was expressing. And, of course, I was paying him, so he did kind of have to actually listen to me. We spent the first term of our partnership working out the direction: What do you want the space to feel like overall? What impression do you want to leave? There are a few different ways to arrange this kind of office, which one appeals more and why?

Once we had that theme, now we could create an actual design. This is where we started pulling little ideas off the shelf - some mine, many theirs - but a design needs rules, some rubric to tell the good ideas from bad. For instance, one of the awesome things about our space is all the great windows and the views they provide. It was important to me that every person be able to get natural light (which is in short supply in Portland) and to have part of that view. This is one area I wouldn’t compromise, but there were many other hard constraints, for reasons of style, cost, or good old Newtonian physics. We captured all of these, and used them to quickly reject ideas that didn’t fit, no matter how great they might have seemed.

We still didn’t have a design, but we had a direction, and a bunch of constraints. Crucially, the whole team had them, they weren’t just some black box between my ears.

It turned out that this was enough of a platform that the team could quickly generate, tune, and reject new designs, so their creativity was opened wide, and my feedback on their ideas made sense. Once the framework was explicit, it became easily extensible. Suddenly discover a constraint you care about but haven’t shared? Add it to the list. Reevaluate your design with the new rules. Done.

They built a beautiful office. Yes, there are some details I lay claim to, and there are a couple of areas where I put my foot down on high-level design components, like open stairways between the floors, but this is their design, their awesome work space.

As I reflected back on how successful this partnership was, I knew it was a teaching experience. You learn far more from successes than from failures, and most of my attempts at this kind of partnership had failed.

Obviously, a big part of it was just how well we were able to partner. You can’t force this. Corey and his team trusted me and knew they had to deliver something I loved, and I trusted them, knowing that they were great at both the creative and implementation aspects of their jobs.

The framework that grew from this partnership enabled the team to do great work, work that I loved. I think I’m most proud of just realizing how special the experience was, ensuring I took the time to understand why. That investment provided a tool I’ve been able to use in almost all of my subsequent work as a leader.

My single most important role as a leader is to describe the direction I want to head, and if at all possible, I need to explain why. A lot of leaders can’t or won’t cover that, and frankly, lots of people have done great work without ever knowing why they were doing it. I agree with Simon Sinek, you’re a better leader if you Start With Why, but you don’t meet the basic qualifications of a leader if you can’t at least point the team in a direction.

That’s not enough, though. The gap was why I often found myself saying the equivalent of, “No, a different rock.” Working with Corey and his team taught me the importance of expressing the constraints, not just the direction. These allowed the team to take ownership of the design, which was absolutely critical to unleash their best work.

This framework of communicating direction and constraints provided necessary separation. I could step away, stop being in people’s faces and checking their work, and they could go off to their lab benches and iterate in peace, knowing both that they could quickly see if they were close, and also that if we had some sort of problem, we had something we could tune and evolve.

In the other big projects I’ve had since then, such as rebranding Puppet, designing new products, and hiring executives, this framework has helped immensely. With it, I am a better leader, and a more pleasant leader, and the teams I worked with do better work, faster. And we all enjoy the process much more.

When It Comes to Culture, You Can Be Right, or You Can Be Successful

luke@lukekanies.com (Luke Kanies) — Tue, 09 May 2017 00:00:00 +0000

Apply the lessons of product design to your company culture

Originally published on NewCo Shift

Every founder understands the importance of culture in the long-term success of their company. Yet rather than valuing and supporting all employees, organizations like Uber still manage to build a toxic, poisonous one. How does this happen, and what can you as a founder do to prevent it?

We’re still in the early days of understanding how to build great culture. However, the barriers to doing so are surprisingly similar to another area where we’ve come leaps and bounds in the last decade: Creating great products. The similarities in their problems mean the tactics for solving them should be portable, too. In both cases, the barrier is essentially:

You’re creating for someone else, and they get to decide whether you succeeded.

Your opinion matters, but only as part of the feedback loop between your work and the outside world. Eric Reis and Steve Blank have done a great job of teaching us that facts live outside the building, and the real test is to go find them. You can’t rely on your own perspective, because you’re not the ones deciding whether to buy.

A product solves a specific problem for a specific customer, whose perfect solution might fail the very same problem on another person. When it comes to testing your product, the only experience that matters is that of your target customer. Failing them is failing full stop.

Your culture has the same need to dial into your audience. As the founder, it doesn’t matter what you think of the company’s culture. It’s not for you. But for better or worse, you do get to decide who your culture is for. A lot of these failures of culture are actually the CEO making bad decisions about who the culture is for.

For example, we all know stories of toxic employees driving other people out of the company. The excuse we hear is that this person is “too important to fire.” It’s presented as a choice between firing this person or making some people uncomfortable, in which case it’s easy to keep this high performer around. But that’s not actually the choice you’re making.

When you choose not to fire someone who harasses women, what you’re really saying is, “This person is more important to my company than women are.”

You’d rather your organization and leadership discriminate against women, have them leave your company, and have your people and teams suffer all the psychological damage that results from choosing to protect one person over a whole class of people.

It’s the same for an employee who discriminates against minorities, veterans, disabled people, or any other group. You can keep that one person, or keep the ability to hire from that entire labor pool.

Of course, that toxic person won’t actually prevent you from hiring from a whole group. That would actually be better in the long run. Instead, you’ll hire a few, but they’ll only stick around long enough to be almost valuable to you. People who stick around for one to two years are incredibly expensive - but your toxic employee will cause them to leave. You get to pay to recruit and replace them, to train them up, to watch teams form, and then to watch them fall apart again. And again. All because you couldn’t make a hard call on one person.

Conveniently, you’ll then be able to look back after a couple of years and say that these people who left just didn’t fit in, as though it’s somehow their fault that you’ve designed an organization that excludes them as target users.

I think there’s a strong moral case to made for inclusion, but you don’t need it. All you need is basic economics. Great people are scarce, and every group you exclude reduces that pool even further. Your investors want you to have the biggest possible user base to increase your addressable market; don’t you also want the largest possible employee base? Women are 51% of the population, and in the US, whites make up 72% of the population. If you only hire white men, with maybe trifling exceptions, then your target market is only 36% of the country. Reduce to just the working age population, and you’re at 22% of the pool. And that’s before you slice for experience, location, etc., much less silly requirements like a degree from an elite school and experience working at Google or Facebook. Every demographic you exclude reduces your possible employee base, and with it your chance for building a great business.

Let’s say I’ve convinced you. You have to design your organization to include other groups. Now what do you do to ensure it’s working for them?

Again, the facts live outside the building. Even worse, as the founder you don’t get the truth. Most people do not speak truth to power because they either feel unsafe, or actually are. Even worse, most powerful people don’t want to hear it. This attitude helps explain why a lot of cultures are so broken. You have to fight your instincts, your comfort, and often, your happiness to get the truth from those who own it.

In the fall of 2014, I had dinner with eight women who worked at my company. This was my most difficult experience as CEO. They were pissed off. Their experience was very different from what I thought was happening, and hearing it directly from them hurt.

I realized in hindsight that I’d made the tactical mistake of collecting the most upset women in the company - getting together with everyone who was having the worst experience- but that didn’t make their experiences any less valid or their feedback any less important.

Thankfully, I was aware of some aspects of what they were struggling with, and I was able to point to three separate projects I was working on, all with defined goals, owners, and deadlines, that would target what I thought were the biggest issues. But I had not realized how bad it was for them, and I was far from achieving my own goals in this area.

My behavior as a result of that dinner would make an explicit statement about who my company was for. I could have taken that deep pain, that searing discomfort, and run from it. I mean, I didn’t experience any of that, and all I had was these whiny women who had this problem. Right?

Would you accept that with your product? Would you dismiss the feedback of eight customers who were on the verge of dumping your product? Would you look at their feedback and say, well, it’s just eight whiny users, I can ignore them?

Many founders choose this path in culture. They keep around the bad managers, the toxic star player, or the oppressive HR policy. But like with your modern software, you have the opportunity - and I say the obligation - to do better.

So go, build your best culture, set high standards for your team. But be very clear about whose feedback you rely on to test whether you’re meeting those standards. If your goal is inclusion and diversity, which it absolutely should be, then you need to listen, really listen to diverse voices, and to those who are systematically excluded from most organizations.

If you can do this, you can emulate the Dodgers hiring Jackie Robinson and the Sorbonne University promoting Marie Curie as the first woman professor of general physics. If not, you will find yourself competing with them instead.

The High Cost of Fitting In

luke@lukekanies.com (Luke Kanies) — Tue, 02 May 2017 00:00:00 +0000

They say authenticity is the key to success, and once you can fake that, you’ve got it made. My experience says it’s not quite so simple.

Originally published on NewCo Shift

When I was 23, I was hired as a system administrator for the first time. I joined BlueStar Communications, which was a young but well-funded company stupid enough to take on the incumbent telecom carriers. Their CEO was a maverick, especially in staid telecom in Nashville, Tennessee. He was bringing always-on internet to small businesses in the southeast (yes, there was a time when this innovative), and blended in about as well as a hockey player in a three piece suit. I was excited to work with someone who I could identify with, and learn from.

He was fired the week I started.

Like the founder of BlueStar, I’d had my own struggles with long tenures. I was fired from a cabinet company after only a week. I lasted a full three month contract at Adidas before having it ended the day I left to visit family. I also lasted only three months in QA and Mac administration jobs.

For all of these firings - except maybe the cabinet shop, which bored me to tears - I wasn’t bad at the work, I just didn’t fit in. You could say I wasn’t really housebroken, that I didn’t know the rules of how people acted in American corporate environments.

All of my prior work experience was remodeling houses with my family, after growing up on a commune. I had no idea what made people normal, I just knew I was missing it.

These failures inspired me to work harder at being worth keeping around, but in parallel I started learning to look like I knew what the rules were and was at least trying to follow them. For someone who only a few years earlier walked around campus with knee-high boots, a spiked leather jacket and a mohawk, this was no mean feat.

This experience with firings was a huge influence when I started Puppet in 2005, six years after I met the CEO of BlueStar. I bootstrapped the company for more than four years, partially because I failed to find an investor I trusted to keep me in the CEO role. The first term sheet I ever received was on the condition that I accept a friend of the investor’s as CEO. (I declined.)

As I grew the team, things got more difficult. One of the first people I hired immediately declared his greater fitness for the CEO role, with zero relevant experience, and tried to convince others to oust me from the company I’d built and they’d just joined.

Yes, I was paranoid, but they really were out to get me.

From my first hire through raising $87m in funding and growing to nearly 500 employees, I could never get comfortable. Everyone I worked with reminded me - unintentionally - that I didn’t fit in, that I didn’t behave as they expected. As I grew into my role, I excelled in areas, but continued stepping in holes that everyone else could see.

The suspicion that I wasn’t faking things well enough was confirmed as I was raising a later round of funding.

Before a pitch meeting, an investor said to me “Now try to be more like a Valley guy, not so much a Portland guy.”

Infuriatingly, I knew what he meant, but also that I’d never be able to pinpoint what I was doing wrong. I worked every day on my “Valley guy” pantomime, from the clothes to the books to the words. This pointed statement told me in stark terms that my efforts were obvious failures to even the casual observer.

Knowing the world saw me as an imposter caused me to hold back. I don’t mean I had imposter syndrome; I suffered from it like most high performers do, but that’s not what this was. The world around me constantly pushed back against what made me “me”, making me worse at just about everything.

I had put myself in a box. I wasn’t even willing to consider ideas that I didn’t think the people around me would accept. I was brave, within that window. I was daring, but not too much. I could do anything I wanted, as long I still kind of looked the part. This box excluded many great options, and notably, excluded a lot of what I most wanted. My weirdness isn’t skin-deep, and a lot of what I wanted just didn’t fit, so I tried to do something that did. Thankfully a lot of it worked out, but I think it could have better, and I know it would have been more pleasant, if I had been more brave, more willing to own my lack of belonging.

It’s worth noting, this was all as someone who did theoretically look the part. I’m a medium-sized white male with a degree from a great school.

I can’t imagine how much worse it would have gone for someone who literally looked different - wrong skin color, wrong gender, wrong accent, disabled, too short, etc. Maybe that was my real problem - people let me in the door thinking I was like everyone else, and only once they started talking to me did they realize how weird I was.

Finally, after almost ten years of running Puppet, I found a way to escape this box I had put myself in. I would quit.

It’s not fair to say this was the only driver for my decision, or even that I was thinking of it this way at the time. What can’t be denied, though, is how much it changed me. I lost my fear of being fired for not fitting in, because I was working to leave anyway.

I couldn’t see the box when I was in it, but when freed, unavailable actions suddenly became doable. I could trust myself for the first time since that first hire, so my cost of decision-making plummeted. I didn’t need to look to society as some sort of arbiter of what’s reasonable.

I had been preventing myself from using my now-highly trained instincts, which reduced me to tackling easy problems or making slow, bad decisions. Or sitting there and doing nothing, which is generally an even worse decision.

Outside the box, my inductive reasoning center could operate without all the second-guessing. I was able to hire a product leader based on instinctive conviction that we were aligned on how to work. I made an incredibly tough call on hiring for Business Development, by following my thread of fear that maybe I was being pulled toward too easy of an answer elsewhere. Most importantly to me, though, I was able to develop and begin rolling out what I think is a truly great product strategy.

I did some of the best work of my life.

This experience has an interestingly conflicting lesson.

On the one hand, the cost of trying to fit in is often too high. No matter how much you want it, you might have to choose between failing at what you want and succeeding at what you can authentically do. If you’re building a team, the choice may come down to those who are great at the job and those you can work with.

On the other hand, I somehow fooled people into thinking I was normal (well, normal enough) for long enough to become a successful CEO in a field where I seemed like an alien to everyone involved. That pantomime was critical in developing the instincts I was able to apply so well as my tenure wound down, and now I have opportunities I never could have dreamed of.

I think the duality of this lesson is important in the conversation around diversity. Puppet couldn’t have existed without some tolerance for my weirdness, but it was also much harder because of it.

I’ll never know if getting out of that box earlier would have caused me to do even better as CEO, gotten me fired ignominiously years earlier, or even maybe caused the company to fail early on. What I do know is that I was deeply hurt by not facing and acknowledging my fear of being fired.

Fear is healthy and reasonable. But you have to pursue it, nail it. Understand it. Not run from it.

I am privileged to have no idea what is in store for me, and no fear at the prospect. I feel no need to fit in anymore, both because I have nothing to prove and because the cost of not fitting in is now one I can afford to pay. If anything, I’m now considered more valuable because I don’t fit the mold.

The lack of pressure to conform brings incredible freedom. Freedom that everyone deserves.

How Can I Help?

luke@lukekanies.com (Luke Kanies) — Mon, 24 Apr 2017 00:00:00 +0000

I am not a technologist. This surprises many, including a CEO I was on the phone with recently. I explained that I had no pet software projects I was working on at home, and thus couldn’t demo her software. She paused for a second, like, “Uh, why are we on the phone, then?”

It’s true that I have worked on tech since graduating from college, and that I wrote Puppet essentially alone while I bootstrapped the company for years by myself. I enjoyed the work, but those were all a means to an end, not the goal. This became more and more clear to me as I hired large teams who really were technologists. I was able to do the work, but they loved it. I naturally fell into different, complementary areas.

So no, I can’t really help your company in sorting out its software stack. Or rather, I could, but you really shouldn’t want my help there. There are better people. Far better. People have found my advice really helpful in the past, but not in this area.

Strategy is where I’ve had the biggest effect as an advisor. You are already deeply committed to your goals - you don’t need my help figuring out what to do. You are just as committed to how you’re going to achieve them, but probably haven’t spent as much energy thinking about it and expressing it. This ‘how’ is your strategy, and key aspects are decided early on, whether you mean to or not.

Do you want a big field sales force, or a self-service model? Either way, why? How does that choice affect your product price point and service attach rate? There isn’t necessarily a right or wrong answer, but a choice will be made, and it has massive consequences on the life of your company. My great ability is pestering you with questions until you’re forced to put your opinions on the table and really examine them. As a leader, your job isn’t just to be opinionated - it’s to be able to usefully express that opinion to your team.

Product is the second major area I will push you. Again, this isn’t about the tech, or the code. I don’t care how it’s built. The first step is being clear about what problem you want users to hire you for. I bet you have a decent grasp of this, but you have to go down a layer into which users you’re going to start with, how you’re going to parlay them into a larger group, and how all of that relates to adoption within a single organization and across a market. The path of a product’s adoption is as critical to plan out as the features you build.

All of that ties into how you price. How does it drive user behavior? What do you want to incentivize through low or free pricing, and what must you charge for to make your business work? How does charging per seat vs consumption vs features change their behavior and affect your business?

All of this must come together into a coherent system that pushes you, your team, your customers, and the market to focus on the right problems at the right time. You should seek my help in seeing the whole system, and especially the gaps in it. I hate software, but oh boy, do I love systems. My brain is so optimized for managing, storing, and assessing systems that I lose nouns constantly. It’s worth it, for me and for you.

I can also help you.

You’re not a coincidence. You have to understand, it’s not an accident that you’re here. Even if the only thing that makes you special is that you were the first one to raise your hand… it’s been a few years now. Because of that one little action, you’re different than everyone else. It’s up to you to demonstrate whether that difference is good, or useful, but it’s definitely there.

I don’t mean to say that you’re better, or that only certain people can be entrepreneurs. History shows the exact opposite, and I’m a huge believer in empowering ever more. What I mean is, the mere act of taking the step permanently changed you. One of the hardest acts for most founders, especially those from underrepresented groups, is believing that they belong, that they deserve to be out front. I can help you see how just sitting in the seat has led you to be a different person than you were before, led you to special insight and special opportunity.

It’s up to you, now, to make the most of the opportunity, to believe in it and to deliver on it. You have to learn how to extract that difference, to bottle it, to share it. And when to dump it down the sink.

Founders are so full of dreams that they have a hard time letting go. “It’s true we can’t do this today, but I’m going to keep talking about it in hopes we can do it tomorrow.” Your business is on death’s door and the wrong success gets you all fired, but sure, go ahead and distract your team with something you know you can’t and shouldn’t build, and that your customers would never buy.

Everyone knows founders have to make hard decisions, but most don’t seem to realize the hardest ones are about their own dreams. To build something great, you have to give up on other dreams. You can’t build it all at once. You can still hold it, treasure it. But you don’t get to talk about it. You can’t distract people with it.

You haven’t earned it yet. When your company is a massive success, and throwing off more cash than you know what to do with, that’s when you pull out your other great ideas and turn your success into a platform for experimentation. Until then, you have to focus. Let go.

Beyond all that, I enjoy working through demos and user experiences, helping people see your work through new but educated eyes, asking a thousand questions that you might not have answers to. This teaches us both a lot about you, your product, and your company. The differences between the easy and hard answers teach you a lot, too.

What I don’t like to do is tell people what to do. At most, I will share frameworks I’ve used for decision-making in the past and recommend some of them for you, but preferably, I will focus on pulling from you what you really believe, and then make you really confront it. It’s not about me. I can’t live your life. I don’t know your customers. I can’t run your company.

But maybe, with the right prompting, I can help you look at it in a new light, help you make the right decisions faster, and help you avoid some of the worst parts of this insane decision you’ve made.

It Shouldn’t Get Easier

luke@lukekanies.com (Luke Kanies) — Wed, 19 Apr 2017 00:00:00 +0000

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

luke@lukekanies.com (Luke Kanies) — Thu, 13 Apr 2017 00:00:00 +0000

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

luke@lukekanies.com (Luke Kanies) — Mon, 03 Apr 2017 00:00:00 +0000

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

luke@lukekanies.com (Luke Kanies) — Thu, 23 Mar 2017 00:00:00 +0000

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

luke@lukekanies.com (Luke Kanies) — Tue, 14 Mar 2017 00:00:00 +0000

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

luke@lukekanies.com (Luke Kanies) — Tue, 07 Mar 2017 00:00:00 +0000

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

luke@lukekanies.com (Luke Kanies) — Wed, 01 Mar 2017 00:00:00 +0000

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

luke@lukekanies.com (Luke Kanies) — Thu, 23 Feb 2017 00:00:00 +0000

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

luke@lukekanies.com (Luke Kanies) — Thu, 16 Feb 2017 00:00:00 +0000

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

luke@lukekanies.com (Luke Kanies) — Wed, 01 Feb 2017 00:00:00 +0000

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

No, You Don’t Learn More from Failure

luke@lukekanies.com (Luke Kanies) — Tue, 24 Jan 2017 00:00:00 +0000

This article was originally published on Medium.

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.

The case for the iPad’s long-term future

luke@lukekanies.com (Luke Kanies) — Sat, 24 Jan 2015 00:00:00 +0000

Based on both individual anecdotes of purchased iPads lying fallow around the house and Apple’s recent announcement that iPad sales were essentially flat year over year, some are predicting that the iPad is not the future of computing that has been predicted.

I’m not quite willing to make big predictions about computing overall, because I really hate being wrong and there’s no real benefit here in being right, but I couldn’t be more confident in the iPad’s future, and it’s not an argument that I’ve heard widely.

TL;DR: The iPad already has great successes, and just by itself those will do well. Most of our apps and workflows haven’t been rebuilt from the ground up for the iPad, though, so we’re not getting the best from it. And there is a great market opportunity in the millions of iPads that are underutilized, and the first app developers that crack that market by playing to the iPad’s strengths will make it big and create an even bigger pull for the iPad through those successes. If you love a computer, the iPad’s not for you, but it’s definitely for someone.

Longer version:

First, let’s look at where the iPad is successful. And I don’t mean, let’s look where it’s purchased; I mean, let’s look at where its users actually get fantastic usage out of it. If this usage is small and meaningless, it doesn’t mean the iPad is meaningless, but it does limit past data in usefulness for predicting the future. But if that success isn’t meaningless, it points to possibilities.

It’s absolutely true that the major use cases for the iPad are in consumption, not production. Weirdly, the vast majority of what humans do, in general, is consumption and not production. I receive 230 emails a day and send 30, on average, so an iPad that was 10x better at managing incoming mail than sending new mail might work better for me than a laptop (depending on how I rate its relative strengths).

People have found the iPad is great for watching videos, reading - books, magazine articles, comics, twitter, and more. People dismiss the iPad for this - “consumption isn’t as important” - but the reality is, your laptop sucks at consumption. Reading magazines or books, watching TV, and reading twitter are all pretty much crap on the laptop compared to the iPad. Yes, you can do it; no it’s not as good.

So, if the iPad were just relegated to being the best enabler of consumption, I think it would do pretty well, since it would also leak over to not-quite-consumption, like trawling the internet for great pictures to post to Pinterest. This might not be the super-exciting future, but I think it’s still a better business than I could think of building.

Beyond consumption, though, there’s another big area it’s doing well: Replacing computers for people who don’t have computers. I’ve personally given away about 15 iPads (this is just for personal stuff; I’ve given away more for work, including 12 of the very first iPads to all the employees I had at the time), and for most of those, they didn’t have a computer, and for most of those, they now don’t need one. Of course, many of the iPads were to young kids, aged 5-10, by those kids will get most of the benefits of a computer without needing the complexity of a full computer.

It’s not just kids, though; my dad could use the computer he shared with my mom, but he never embraced it. He has been literally emailing me weekly about how giddy he is to go to a coffee shop and write email on his iPad. He didn’t feel comfortable doing this with the laptop, but he loves it now. He’s by no means the only person I know who either doesn’t own or doesn’t use a laptop because they now have an iPad.

Everyone who needed a computer already has one, but not everyone has a computer. Many of those who don’t need a computer also don’t need an iPad, and maybe a smartphone is perfect for them; but the group in the middle, who don’t need a laptop but for whom a smartphone isn’t sufficient, could really thrive on an iPad.

Just these two successes are a great business, if not necessarily a 100% growth business indefinitely. But there’s a lot more.

The next thing that gives me confidence in the iPad is how few of our tools have been rebuilt to work with an iPad workflow. Most of what I try to use on the iPad is an attempt at porting either iphone or laptop apps. That can work, but it won’t automatically. I often use a keyboard for my iPad, but essentially nothing has good keyboard shortcuts, for instance; I would never tolerate this in a laptop app, but it’s not really a choice on the iPad (for now).

I don’t know what it will take to rethink my critical apps and workflows to work on the iPad, I just know it hasn’t been done yet. And yet, even without that, it’s literally my favorite computing device by a mile. I use my phone constantly. My laptop is a workhorse. But I love my iPad. Every time I pick it up I can feel the future of computing just fighting to get out. There are so many little bits of my iPad life that need to be shaved, molded, tweaked, cut, poked, prodded, or beaten to a pulp; when that happens, we’ll be in a whole new world.

The world just hasn’t been creative enough yet to figure out how to take advantage of what the iPad can do. Remember: This thing is only a few years old. It might be 10 years before we really figure it out. That’s not an iPad failure, though; that’s a market failure. There’s a lot of creativity yet to do.

It’s that market failure - which I feel keenly every time I pick up my iPad - that really closes it for me. The iPad has an amazing future because there are fifty million people who pick up an iPad with hope in their hopes, dreaming of the awesome things this can help them do. Today, too many of them are disappointed with the answer. But tomorrow, they’ll pick it right back up again, with hope in their eyes once more. In the mean time, Apple will continue to sell a ton of iPads. Maybe it will only cough be twenty million a quarter or whatever, but that’s still a big market.

I am very confident that that market opportunity will push people to invent new ways to excite those users. Yeah, everyone’s currently trying the obvious, stupid stuff: “Hey, let’s just make a crappy html5 version of our web app” or “Hey, let’s just upscale our iphone app”. That’s not really working. Something, however, will work. Imagine the iphone if Loren Brichter hadn’t gotten ahold of it and invented and created as much as he did. You can’t force that, but with enough people trying, and enough clear demand, it’ll happen, and it’ll change the way you use your iPad.

I hear a lot of people say the big barrier is cross-application communication, but I think a lot of that is trying to copy the strengths of the laptop to the iPad, which might not be how the iPad comes into its own. You don’t use your phone to do things you used to do on your laptop (at least, not primarily); why would you use your iPad for that?

I’m not sure what strengths of the iPad will come to the fore in a way that makes it its own device, but I have some ideas.

As an example, people totally undervalue the fact that it doesn’t go to sleep. Just comparing email on an iPad to a laptop, there isn’t a great email client for the iPad yet that I have found (and trust me, I’ve looked; I’ve got at least seven mail apps installed on my phone), but I like a lot of the core email experience on the iPad dramatically more.

Most of the time I check my email I’ve got about 15-30 minutes. My goal is to delete, send to my task list, or reply to as many emails as possible. With my laptop, I either need to leave it at my desk all day, or when I open it I have to give it some time to find wifi (or get an IP from ethernet), then download all of my mail. This could take 30 seconds, but with Mail.app (don’t ask), it could also take 15 minutes. Yes, it would be better with gmail, but it wouldn’t be instantaneous.

Let’s compare that to the iPad. It’s always on. It’s always online, because I’ve got an LTE chip in mine (I’ve had every version of the iPad since the very first, and every one with a mobile modem since they supported them). So, I open my iPad, boom, all the mail is right there. No wait, no IP acquisition, not downloading mail. Done.

Let’s take this to the extreme case: I often travel with just the iPad, and I use it in ways I couldn’t use a laptop. I get on a plane, put my iPad into airplane mode, and when I’m aloft I start processing email (with a keyboard). The email is right there, already downloaded, ready to go. When I land, I turn off airplane mode, and the email just sends; no work for me.

The same work on my laptop requires that I sit down at the terminal, pull out the laptop, pair it with my phone or iPad (or gamble on the airport wifi), wait the who-knows-how-long until Mail.app syncs with gmail, then put everything away. When I land (having probably done slightly more work in the 1.5 hr flight I usually take), I have to do the same thing: Find a chair, open the laptop, pair with device, wait until the 20-50 emails I wrote on the flight get sent. I’ve spent a long time on the freeway with my laptop open and connected to my phone, trying to upload mail.

Total iPad win. The laptop might support this at some point, but it’s just not built to literally be online 100% of the time. This plays to the strengths of the iPad, and will be hard to import anywhere else.

What else plays to this strength? I think there are tons and tons of areas that could benefit from being online 100% of the time, and you can see most of Apple’s development work is in improving this so apps can stay open more, download more often, be more up to date, etc. If my iPad evolves so that every app on it always has its content up to date, but I can never build a mixed-media blog post, well, I would take that trade.

Just think about the iPad-specific interfaces and experiences that have built. Hmm. There aren’t a lot. I know of some that have tried, like iPhoto, but many of them have been not so great. The only ones I can think of that really work are the app-switching moves: Four finger swipe for app switching (which works poorly because I can never figure out how the device orders the apps), and the five-finger app close gesture. For a completely new device and form factor, that’s not much real innovation in interaction.

The point, though, is I don’t need to know what happens next. I just have to be confident that the market opportunity of tens of millions of underutilized iPads in the hands of excited people who have proven they’ll spend money on technology will draw enough experimentation that we’ll get to see the true innovation. This is a young product, and it’s a product that’s sufficiently similar to others that people haven’t really let it grow into its own. There’s enough money and interest in the system, and enough truly awesome parts of the iPad experience, that I’m absolutely confident it will.

Too many people are saying the iPad is a dud because they’re a computer user and their usage doesn’t translate well to the iPad. They’re not approaching the experience with a beginner’s mind, and are instead saying, “I know it’s a new device, but it should do exactly what the old one does.” One of the commentators on the Accidental Tech podcast seems to have set “create a mixed media blog post” as the critical success criteria, but I bet less than 1 in 10000 computer users, if that, ever actually need to do that. Even when I blog, I just do straight text. Hell, I probably include more code snippets (well, used to) in my posts than pictures, but I’d be crazy to make that a requirement, because I understand the iPad’s market isn’t me.

To that commentator, I would recommend they go read Innovator’s Dilemma. Disruptive technology is rarely used by the users of the old technology. The laptop, or desktop, or whatever, makes you happy. Great. The iPad’s not for you. It’s for people who don’t need what you need, and are satisfied with a much simpler solution with some kinds of power that are greater, and the reduced complexity is a critical part of its success. (Really, read Innovator’s Dilemma.)

And seriously, if you’re getting an iPad, and you can afford it, get it with an LTE chip. It dramatically changes the experience. I couldn’t live without it. And don’t say I can tether it. Not at all the same.

My recommendation is, don’t ask what it would take to cause you to switch to an iPad. Ask what you aren’t doing today that you’d like to be able to do. Ask who isn’t using a computer and could be. Ask how the world will change when every device and every app is online all the time. Wonder what kind of gestures will dramatically increase the power and intuitiveness of the iPad. And see if you can’t come up with an app that will make those fallow iPads just that bit more sexy.

Writing on Luke Kanies

Building on ATProto

Start With Reviews

Local First Data

Public and Private

What does this have to do with ATProto?

One last local-first note

Conclusion

AI Is Like a Crappy Consultant

Those Great New Calendar Tools Probably Won't Help You

Do I Hate Investors?

Why was I fundraising from VCs?

VCs are gatekeepers

Hate the Game, not the Player

Will I do it again?

My Monopolies

The Paradox of Antitrust Choice

Tech is not special

The “consumer welfare” standard is not the law

Revisiting Consumer Welfare

The Tech Monopoly Minefield

Conclusion

Designing Tomorrow’s Privacy

The Business of Privacy

The Cloud Conundrum

My Bet on Privacy

Don’t Make Board Decks

Entrepreneur, Stage 1: Bootstrapping, Burnout, and Babies

Burnout Strikes

Getting Help

What it all means

The First Two-Million-Dollar Check

How TechCrunch is like the Iliad

P-Hacking in Startups

What’s wrong with science?

The how and why of P-hacking

From social science to startups

You got caught p-hacking

How do I fix it?

So my data is now worthless?!

The Automator's Dilemma

My Losing Battle with Enterprise Sales

A Writing Report: Two Years In

The Rights You Lost When the Document Died

Follow your weird

Review of the 2018 iPad Pro

How I fell in love with the iPad

The iPad today

Now, about that new iPad

Conclusion

We Were Promised Flying Cars and Five Hour Work Weeks

Great advisors reveal your truth, not theirs

Hold on to your why

Owning My Strava Ride

How to Neg a Founder

An alternative crypto-history

Filesystems, version control, and the blockchain

The virtue of a tool

Several short sentences

Decentralize Your Data

What does owning your data even mean, and can the Blockchain help?

Trusting more with the blockchain

Blockchain without Blockchain

There is powerful technology hidden in the blockchain. Just strip out the parts everyone cares about

The power of better tools

There is a solution to wage and productivity stagnation. Just don’t call it automation

The Market Is Wrong About Your Problems

What Voltaire and the Flaw at the Heart of Economics Have to Teach Us About Software That Doesn’t Exist

Owning my writing

It’s the message, not the medium

Why We Hate Working for Big Companies

Modern capitalism raises the flag of the free market while pitting centrally planned organizations against each other

Abandoning Trello

On the value of change and focus

Great design is ruining software

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

Putting OKRs Into Practice

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

Startup Days

Scaling