When I was 23, I was hired as a system administrator for the first time. I joined BlueStar Communications, which was a young but well-funded company stupid enough to take on the incumbent telecom carriers. Their CEO was a maverick, especially in staid telecom in Nashville, Tennessee. He was bringing always-on internet to small businesses in the southeast (yes, there was a time when this innovative), and blended in about as well as a hockey player in a three piece suit. I was excited to work with someone who I could identify with, and learn from.
He was fired the week I started.
Like the founder of BlueStar, I’d had my own struggles with long tenures. I was fired from a cabinet company after only a week. I lasted a full three month contract at Adidas before having it ended the day I left to visit family. I also lasted only three months in QA and Mac administration jobs.
For all of these firings - except maybe the cabinet shop, which bored me to tears - I wasn’t bad at the work, I just didn’t fit in. You could say I wasn’t really housebroken, that I didn’t know the rules of how people acted in American corporate environments.
All of my prior work experience was remodeling houses with my family, after growing up on a commune. I had no idea what made people normal, I just knew I was missing it.
These failures inspired me to work harder at being worth keeping around, but in parallel I started learning to look like I knew what the rules were and was at least trying to follow them. For someone who only a few years earlier walked around campus with knee-high boots, a spiked leather jacket and a mohawk, this was no mean feat.
This experience with firings was a huge influence when I started Puppet in 2005, six years after I met the CEO of BlueStar. I bootstrapped the company for more than four years, partially because I failed to find an investor I trusted to keep me in the CEO role. The first term sheet I ever received was on the condition that I accept a friend of the investor’s as CEO. (I declined.)
As I grew the team, things got more difficult. One of the first people I hired immediately declared his greater fitness for the CEO role, with zero relevant experience, and tried to convince others to oust me from the company I’d built and they’d just joined.
Yes, I was paranoid, but they really were out to get me.
From my first hire through raising $87m in funding and growing to nearly 500 employees, I could never get comfortable. Everyone I worked with reminded me - unintentionally - that I didn’t fit in, that I didn’t behave as they expected. As I grew into my role, I excelled in areas, but continued stepping in holes that everyone else could see.
The suspicion that I wasn’t faking things well enough was confirmed as I was raising a later round of funding.
Before a pitch meeting, an investor said to me “Now try to be more like a Valley guy, not so much a Portland guy.”
Infuriatingly, I knew what he meant, but also that I’d never be able to pinpoint what I was doing wrong. I worked every day on my “Valley guy” pantomime, from the clothes to the books to the words. This pointed statement told me in stark terms that my efforts were obvious failures to even the casual observer.
Knowing the world saw me as an imposter caused me to hold back. I don’t mean I had imposter syndrome; I suffered from it like most high performers do, but that’s not what this was. The world around me constantly pushed back against what made me “me”, making me worse at just about everything.
I had put myself in a box. I wasn’t even willing to consider ideas that I didn’t think the people around me would accept. I was brave, within that window. I was daring, but not too much. I could do anything I wanted, as long I still kind of looked the part. This box excluded many great options, and notably, excluded a lot of what I most wanted. My weirdness isn’t skin-deep, and a lot of what I wanted just didn’t fit, so I tried to do something that did. Thankfully a lot of it worked out, but I think it could have better, and I know it would have been more pleasant, if I had been more brave, more willing to own my lack of belonging.
It’s worth noting, this was all as someone who did theoretically look the part. I’m a medium-sized white male with a degree from a great school.
I can’t imagine how much worse it would have gone for someone who literally looked different - wrong skin color, wrong gender, wrong accent, disabled, too short, etc. Maybe that was my real problem - people let me in the door thinking I was like everyone else, and only once they started talking to me did they realize how weird I was.
Finally, after almost ten years of running Puppet, I found a way to escape this box I had put myself in. I would quit.
It’s not fair to say this was the only driver for my decision, or even that I was thinking of it this way at the time. What can’t be denied, though, is how much it changed me. I lost my fear of being fired for not fitting in, because I was working to leave anyway.
I couldn’t see the box when I was in it, but when freed, unavailable actions suddenly became doable. I could trust myself for the first time since that first hire, so my cost of decision-making plummeted. I didn’t need to look to society as some sort of arbiter of what’s reasonable.
I had been preventing myself from using my now-highly trained instincts, which reduced me to tackling easy problems or making slow, bad decisions. Or sitting there and doing nothing, which is generally an even worse decision.
Outside the box, my inductive reasoning center could operate without all the second-guessing. I was able to hire a product leader based on instinctive conviction that we were aligned on how to work. I made an incredibly tough call on hiring for Business Development, by following my thread of fear that maybe I was being pulled toward too easy of an answer elsewhere. Most importantly to me, though, I was able to develop and begin rolling out what I think is a truly great product strategy.
I did some of the best work of my life.
This experience has an interestingly conflicting lesson.
On the one hand, the cost of trying to fit in is often too high. No matter how much you want it, you might have to choose between failing at what you want and succeeding at what you can authentically do. If you’re building a team, the choice may come down to those who are great at the job and those you can work with.
On the other hand, I somehow fooled people into thinking I was normal (well, normal enough) for long enough to become a successful CEO in a field where I seemed like an alien to everyone involved. That pantomime was critical in developing the instincts I was able to apply so well as my tenure wound down, and now I have opportunities I never could have dreamed of.
I think the duality of this lesson is important in the conversation around diversity. Puppet couldn’t have existed without some tolerance for my weirdness, but it was also much harder because of it.
I’ll never know if getting out of that box earlier would have caused me to do even better as CEO, gotten me fired ignominiously years earlier, or even maybe caused the company to fail early on. What I do know is that I was deeply hurt by not facing and acknowledging my fear of being fired.
I am privileged to have no idea what is in store for me, and no fear at the prospect. I feel no need to fit in anymore, both because I have nothing to prove and because the cost of not fitting in is now one I can afford to pay. If anything, I’m now considered more valuable because I don’t fit the mold.
The lack of pressure to conform brings incredible freedom. Freedom that everyone deserves.
I am not a technologist. This surprises many, including a CEO I was on the phone with recently. I explained that I had no pet software projects I was working on at home, and thus couldn’t demo her software. She paused for a second, like, “Uh, why are we on the phone, then?”
It’s true that I have worked on tech since graduating from college, and that I wrote Puppet essentially alone while I bootstrapped the company for years by myself. I enjoyed the work, but those were all a means to an end, not the goal. This became more and more clear to me as I hired large teams who really were technologists. I was able to do the work, but they loved it. I naturally fell into different, complementary areas.
So no, I can’t really help your company in sorting out its software stack. Or rather, I could, but you really shouldn’t want my help there. There are better people. Far better. People have found my advice really helpful in the past, but not in this area.
Strategy is where I’ve had the biggest effect as an advisor. You are already deeply committed to your goals - you don’t need my help figuring out what to do. You are just as committed to how you’re going to achieve them, but probably haven’t spent as much energy thinking about it and expressing it. This ‘how’ is your strategy, and key aspects are decided early on, whether you mean to or not.
Do you want a big field sales force, or a self-service model? Either way, why? How does that choice affect your product price point and service attach rate? There isn’t necessarily a right or wrong answer, but a choice will be made, and it has massive consequences on the life of your company. My great ability is pestering you with questions until you’re forced to put your opinions on the table and really examine them. As a leader, your job isn’t just to be opinionated - it’s to be able to usefully express that opinion to your team.
Product is the second major area I will push you. Again, this isn’t about the tech, or the code. I don’t care how it’s built. The first step is being clear about what problem you want users to hire you for. I bet you have a decent grasp of this, but you have to go down a layer into which users you’re going to start with, how you’re going to parlay them into a larger group, and how all of that relates to adoption within a single organization and across a market. The path of a product’s adoption is as critical to plan out as the features you build.
All of that ties into how you price. How does it drive user behavior? What do you want to incentivize through low or free pricing, and what must you charge for to make your business work? How does charging per seat vs consumption vs features change their behavior and affect your business?
All of this must come together into a coherent system that pushes you, your team, your customers, and the market to focus on the right problems at the right time. You should seek my help in seeing the whole system, and especially the gaps in it. I hate software, but oh boy, do I love systems. My brain is so optimized for managing, storing, and assessing systems that I lose nouns constantly. It’s worth it, for me and for you.
I can also help you.
You’re not a coincidence. You have to understand, it’s not an accident that you’re here. Even if the only thing that makes you special is that you were the first one to raise your hand… it’s been a few years now. Because of that one little action, you’re different than everyone else. It’s up to you to demonstrate whether that difference is good, or useful, but it’s definitely there.
I don’t mean to say that you’re better, or that only certain people can be entrepreneurs. History shows the exact opposite, and I’m a huge believer in empowering ever more. What I mean is, the mere act of taking the step permanently changed you. One of the hardest acts for most founders, especially those from underrepresented groups, is believing that they belong, that they deserve to be out front. I can help you see how just sitting in the seat has led you to be a different person than you were before, led you to special insight and special opportunity.
It’s up to you, now, to make the most of the opportunity, to believe in it and to deliver on it. You have to learn how to extract that difference, to bottle it, to share it. And when to dump it down the sink.
Founders are so full of dreams that they have a hard time letting go. “It’s true we can’t do this today, but I’m going to keep talking about it in hopes we can do it tomorrow.” Your business is on death’s door and the wrong success gets you all fired, but sure, go ahead and distract your team with something you know you can’t and shouldn’t build, and that your customers would never buy.
Everyone knows founders have to make hard decisions, but most don’t seem to realize the hardest ones are about their own dreams. To build something great, you have to give up on other dreams. You can’t build it all at once. You can still hold it, treasure it. But you don’t get to talk about it. You can’t distract people with it.
You haven’t earned it yet. When your company is a massive success, and throwing off more cash than you know what to do with, that’s when you pull out your other great ideas and turn your success into a platform for experimentation. Until then, you have to focus. Let go.
Beyond all that, I enjoy working through demos and user experiences, helping people see your work through new but educated eyes, asking a thousand questions that you might not have answers to. This teaches us both a lot about you, your product, and your company. The differences between the easy and hard answers teach you a lot, too.
What I don’t like to do is tell people what to do. At most, I will share frameworks I’ve used for decision-making in the past and recommend some of them for you, but preferably, I will focus on pulling from you what you really believe, and then make you really confront it. It’s not about me. I can’t live your life. I don’t know your customers. I can’t run your company.
But maybe, with the right prompting, I can help you look at it in a new light, help you make the right decisions faster, and help you avoid some of the worst parts of this insane decision you’ve made.
Anderson’s knife can cut anything, taking a chunk from everything in the land.
Master Terrence’s strokes remove less with each cut.
Greg LeMond once said, “It never gets easier, you just go faster.” This quote has been a rosary for me, a source of contemplation and meditation over the years. I think of it every time a new problem reveals itself as an echo of something I thought I already solved.
When I started Puppet, everyone I worked with stressed the need for me to recognize my position as founder and CEO, to bring people with me. The summer before I stepped down, more than a decade into practicing this skill, it still showed up in every coaching session. Not because I haven’t improved - but because it is a life skill that I can improve at every year and still die with more work in front of me than behind.
I found it incredibly hard to hire those first few people. I second-guessed myself, was slow, looked like a fool, felt an even bigger one, and finally made bets based on too little information. When I rebuilt the executive team in my last year, I second guessed myself, went too slowly, made what looked like basic mistakes, and felt incompetent the whole time.
This isn’t a coincidence. It’s not a sign of my incompetence. It’s the exact opposite: It shows that I never let things get easier, instead I kept my intensity up and always focused on going faster.
LeMond knew how to win. You train, you work, you focus, and all that effort delivers leverage. What you did yesterday when giving 100%, you can do today giving only 97%. What do you do with that 3%?
If you want to win, you reinvest it. In what? Counter-intuitively, exactly what got you that leverage in the first place.
For each and every one of us, there are two kinds of skills: Those it’s worth devoting our lives to, and those it’s not. A given pursuit can be less important because it doesn’t matter to you, because you’ll never be good enough at it, or because you just don’t like it. Those that matter, though, are a perfect intersection of your love, your abilities, and your values. They will reward any amount of investment by making you better at what you care most about, and are best at.
You have to love it because you really can’t devote the time and energy needed to dominate unless you like the work. You need at least some ability. You don’t need to start with a natural talent, but you are most likely to be rewarded for investing in areas that come easier than when you’re starting at the bottom. And your investments have to match your values. Some people care most about skills that earn them money, others about having an impact on people’s lives, and yet others want to build. You have to believe that what you’re investing in will help you spiritually, not just materially. It’s the only way you can convince yourself to work as hard as you need to.
Yes, there absolutely are things you will never be good at that you have to invest in. When I started Puppet, I was an outright liability in some areas, such as business operations. I had to get better at those. But I was never confused into thinking I would be great at them. That’s what team building is for.
Given two skills, one where you’re 8/10 and the other where you’re 3/10, where do you invest? Some might recommend the skill you suck at.
Not me. If that skill mattered, you would never have gotten hired in the first place. The reason you have a job is because of your 8/10 skill. Get 10% better at your weakness, and wow, you’re at 3.3/10. Big whoop. Get 10% better at your strength? You’re at 8.8/10. That’s a huge difference.
But getting 10% better in your area of expertise is fantastically difficult. It’s your life’s work.
I am suspicious of people who say the hard things are easy. What I hear is not that it’s easy, but that they’re not trying very hard. Or they’re too embarrassed to be honest.
Greg LeMond was the fastest cyclist in the world, but never stopped trying to ride faster.
Miyamoto Musashi won more than 200 individual duels with a sword, but never stopped trying to cut faster.
Excellence requires perpetual intensity. You should be confident enough in your strengths to admit that it’s hard. It should be hard. It’s the only way to get better.
Reese’s keyboard produces truth of complexity and beauty, admired from a distance by all.
With a violent strike of Master Aaliyah’s pen, Jorge is enlightened.
I set out in January to study the realms of finance, software, and my own desire, but found myself adrift with no laboratory for experimentation. Programming was my testing ground for the hypotheses that led to Puppet, but my new questions cannot be answered in silicon. Clumsy studies provided two conclusions: Writing itself can and should be how I express and test my beliefs, but only if I get much better at it.
I started Puppet with core hypotheses, considered stupid by the experts around me. There was no point in talking about them; anyone can talk, and listeners similarly get to pick their conclusions. Only those I could prove had merit.
Proof is complicated. Few of us live in the world of math, where there’s enough overlap between objective reality and our language for discussing it that we can be truly sure. Computer science is itself lacking the unsentimental judge that the natural world provides to actual science. In truth, I should not discuss proofs, but rather disproofs. My real challenge with Puppet was to get rid of my false beliefs and let the remainders shine through, and there, programming was the perfect foil.
The best product idea in the world is worthless if it can’t be expressed in software in a sufficient timeframe. Merely building Puppet forced me to discard many convictions, and early rejects often became critical axioms undergirding the whole system. Of course, in the world of software, the compiler is only the first test. The real arbiter is your user, your customer. Once you’ve expressed your belief in a form someone can use, do they? I remember arguing for hours with a customer against a feature he requested, but the cold hard reality of his problem had me spending that night in my hotel room fixing it.
I am often asked if I miss programming. I do not.
What I miss is the laboratory it provided me, and the complete world that enveloped me, pressing in on me with its constraints, requirements, and complexities. I miss the hours I spent focused on one problem, and the complex systems needed to turn my ideas into a form usable by others.
I am thrilled and relieved to see that writing can be a new and even better laboratory for me. When I was programming full time, problems would haunt me, refusing to leave. I wore holes in my shoes walking back and forth between my keyboard and the local coffee shop, trying to line things up so they made sense. I’d scrunch up my face while drinking the coffee, drawing enqueries as to my wellbeing.
Writing is harder than that. The problems are bigger, and yet deeper inside, and harder to extract. I was never afraid of programming, but every idea I fail to write frightens me at least a little. On the far side, successfully expressing something is cathartic, a release, and it washes everything out with it.
It’s a better laboratory, because I have far more opinions about the real world than about the software world. Like those hypotheses that led to Puppet, I don’t know if they’re good. But I do know they’re different. I’ve bounced off reality enough times, asking for help from the crowd of onlookers and then getting back up, that I have a good sense of which of my beliefs are widely shared, and which are rare. For better or worse, little of what I believe, of what I think is important, is widely shared.
I’m excited by disagreement. Alignment is critical to execution, but diversity is needed for learning.
More than anything, I look forward to sharing my ideas, and as I did with Puppet, either finding them useful to other people, or having them cut to shreds to reveal new constraints, insights, opportunities. To do that successfully, though, writing is not enough: People must be able to read it.
Writing is no easier than coding, and in both, it’s ten times harder to write for others as for oneself.
One of my earliest optimizations in building Puppet was to prioritize my own productivity wherever possible. I explicitly chose to program in Ruby because I was faster there, even if it was slow and unpopular (Puppet was started before Rails was released). It took years for my programming style to reveal itself as an implicit personal optimization, highly effective for me but inscrutable to others.
My writing turns out to have a similarly mixed legacy.
All of the great shifts I initiated at Puppet began life as an essay, some extruded in a single sitting but more often sculpted over months and years. Once a hypothesis could defend itself, I then spent months and (more often) years translating it, turning it into something people could execute.
I’m proud of that work - how can I not be, when it helped build Puppet into what it is today?
But it’s fair to define good writing as something that doesn’t need a translator into its own tongue. By that measure, I’d failed.
Like a young programmer, I used to see people’s confusion as a sign of my genius and the value of my work. Now I look back with my designer’s eye and see it as a missed opportunity. We could have been there years faster if my beliefs had come with a better user experience. Kanies’s Razor is as applicable in prose as it is in code: Never attribute to genius that which can be adequately explained by incompetence.
I sit at the keyboard today as thrilled and scared as I was at the shiny benches of my science classes in college. Today I smell tea instead of banana oil and denatured ethanol, and I have no lab tech to stonewall me when I ask for easy answers, but the feeling of hope, of optimism, of a world to be discovered, understood, and fought through lifts me up just the same. I believe I can enjoy writing as much as I ever enjoyed programming, I can develop and test a wider range of hypotheses with a greater impact on those around me, and I can even learn get those ideas across to other people.
Apple just released iOS 10.3, which for the first time puts one of their production platforms on their new filesystem, APFS. I’m pretty happy that they are finally replacing such an aging, obsolete piece of core technology, but I’m nowhere near as excited about it as John Siracusa is. All APFS seems to do is finally meet the basic needs of a modern operating system, and not even all of those. It doesn’t come anywhere near doing what I care about most in the filesystem, which is owning metadata so applications don’t.
As anyone following the discussion of federal surveillance knows, metadata has become at least as important to our lives as our data. It’s not just the phone calls, it’s who you called, when, and for how long. It’s not just the phone, it’s which ones are your favorites and how they relate to each other. This metadata is as important to us personally as it is to the NSA, because it’s what brings simplicity, usefulness, and most importantly accessibility to the reams of information we create and rely on.
The reason I’m disappointed in APFS is that it missed the opportunity to promote metadata into something as important as the data, and as a result I’ve largely lost hope that computers will ever be as useful and open as they can be.
I’ve been trying for months to convert from Apple’s Photos to Adobe’s Lightroom for photo management, and the biggest barriers to doing so are metadata. It’s easy to get all of the photos - just drag the Masters folder into Lightroom. Oh, you organized your photos into albums? Yeah, that’s all gone. You had thousands of photos categorized as favorites so you could easily find the best? Oops, we ignore that.
Google Photos has the exact same problem. I can’t imagine how anyone who cares even a snit about photos could migrate to it, because there’s literally no way to do so that preserves any metadata at all. You get to keep the photos, but not how you organized them, and your only option is to rely on what they think matters to you.
Can you imagine switching email providers but losing all of the information about who the email is from or when it was sent? That’s as idiotic as what’s happening here.
If my filesystem owned this metadata, on the other hand, no conversion would be necessary. Any application could be written to read and write it directly, or I could trivially use any scripting language I wanted to do so. In fact, I could easily switch back and forth between different apps for different purposes, because they would not be able to lock me into their proprietary databases.
This shift is hard to understand, as we’re so used to thinking of applications and their metadata as somehow intertwined. For those in the programming world, there’s a clean analogy that helps to explain the horror of the modern filesystem:
For most of the history of software, applications have been written to directly access databases. They needed to understand the structure of tables and rows, and they had to write and manage their own queries for interacting with that data. Because of the complexity of duplicating this ability, applications tended to own their data entirely, and no other apps could get access.
We’ve recently instead seen a trend towards building very simple data services on top of databases, so that no app directly accesses them. This data service provides an API that understands how all of the data works, and also provides all of the key operations that can be performed on the data. This way, any application can access the data - for both reading and writing - without worrying that its use of the data is somehow incompatible with another consumer. You get the added benefit that any optimizations in the data service help every consumer, not just the one or two apps you remember to change.
Those data services are exactly what have enabled modern applications to scale to the level they do. The application developer can focus on their goals for the data, relying on the data service to provide consistency, portable operations, and everything else.
In the land of the operating system, though, we have no such luck. Everyone who talks to the filesystem gets about the thinnest interface imaginable: Get me a blob of data. Yes, there’s basic metadata (who owns it, when it was created, etc.), but none of it is or can be custom to the application, which makes it useless. Can you imagine how unpleasant it would be if we had to shoehorn both the subject of an email and the subject of a photo into the same keyword?
As a result, everyone turns that blob that the filesystem is trusted with into a database, and that’s where they put all of the metadata. Some even put the data there, even if it means huge database files and entirely non-portable systems. Really great app developers then go to the effort of building a full read and write API on top of this database that allows you to manage and port everything in the database. That’s enough work that most people skip it, though.
I would never have seen this missed opportunity in the filesystem if I hadn’t used BeOS. I went to Reed College, where Steve Jobs famously attended briefly (I made the unfortunate mistake of graduating, unlike him). This meant I was a Mac user all through school, which were the bad days of Quadras and MacOS 8 and 9. shudder I switched to BeOS because, well, I could, and it’s what really turned me into an OS junkie. There were many awesome things about it (many of which are now in OS X), but my favorite became how much responsibility the OS took for metadata. Applications became smaller, simpler, and in many cases, you realized your whole concept of an application was a way of organizing metadata, which meant you could rely on the OS entirely, and needed to write no code.
The greatest irony is that the author of Be’s awesome filesystem, Dominic Giampaolo, is now a lead engineer on APFS. Through the work of him and the rest of the team at Be, I came away with a clear idea of the value of my metadata, and especially the benefit of the operating system putting it on center stage.
So while I’m happy that my phone is no longer running the oldest, crappiest filesystem around, and I’m looking forward to the days when my computers aren’t either, I’m not excited. Until it was released, I could always dream that Apple saw the same future I did.
Now that the new filesystem is here, that hope is lost.
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
