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.
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.
Every startup has its founding myth, the story that it uses to help draw in and motivate employees, customers, and investors. In most cases, those myths were cultured years after the company’s founding, and bear little relationship to reality. When you dig deeply into a company’s true origins, what initially looked like the product of far-sighted genius deflates into a mix of insight and smart decisions meshed with a series of serendipitous events.
This gap between myth and reality in no way diminishes the achievement of these companies and their teams, but it collapses our ability to learn the true lessons from those who made it and those who did not. If we can shift our story-telling from creation myths to capturing the collisions actually necessary to germinate greatness, we can better recognize what it will take to support it next time. Even better, it will allow us to pull forth those organizations not lucky enough to get all the draws, enabling our ecosystem to address neglected founders attacking neglected markets.
As I was building Puppet, I assiduously sought founder stories, trying to understand what it really took to do what they did. Over time, this turned from a quest to build “Good to Great” for startups (which was silly anyway, given how stupid that book is) into a collection of more-true founding myths:
I find these funny, but the true goal is to puncture the story people want you to buy so you can understand what it really took. When you do that, you find that yes, people had to work hard, they had to be smart, they had to be creative. Those are necessary, but as testified by the thousands of failed companies full of hard-working, smart, creative people, they aren’t sufficient.
When you can find true founding stories, such as Phil Knight’s excellent Shoe Dog, you gain critical insight that might help you build your own business better, but you also realize how much of building a great company is expertly riding the tide of luck and opportunity.
On first blush, there’s no problem with this, other than the ridiculous levels of delusion necessary to turn serendipitous opportunism into genius founding myths that manage not to include the lucky bits.
On reflection, though, erasing the role chance plays causes systemic problems throughout the startup world.
We’ve already seen that human nature abhors a vacuum, refusing to accept that people don’t always deserve their circumstances. Luck is obviously not the only contributor to a startup’s success, because how they play the hand they’re dealt is at least as important as the hand itself. But let’s not lie to ourselves about the role of randomness in a startup’s circumstances.
When we do, it limits our ability to understand what it really takes to make a great company. This is similar to the deep structural flaws within “Good to Great”: If you just ask the great companies what they did and try to do the same, you sound smart but have only made your readers dumber. I recommend The Halo Effect for a more complete discussion on how this business-book analysis of success fails its readers. You can fatally pierce the concept by focusing on one kind of failure:
“The Delusion of the Wrong End of the Stick - successful companies may do various things but that does not mean that doing those things will make you successful”
As I was trying to build Puppet, I found this discrepancy between the stories and the realities immensely frustrating. I was uninterested in being valorized for something I felt lucky to be doing, but these myths were a screen obscuring information I knew was valuable. My goal in studying my predecessors was to improve my own chance of success, but it’s impossible to learn from propaganda. Instead of a community of founders learning from each other, with each iteration being better than the next, you get cargo cult companies that manage to copy every part of a successful business except the parts that made it work.
As just one example, Google’s own data now shows that its vaunted hiring practices did not actually help, but a whole generation startups copied their worthless brain teasers and discriminatory ivy league requirements. For years, Google’s dominance was partially explained by their great hiring, but what happens when it turns out they weren’t actually better than anyone else? Nothing to see here, please move along. Let’s just start another round, this time copying Netflix and Amazon. Forgive me for thinking that Amazon’s success has more to do with their taking Walmart’s extractive business strategy to the web than on their use of internal APIs.
What I found again and again when I peeled these myths back was far more genius in how people responded to their circumstances than in how they were created. Oracle is a perfect example: Larry Ellison was smart enough to realize that IBM had invented this great new database concept but weren’t trying to sell it, so he took advantage of that to build it himself. You can bet that’s not how Oracle tells its founding story, but only once you know it can you see that Ellison’s true strength was pushing hard and fast enough to ensure that Oracle was the first one to market with this free idea. I don’t look up to Oracle’s founder, but you can bet I learned from that story.
Google is another good one: One of the best CS schools in the world bashes together two random guys, who then go on to invent something and get lucky enough to fail to sell it. What you can learn from Google looks pretty different once you know that. Again, it does not diminish what they did after that failure, but it turns their stories of manifest destiny into a more true telling of wandering any icy landscape looking for safety.
When they say history is written by the victors, they mean both that only the the stories of the winners end up getting recorded, but also that the stories themselves get morphed, corrupted, to present those winners as just and deserving. That corruption is as pervasive in the world of startups as it is in the wider world.
There is tremendous value in understanding the real stories behind the great successes. Good luck getting companies and founders to tell them.
The iPad has made great strides in the last few years toward being a full-time computing platform. While many still cry that it’s just not very useful yet, others are out there using it as their only computer, or have at least shifted significant usage from desktops and laptops to it. I have been traveling at least a third of the time over the last few years, and the iPad is my only companion on the majority of those trips. It is by far my favorite computer, but it has one glaring defect.
Obviously, the heart of the iPad is its touch interface. The direct interaction is exactly what makes it such a joy to use for so much of it can do. However, even Apple has finally acknowledged that a keyboard is a necessary companion for many iPad uses. While their keyboard has some issues (or rather, their keyboard connection technology does), the overall experience is quite nice. Except for one little detail.
Unlike touch, keyboards are inherently targeted. While touch is powerful specifically because of your ability to directly manipulate the software you’re using, keyboards must first be pointed at a place that needs text. They need focus. And here’s where the iPad falls down.
It has no concept of focus. Or rather, it obviously does, but its designers are in denial about it. Keyboard focus is littered throughout the platform, from the presence of a cursor when inputting text, to the software keyboard auto-hiding when no text field is in use. When you’re producing text, this generally works pretty well.
But the keyboard is used for far more than typing. Whether it’s command-tabbing between applications or using shortcuts within them, the keyboard is a critical control device. And it just does not work right on the iPad.
Honestly, it does not work that well on the mac these days, either. Apple’s Mail application can’t seem to figure out how to pass focus between emails, especially when deleting them, and there are plenty of other situations where focus within a window - as opposed to between them - can neither be perceived nor controlled.
But because of its orientation around touch, the iPad is much worse. The vast majority of the time that I want to, say, delete an email, the delete key just literally does nothing. I can even touch the email I want to delete to “ensure” it’s focused, and yet still the keyboard is useless. I have to resort to touch for interacting with applications the vast majority of the time. Many iPad-specific apps now advertise keyboard shortcuts, but they’re useless. I mean, sometimes they work. But that’s not good enough when you’re trying to get something done; we learn, eventually, to do what’s consistent, rather than what’s fastest when it works but often fails.
I have so many memories of using my keyboard to tell some app to do something, and just starting at the iPad until I realize nothing is going to happen. I tap around, hoping to tell it, “start here”, but it’s usually no use. My expectations collapse, and I feel crippled, reduced to the level of those who just click around their GUIS. It’s not wrong, but it can be so much better.
I follow every conversation I can find about the iPad as a productivity platform. I’m deeply interested in the thoughts of people who are bought into it, such as Federico Viticci, so I am cognizant of the general thread of how this is progressing. As so often happens to me, I seem to be the only person concerned about this problem. Here are all of these people talking and writing about the iPad as a general purpose computing platform, yet they don’t mention this problem of the inconsistency and invisibility of focus at all. Do they just not use keyboard shortcuts? That’s not possible, right?
And don’t tell me it’s my iPad. I’ve had literally every version ever made (I currently have both sizes of the iPad Pro), and every few iterations I do a clean install. I’ve tried every variety of keyboard, from Apple’s to Logitech’s to a $15 piece of junk I bought at Brookstone at the airport one time because I managed to leave mine at home. I’ve changed every variable. The only explanation seems to be that others just don’t care about this.
I’d also like to see people rallying for Apple to shift the default orientation of the iPad Pro to landscape, because the keyboard is so central to its use, along with an automatic disabling of the rotation lock when the keyboard is connected, but these are minor compared to the core utility of a keyboard.
To me, one of the central reasons to want a keyboard, one of the primary purposes of the keyboard on my computer, is to control the computer. At that, the iPad is currently failing miserably, and it deserves better.
I fear that this can only be fixed by introducing completely new design concepts to the iPad. Obviously the OS understands focus, but the design team has worked hard not to ever indicate that to you. That has meant application developers have not bothered to manage it effectively, and has trained users to rely on touch rather than the keyboard.
While Apple is a design powerhouse, they’re also into brutalist design, always opting for less, always preferring to forego a capability if they can’t make it perfect. This causes me to despair that they’ll make material strides on this any time soon.
I’d love to be proven wrong, but for Apple to start caring about this, its customers need to first.
What’s your story? Do you just not use keyboard shortcuts? Do they work great for you? Or they’re totally broken, but the other broken stuff is just so much more important you haven’t mentioned them yet?
Software’s focus on world-dominance has crossed with my incessant tinkering to result in a computing environment that is failing me utterly.
I’ve tried everything, and it still doesn’t work.
My first computer was from basically the worst era Apple has ever produced, starting with MacOs 7.6.1 and finally quitting around MacOs 9, switching to BeOS. While I was using these for fun, I was learning Solaris (and AIX, and HP-UX, and FreeBSD, and Debian) for work. I know some are frustrated that the Mac has lost its spacial finder, but I’m frustrated when I have to touch my mouse, because I spent years in a fine-tuned X-Windows interface that allowed me to do essentially everything from the keyboard. It was only marginally graphical; all of the windows except the browser were different kinds of text interfaces, from the terminal to vim to irc. I controlled everything with a Sun Type V keyboard, which relegated the caps lock and backslash keys to some far away corner like God intended, and gave prominence to control, escape, and delete, which matter quite a bit more. I honestly have no idea what mouse I used for the first ten or fifteen years; I don’t normally care about them, so I don’t normally notice them.
As I gradually switched from a sysadmin-turned-developer to a CEO, my computing needs changed dramatically. I spent all my life in email, calendar, and chat rooms, instead of text windows (notice they’re all still text, though). I did not even have a desktop computer for years, because a laptop was a better compromise.
As the iPad got more powerful, though, and Apple’s iMac computers turned from lickable toys into their most powerful computers, I moved most of my computing from laptops up to desktops or down to tablets. For a little while, all was fine, because I still wasn’t spending much time on the computer - as a CEO, most of my time was spent directly communicating with people, either in meetings or via email and chat. Being present means not being on your stupid devices. That was my computing experience.
Once I left my CEO role, I shrugged. I changed a few things (started writing in Ulysses, for example) but basically kept the tools and practices I had.
It’s become clear now that I have a solid decade of debt that’s built up in how I use my computers.
I really hate it.
Some of it is obviously just bugs. Or something. The keyboard (a KÜL tenkeyless with some kind of Cherry MX switches) and mouse (some large Logitech thing) just don’t work most of the time. The keyboard has to be unplugged and plugged back in 90% of the time the computer goes to sleep, and the mouse icon just does not seem to care about my needs, even after swapping mice, mousing platforms, hair shirts, and everything else I can think of (turns out that moving the mouse’s wireless adapter from a USB hub to the desktop might have fixed the mouse).
Beyond that, the software is out to get me.
Am I seriously the only person in the world who cares about keyboard focus?
I just deleted an email in Apple’s Mail.app on my desktop (running the latest os and patches, but this problem has persisted for as long as I’ve used the app), and I literally have no idea where the focus went. I hit delete, the email goes away; I hit delete again, and literally nothing happens. An email is highlighted, but, oh, I see, it’s a gray highlight instead of a blue one. I click on it, now it’s blue, and suddenly delete works.
I have essentially the same problem on my iPad (which I work on at least as much as my desktop). My only feature request for the iPad is to make keyboard focus predictable and functional. You can be scrolling through emails with the arrow key, and suddenly it will just stop working. Delete an email, no idea where focus is. I don’t even know how to tell where the focus is.
I’m in this insane world where I can feel utterly defeated by the need to click on an email to delete it, but if I zoom out, just about every other part of my computing experience causes similar frustration. I’m apparently the only person in the world who has quality studio monitors on my desk, based on how much everyone is freaking out over the HomePod price. I have separate audio installations in 7 parts of my house, and the HomePod in my bathroom is the cheapest one, beating the thirty year old (purchased used, recently) NAD and M&K kit in my bedroom by about $100. Nothing can cause you to lose hope that your needs will be met like the entire internet agreeing your needs don’t exist.
I don’t consider myself an audiophile, but I know enough to know that decent speakers start arriving at around $300 (each, not a pair), rather than topping out there. I never bought into Sonos because that required my believing they could deliver a good speaker, amplifier, and software experience for the price of a single decent speaker. Oh, and I had to join their walled garden; I’m willing to consider that, but it’s got to be worth it, and it never was for them.
Getting back to computers, it just could not be more clear to me that I’m in the shitty middle ground of the computer world.
I’m not a specialist any more. When I was a sysadmin, I was a specialist and I could build my computing environment to match that. (Although good luck finding specialized sysadmin hardware these days.) When I was a developer, I was a specialist, and my computing showed it.
Now I do what everyone else does: I email, browse, handle my calendar, chat a bit. My writing is a touch specialist, but not really; I’m using a specialist tool that’s great for writing books, but I’m just producing blog posts instead.
Even though I’m not a specialist, I’m still weird. I know that I’m using all of my tools differently than most of you are. I know we all think we’re special, but I’ve been around enough to know I am. Not in a good way, just in a “why are you doing that?” way.
Take my calendar. I’ve now twice written tools to tell me whether I’m meeting my goals in terms of how I spend my time. Sure, you have some sort of tomato timer to remind you to stand up or something. Amateur. My calendar should be a statement of my priorities, of how I will and do spend my time, and I want to hold myself accountable to my goals. I appear to be the only person who wants this, based on the searching I’ve done. Thankfully Google Calendar has APIs available, but why should I have to write this?
I have tried every email client I can find, but they’re all written for someone else. They all seem to offer, “How can I help you do email without email?” I don’t want that. I want the vim of email clients. I want the Photoshop of email clients. Can you imagine telling a graphic designer that you want to help them make graphics without making graphics? It’s stupid. They’re designers. They design graphics. I’m a communicator. I communicate. I read and write. A lot. Make a client that’s better for that. But nope. Instead you have the modern equivalent of a lickable interface that still can’t do inline reply and only has 5 keyboard shortcuts. _BZZZT_DELETED!
Some of it is just stupid. I have LED strips mounted to the back of my monitor, so I can get ambient lighting while I work. It’s actually an awesome feature, and I totally recommend it, but it’s a bit of a mess of wires with a ridiculous interface (a switch that keeps falling off my desk). I get not everyone has their monitor against a wall, but this seems so great it should ship by default. Can I just get all the LEDs you want in my keyboard moved back there? And, of course, I want it all connected to the computer so I can control it via software. Instead I’m wiring it all together myself and hoping 12V can’t catch my desk on fire. Yay.
I wish it was just that I’m a curmudgeon, that I can’t give up the old ways, but the truth is I like my iPad more than any other computing device I’ve ever owned, and honestly, I always hated the old ways. I’ve been hating software for as long as I’ve used it, and I’m proud I’ve been able to keep my edge as my career and the world it’s in has changed. I hated X-Windows. I really, really hated MacOS. I loved BeOS, but honestly, I held it to a very low standard. I loved every part of Solaris except the parts that actually existed or that I ever used, and I quit using it just when it stopped sucking quite so much (god, remember having to use Veritas to get decent clustering? Even worse, remember Disksuite?).
So it’s not that I miss the old days. I want to live in a different universe. I want a different physics model for our software world.
I’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
