The Rights You Lost When the Document Died

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 Pages1) 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.2 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.3 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.

  1. 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.
  2. I was on team break-up.
  3. I can’t believe you forgot mine last year.

We Were Promised Flying Cars and Five Hour Work Weeks

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 wood1, 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.

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

Hold on to your why

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

Photo by Sharon McCutcheon

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

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

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

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

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

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

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

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

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

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

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

Bullshit.

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

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

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

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

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

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

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

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

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

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

The Morality of a Good Tool

Tools just get the job done, but products demand something in return

Photo by Todd Quackenbush

I love tools, the effortless balance of a well-known hammer in my hands, knowing exactly how to hold it and what it will do. Starting out clumsy is never fun, especially with the tools that crush fingers or spill, but I adore that feeling of developing expertise. It’s hard to conceive of a tool without also thinking of the experts who use it. I secretly wonder if I deserve most of the tools I have.

“That’s a mighty fine hammer you have there, but unless you can show me the callouses from using it, we’re going to have to confiscate it.” Home Depot would make a lot less money if we had to prove we got good usage out of the fancy stuff we buy.

This mythical tester doesn’t have to stick to checking you out. The tools themselves prove it when they’re not just for show. Knives shrink with sharpening, work pants thin, machines drink oil.

This is a feature. Preciousness is the antithesis of a good tool. “That knife is too expensive to use every day.” Ugh. Not my tools. I’d rather break something on the first day than be afraid to use it in real life.

Tools should be scratched. Dented. Aged. Their callouses should pair yours. You and your friends should huddle around your tools, bragging about whose has the better patina. Precious tools are just toys, decoration. They live on a shelf, or more often in the attic, not on your work bench, by your side. In software form, they are so well designed they don’t even function.

Tools only deserve the label if they help you work. Given that that’s the heart of what motivates me, it’s natural I want to build tools. I’ve been madly rushing toward a plan to do so, but was recently pulled up short by a simple question: What do you mean by tools?

I really hate the easy questions.

This was put to me by Jordan Hayles of the Radical Brand Lab. The bit above is one kind of answer, but as I thought about it, it became clear that it’s insufficient.

I’ve been saying I want to build power tools for people. Why not power products? That’s a motor boat of alliteration: ‘power products for people.’ Awesome, right? Right?

Ok, maybe not.

Part of my choice of phrase is that I grew up building houses, and ‘power tools’ just meant the things you plugged in. You know? Because they needed power? It’s a common usage, maybe my 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 other founders. Just a few more years and I might have some clue what I’m doing. 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, getting that blue color shine? Mere cynicism about the software industry?

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. I mean, not all at once. You’ve got to package it, price it, 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 items, but not because it’s soap. The strong brand makes it easy to sell, even allowing it to be used as a stand-in for money in drug deals. Shows just how far I have to go in product management. Unfortunately, it says nothing about the soap.

Inkjet printers are an example of this gone wrong. Laser printers, their predecessors, had toner cartridges you could refill. Not very clean, but cheap and reliable. The printers themselves were so expensive that this worked out well for everyone. Inkjet printers are instead fantastically cheap, and most people who buy them rarely use them so demand a very low price.

Printer manufacturers have found a way to make up for the money they have to give up in the initial purchase: Disposable cartridges. Initially these were just a consumable, an extra revenue stream, but over time, companies started putting more rules in place to prop up the cartridge prices, and to ensure all that money went to them, not third parties: You had to buy them from the manufacturer, they had to be replaced every year, you could not refill them.

This hurts the user in the name of making money for the vendor. People are unhappy enough about it that the US Supreme Court had to weigh in.

That’s good product management. Well, evil, but you know what I mean.

Reasonable people might disagree on the wisdom of this approach, but it begins to reveal a distinction between the simplicity of “tool” versus a more complete “product”.

When I think of a tool, it is uncomplicated. 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 where or when I bought it. 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 people. (Just mentioning the colors probably caused you to visualize these companies. Branding works, even for tools.) 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.

A product, however, exposes you to its business model. 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. Those differences obviously impact price, and how you use the soap.

Tools now become a kind of counter-point, a better offer:

It helps you do your job, and makes no demands of you in return.

I know how DeWalt and Mikita make money, but I don’t think about it when I’m using their tools. I can comfortably recite that my canonical hammer is the Estwing 22oz waffle head with a straight claw1, 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. “It’s just a tool.” You can see this as belittling, insulting, but it does not have to be. It’s also a statement of choice. Of freedom.

Products have an implicit, ongoing dependence on their vendor. As that vendor, this works well for me: 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. But it’s not always a healthy relationship. These interactions often shift from helping you to sustaining a business model, as they did with inkjet printers.

When I say I like tools, I’m rejecting all of those interactions. I want something self-contained. Independent. Usage is a pragmatic decision, not a lifetime commitment.

That independence has downsides for founders. 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 forced to experience my business model, and their absence means my business is harder to build, to protect.

One might argue in return I’m better off because I treat my customers with more respect, and I’d probably agree. I think this is often the right answer, but it’s not a popular one. I might be accused of not “wanting to build a real company,” or I might be insulted in the most dire way possible: “That’s just a lifestyle business”.

Tell that to Adobe. And AutoDesk. These companies are built on their tools. They are the behemoths we know today because they knuckled down and solved their customers’ problems. It was a different time, but people have not changed.

I don’t think that every product is compromised when the customer experiences the business model, but I think most are. Some of it is laziness, knowing you don’t need to finish because your product will cover for you. But a lot of it is strategy, recognizing the value of a product over a tool.

I want to build tools.

  1. 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.

How to Neg a Founder

Is that a compliment, or an insult?

Photo by John Salvino

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

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

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

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

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

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

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

Why We Hate Working for Big Companies

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 support1. 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.2

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.3

The most important feature of free market economies is that each person within them is able to make independent decisions in their own best interests4. 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.

  1. Although I might stress the “well regulated” part more than most modern economists.
  2. Of course, capitalism is just as capable of killing its citizens, whether through starvation or lack of health care.
  3. 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.
  4. But not so independent that you should be as pathological as Ayn Rand.

Great design is ruining software

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Putting OKRs Into Practice

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

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

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

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

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

Here’s how we did it.

Startup Days

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

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

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

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

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

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

Scaling

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

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

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

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

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

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

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

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

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

What might come next?

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

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

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

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

Conclusion

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

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

Where does your work live?

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.