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.
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.
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.
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.
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.
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.
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.”
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.
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.
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.
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. ↩
Look, I have to say it: You’re weird. Even if I don’t know you, I’m confident: Somewhere, maybe lurking deep inside, something about you is just not right. I don’t know what, specifically. For all I know, you might be one of those weirdos whose particular strangeness is just how authentically normal you are. shudder.
This might be insulting to you, calling you weird. It happens a lot: I think I’m complimenting someone and they get all huffy. Conversely, people are often afraid I’ll be hurt when they shyly let me know that I, ah, don’t really fit. Don’t worry; you’d need to know me a lot better to successfully offend me.
Society is not a huge fan of weirdness - I mean, the definition is pretty much, “does not fit into society” - and it trains you away from it. We’re social animals, so you probably do what you can to conceal, or at least downplay, anything different. It makes sense. It’s a basic survival mechanism.
I know I do it. I can’t hide everything - some stuff just can’t be covered up - but I can usually skate through a conversation or two before people back up a step and give me that funny, sometimes frightened, look. Being on the west coast helps; I’m a little less weird here than I was in the south. It probably also helps that I cut my mohawk, and the spiked leather jacket and knee high boots stay in the closet now.
I’ve written a bit about my struggles to balance authenticity and fitting in. I think it’s important to call out it out, because those who experience this struggle rarely have the luxury of admitting it. I’m lucky enough in multiple ways that I can be up front about it now. But resolving this conflict matters for more than psychological reasons. Our own goals usually require that we learn to embrace our weird. Not just grab on to it, actually, but really live in it. Inhabit it.
That weirdness is how we win.
This is easiest to show in investing. We have a natural tendency to do what is proven to work, but that is only assured of getting “market” - in other words, mediocre - returns. If you study the best investors, they’re all doing something that seems weird. Or at least, it did when they started. The first people who paid to string fiber from NYC to Chicago to make trades a couple milliseconds faster were considered pretty weird, but they knew the truth: Normal behavior gets normal returns, anything more requires true weirdness. (Well, or fraud. There’s always that if you’re afraid to stand out.)
It’s the same way in life. You can’t say you want something different, you want to be special, but then follow the same path as everyone else. “I’ll embrace what makes me special just as soon as I get financial security via a well-trodden path to success.” Oh yeah. We definitely believe that.
There’s a nice sleight of hand you can do, where you can say you’re doing something different, but really you’re a rare form of normal. The first few doctors and nurses were really weird. Those who recommended you wash hands before surgery were literally laughed at, considered dangerous crackpots1. But now? Most people become a doctor in pretty much the same way. Being a doctor is normal now, even if it’s not common. That’s probably good.
But what if your job is innovation? What if you’re whole story revolves around being different? Can you still follow a common path?
Because that’s what too many entrepreneurs today are doing: Trying to succeed at something different, by doing what everyone else is doing.
I mean. Not literally everyone else. But close enough.
It starts out innocently enough. There aren’t many people starting tech companies at first, and boy howdy are they weird. Someone makes a ton of money, all their weirdness gets written up - “hah hah, see how he has no sense of humanity but is somehow still a billionaire?” - and now we’ve got something to compare to. Hmm. Well. We can’t consistently duplicate Jobs, Gates, Packard. But if we tell enough stories enough times, we find some kind of average path through them. Ah! Enlightenment!
Now that we know what “most” people do, we can try it too. I mean, we have no idea if the stories about those people have anything to do with why they succeeded, but why let that get in our way? Conveniently, every time it works we’ll loudly claim success, but silently skip publishing any failures. Just ask Jim Collins: He got rich by cherry-picking data in Good to Great to “prove” there was a common path to business success. It turned out to have as much predictive value as an astrological reading, and is just business garbage dressed up in intellectual rigor, but that doesn’t seem to have hurt him.
The business world keeps buying his books. They need to believe there’s a common path that anyone can travel to victory. Otherwise, what would they sell? What would they buy?
Obviously this doesn’t work. There is no standard playbook to winning an arms race. Once there’s even a sniff of one, people copy it until it doesn’t work any more. This is pretty much the definition of the efficient market hypothesis: There’s no standard way to get above-average results. Once Warren Buffet got sufficiently rich as a value investor, so many people adopted the strategy that, well, it’s hard to make money that way. Not impossible, but nowhere near as easy as it was fifty years ago.
Of course, you can go too far in being weird. There has to be something in your business, in your strategy, that makes you different enough that you just might win. But adding a lot of other strangeness for no good reason worsens already long odds. The fact that Steve Jobs did so well even though he was a raging asshole, even to his best friends, made his success just that much less likely. Most people are a bit more like Gates and Bezos: Utterly ruthless in business, and caring not a whit for the downsides of their success, but perfectly capable of coming off as a decent person whenever required.
I’m rarely accused of being a world-class jerk, but I don’t pass the smell test as normal for very long. Jim Collins might say maybe if I were more pathological I would have succeeded more. With Jobs and Musk as examples, it seems reasonable, right? In truth, it’s just as reasonable that I would have done better by dropping out of Reed College, like Jobs did, rather than foolishly graduating from it. Think it’s too late to retroactively quit early?
Yes, you have to learn to love your weird, but it shouldn’t be arbitrary. You can’t realistically say that you’re going to rock it in business because you’re addicted to collecting gum wrappers from the 50s. I agree that that’s weird, but is it usefully so? Being a jerk is weird, and bad, but it’s not helpfully so. And really, dropping out of college isn’t that weird for someone in Jobs’s financial position at the time. It’s only if you have a bunch of money that it seems so.
I recommend you take the time, think deeply on what opinions you hold that no one else seems to, what beliefs you have that constantly surprise you by their lack in others. What do you find easy that others find impossible? What’s natural to you, but somewhere between confounding and an abomination to those who notice you doing it?
Those things aren’t all good. And in many cases, you’ll need to spend your entire professional life managing their downsides, like I have. But somewhere in that list is what sets you apart, what gives you the opportunity to truly stand out. They’re the ground you need to build your future on.
Unless you just want to be normal. In that case, I don’t think I can help you.
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. ↩
Being an advisor to other founders is a contradictory affair: Be helpful, but do not give advice. That is, I want to help you do your best work, but I don’t think I can or should do it by telling you what to do or think.
I obviously think I have value to add or I would not sign up to help. Well, maybe it’s not obvious; our industry is rife with advisors who attach their names and little else to projects. It’s true I’m motivated to join partly by the possible long-term reward, but mostly I’m helping because I enjoy it and am learning a lot.
While running Puppet, I was constantly confronted with a classic leadership struggle: How do I simultaneously help people improve their own answers, yet get them to do what I want? There are many who will say this is a false struggle, that I could have avoided it by focusing on empowering people instead of trying to get them to do what I wanted. Pfft. The literal definition of leadership is providing direction and getting people there, and that’s doubly so for a fast-growing startup where alignment is critical to execution. I spent a decade slowly, incrementally, getting better at this, but felt my incompetence as keenly at the end as I did at the beginning.1
Advising companies allows me to practice the empowerment-half of this skill without the other complications. Unlike when I was a CEO, I know I should not be setting direction or making decisions. My job is not to provide answers, but to help people do their own best work.
My only explicit training for this was when I was an organic chemistry lab tech in in college. My primary task was repeating questions back to the students: “I don’t know, which layer do you keep?"2 When I started dating my now-wife in college, she told me her friends were bitter that I would not give them answers. I knew my job. I was there to help them get an education, which required they did the work on their own. This has also been helpful experience for being a parent: “I don’t know, what is 12 times 9?”
Advising CEOs has similar constraints, but it’s a lot more open-ended, and has no answer sheet. In the lab, there was one right answer, it was always the same, and you could reason it out with the information at hand. Labs were also usually a day of work, maybe three days, and mistakes were pretty cheap, in the grand scheme of things. I don’t expect one of those students to track me down later in life and lay at my feet all of their struggles or successes. Most importantly, we were studying an objective space that I did actually know more about. When push came to shove, I knew the answers, and I could reason out anything that wasn’t obvious.
Helping CEOs is considerably harder. I’m rarely asked about questions that have a single right answer. No competent CEO would bother getting advice on an easy question, or one whose answer wasn’t important. Wrap into this the fact that I can’t possibly know the company as well as the person asking me the question.3 It’s inconceivable that I would often have answers available that the expert in the seat doesn’t.
That simplifies the challenge: Prod the questioner into getting to their own answer, no matter how much they complain. And they do sometimes get upset: I had a CEO exasperatedly demand what I would do, after a long session of forcing him to work through what he cared about, what he saw as the right answer. When I relented - only after he had already done all the hard work - he could see how thin and useless my answer was. By the time he’d decided what to do, he saw that what he learned from the process was at least as important as the answer, and my just providing a solution could never give that.
There is still some risk. I’m by no means a master of this technique. I know I have at times presented people’s options in stark ways, which sometimes felt like no choice at all. My own predilections, such as toward a consumer-style sales model, are hard to separate from any guidance I might provide. It’s honestly just hard to know sometimes whether you’re successfully getting someone to express their own implicit belief or leading them to agree with one of yours.
It’s a skill I expect to spend the rest of my life trying to master. But it’s worth doing, and I’m enjoying the learning process.
Helping CEOs instead of running my own company provides a kind of repeatable laboratory environment. I get to learn at the same time, though, because it’s much harder than being a lab tech.
It’s not enough to just parrot questions back. I spend my time listening closely and drawing out more information, then replaying back what I heard. Listening is a woefully underrated skill. I’ve been loving the opportunity to practice really hearing what people are saying, and trying to differentiate between the words they use, the meaning behind them, and their intent in saying it at all.
As you look for advisors, be sure you demand the same discipline from them. Don’t accept answers. They should hear you, understand your dilemma, and be able able to point out where you haven’t thought completely, or clearly.
A great advisor should provide light, not direction.
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. ↩
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.
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 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. 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. ↩
I’m a tech founder and recovering SysAdmin. I helped found DevOps and grew up in open source. These days I am convalescing from a decade of physical and mental neglect while running Puppet.
Read more
Photo courtesy of 
Image courtesy of 
