You’re doing productivity wrong. Actually, it’s worse than that. You have no idea what it is. And no, this isn’t some sort of technical, jargon-y sense where I’m arguing over whether to measure it in terms of lines of code, hours spent typing code, or something else. Your core understanding of productivity is entirely wrong, and it’s making your company worse at everything it does.
Productivity in the software world is discussed in terms of the individual, and usually phrased as getting more of a person’s time on the thing they were hired for. “Hey, I didn’t hire you to talk to users or attend training! I hired you to write code!” Even the developers join in: “Every minute I spend in meetings instead of writing code is wasting company money.”
This is stupid and wrong.
I had a conversation with a CFO recently who asked me why his company should use Puppet. I asked him in turn, what does it cost you to ship software right now, and what’s the value of lowering that cost? He said, not surprisingly, that he could not answer that. This isn’t to pick on him - most software CFOs would say the same things, since their job rarely delves into software operations.
Can you imagine having the equivalent job description with a manufacturing company? Picture the CFO of GM saying their job doesn’t require they understand the financial aspects of building cars. They’d be shipped out in disgrace. Yet somehow the software world tolerates ignorance of the financial implications of their core work product, software.
Sure, you might say, our finance teams can’t help us build more, better software for less money, but we don’t need their help because we intuitively know that more time spent writing code equals more productive development teams. Right?
No, you don’t. Again, you’re wrong. This is exactly, specifically how you’re wrong.
Toyota showed decades ago ensuring everyone is busy all the team is a great way to lower productivity. Yeah, you read that right. Lower. If you can’t shut the factory down (thus making everyone idle), you can’t fix problems at their source, which means every car you make is broken in the same way.
As another example, teams can almost never be perfectly balanced in output. Maybe you make doors much faster than you make engines, so if your door team is always busy, you end up with too many doors. Just like in development: The interface team might work a bit faster than the backend team, so they build an interface on a myth and then you can’t ship their work because there isn’t coverage on the backend. Oops. But hey, at least that interface developer didn’t spend any time in training, testing their prototypes with users, or bringing fancy coffee to the backend team.
The stupid thing is modern industry figured this out with its very first business consultant, Frederick Taylor, who developed a thing he called ‘Scientific Management.’ His ideas sounded good: I’ll hold a stopwatch and find ways to encourage people to get more done in a given amount of time. Seems reasonable, right? Probably more advanced than how most software companies do it today. In fact, he was really successful: He spawned our nation’s first management consultants, and they’ve continued to make tons of money on the fraud that he perpetrated more than a century ago.
Because that’s exactly what he was: A fraud. He was fired from his first gig because it ruined actual productivity, yet managed to convince corporate America that it was such a good idea they should ignore the little problem of it not working. Here we are a century later and the Harvard Business Review is still giving advice using Taylor’s own language.
But, you ask, what do I focus on if I’m not allowed to just track what the developer works on?
Now, Grasshopper, you set foot on the path to wisdom.
These are examples of waste in the form of rework (fixing quality problems later) and inventory (the built but unshipped interface work), but there are many other kinds that pervade modern software development. Lean Manufacturing is our most complete and coherent philosophy of productivity, and its name isn’t just decorative. It reframes the problem of optimizing productivity into the practice of reducing seven (or sometimes eight) kinds of wastes, including those above.
The funny thing, though, is that none of these wastes are visible if you just look at the individuals involved, so measuring what the people do isn’t just worthless, it’s actively counter-productive. See what I mean about all the wrongness?
Transport is a great example. You might have a person at your company specifically tasked with this (the most famous example from this is certainly from Office Space, but there are rational reasons for such roles in modern software teams). Intuitively you’d want this person to be 100% busy, yet optimizing the system to need more transport hurts the system even while it makes your individual stats look better.
Our world of software is fundamentally confused because it can’t move past thinking about the people to seeing the system. The first page of results on software productivity pretty much exclusively focus on the people, and even developers will say they should be spending more time writing code and less time doing other stuff (like in meetings with product managers or customers).
This is the challenge of our industry over the next few decades. It took around two centuries to get from the first industrial mills in the 1700s to the development of lean in the late 1900s. There are times where I think we can do better, learn faster, but then I realize how much more complicated our problem domain is, and I start to wonder. At least in factories you can physically measure inputs and outputs, and you’re consuming and producing discrete, easily measurable work. With software - especially SaaS built on the public cloud - discreteness is impossible, and even measuring the cost of inputs often approaches impossibility. It’s much harder to optimize systems that extend far beyond our own data-centers (if we even have them).
Nonetheless, this is our challenge. The first step is to move away from this focus on people, from this view that the developer’s precious time at keyboard is our main concern. Only then can we start to truly get better at building better software, faster, and for less money.
Early in my tenure at Puppet, I had one of my employees, José, make laptop stickers. He said we already had some, and I said, yeah, but they suck. So he designed something different. I said nope, still not right. Finally, in frustration, he said, “You clearly know what you want, can you just tell me what it is?”
I expect many of you will recognize this problem. It is sometimes called “Bring Me a Rock”, which pretty well captures its absurdity. Becoming a better leader required I find a way past it.
To my chagrin, I am often described as having “vision.” I hate this. It implies I know what I want, that I have some kind of clarity. I don’t. If anything, I pride myself on my uncertainty. I am a deep believer in open-minded, unsentimental experimentation and I think one of my true skills is knowing where to focus that research, rather than knowing what the research will find. This is pretty much the exact opposite of having a vision. So why did so many people think I had one? Why did everyone around me look to me for answers, instead of doing their own exploration?
I was tempted, but Kanies’s Razor kept me from believing it was just because I was so smart. Finally, someone partnered fantastically with me and helped me see that these are the same problem, solvable through better communication on my part.
In 2014, Puppet moved into a large, new office in Portland, OR, and we had the opportunity to strip the building down to its bones and build out the space we wanted. We were lucky enough to work with Corey Martin of Hacker. He and his team were great at really listening to me, and pulling out what I truly cared about, never getting frustrated or giving up when I was equal parts opinionated and incoherent.
I don’t always know what I’m talking about, but I’m pretty much always sure that I’m right. - Mojo Nixon
Corey quickly realized that I didn’t know what I wanted, but there was something worth extracting from all of the beliefs I was expressing. And, of course, I was paying him, so he did kind of have to actually listen to me. We spent the first term of our partnership working out the direction: What do you want the space to feel like overall? What impression do you want to leave? There are a few different ways to arrange this kind of office, which one appeals more and why?
Once we had that theme, now we could create an actual design. This is where we started pulling little ideas off the shelf - some mine, many theirs - but a design needs rules, some rubric to tell the good ideas from bad. For instance, one of the awesome things about our space is all the great windows and the views they provide. It was important to me that every person be able to get natural light (which is in short supply in Portland) and to have part of that view. This is one area I wouldn’t compromise, but there were many other hard constraints, for reasons of style, cost, or good old Newtonian physics. We captured all of these, and used them to quickly reject ideas that didn’t fit, no matter how great they might have seemed.
We still didn’t have a design, but we had a direction, and a bunch of constraints. Crucially, the whole team had them, they weren’t just some black box between my ears.
It turned out that this was enough of a platform that the team could quickly generate, tune, and reject new designs, so their creativity was opened wide, and my feedback on their ideas made sense. Once the framework was explicit, it became easily extensible. Suddenly discover a constraint you care about but haven’t shared? Add it to the list. Reevaluate your design with the new rules. Done.
They built a beautiful office. Yes, there are some details I lay claim to, and there are a couple of areas where I put my foot down on high-level design components, like open stairways between the floors, but this is their design, their awesome work space.
As I reflected back on how successful this partnership was, I knew it was a teaching experience. You learn far more from successes than from failures, and most of my attempts at this kind of partnership had failed.
Obviously, a big part of it was just how well we were able to partner. You can’t force this. Corey and his team trusted me and knew they had to deliver something I loved, and I trusted them, knowing that they were great at both the creative and implementation aspects of their jobs.
The framework that grew from this partnership enabled the team to do great work, work that I loved. I think I’m most proud of just realizing how special the experience was, ensuring I took the time to understand why. That investment provided a tool I’ve been able to use in almost all of my subsequent work as a leader.
My single most important role as a leader is to describe the direction I want to head, and if at all possible, I need to explain why. A lot of leaders can’t or won’t cover that, and frankly, lots of people have done great work without ever knowing why they were doing it. I agree with Simon Sinek, you’re a better leader if you Start With Why, but you don’t meet the basic qualifications of a leader if you can’t at least point the team in a direction.
That’s not enough, though. The gap was why I often found myself saying the equivalent of, “No, a different rock.” Working with Corey and his team taught me the importance of expressing the constraints, not just the direction. These allowed the team to take ownership of the design, which was absolutely critical to unleash their best work.
This framework of communicating direction and constraints provided necessary separation. I could step away, stop being in people’s faces and checking their work, and they could go off to their lab benches and iterate in peace, knowing both that they could quickly see if they were close, and also that if we had some sort of problem, we had something we could tune and evolve.
In the other big projects I’ve had since then, such as rebranding Puppet, designing new products, and hiring executives, this framework has helped immensely. With it, I am a better leader, and a more pleasant leader, and the teams I worked with do better work, faster. And we all enjoy the process much more.
Every founder understands the importance of culture in the long-term success of their company. Yet rather than valuing and supporting all employees, organizations like Uber still manage to build a toxic, poisonous one. How does this happen, and what can you as a founder do to prevent it?
We’re still in the early days of understanding how to build great culture. However, the barriers to doing so are surprisingly similar to another area where we’ve come leaps and bounds in the last decade: Creating great products. The similarities in their problems mean the tactics for solving them should be portable, too. In both cases, the barrier is essentially:
You’re creating for someone else, and they get to decide whether you succeeded.
Your opinion matters, but only as part of the feedback loop between your work and the outside world. Eric Reis and Steve Blank have done a great job of teaching us that facts live outside the building, and the real test is to go find them. You can’t rely on your own perspective, because you’re not the ones deciding whether to buy.
A product solves a specific problem for a specific customer, whose perfect solution might fail the very same problem on another person. When it comes to testing your product, the only experience that matters is that of your target customer. Failing them is failing full stop.
Your culture has the same need to dial into your audience. As the founder, it doesn’t matter what you think of the company’s culture. It’s not for you. But for better or worse, you do get to decide who your culture is for. A lot of these failures of culture are actually the CEO making bad decisions about who the culture is for.
For example, we all know stories of toxic employees driving other people out of the company. The excuse we hear is that this person is “too important to fire.” It’s presented as a choice between firing this person or making some people uncomfortable, in which case it’s easy to keep this high performer around. But that’s not actually the choice you’re making.
When you choose not to fire someone who harasses women, what you’re really saying is, “This person is more important to my company than women are.”
You’d rather your organization and leadership discriminate against women, have them leave your company, and have your people and teams suffer all the psychological damage that results from choosing to protect one person over a whole class of people.
It’s the same for an employee who discriminates against minorities, veterans, disabled people, or any other group. You can keep that one person, or keep the ability to hire from that entire labor pool.
Of course, that toxic person won’t actually prevent you from hiring from a whole group. That would actually be better in the long run. Instead, you’ll hire a few, but they’ll only stick around long enough to be almost valuable to you. People who stick around for one to two years are incredibly expensive - but your toxic employee will cause them to leave. You get to pay to recruit and replace them, to train them up, to watch teams form, and then to watch them fall apart again. And again. All because you couldn’t make a hard call on one person.
Conveniently, you’ll then be able to look back after a couple of years and say that these people who left just didn’t fit in, as though it’s somehow their fault that you’ve designed an organization that excludes them as target users.
I think there’s a strong moral case to made for inclusion, but you don’t need it. All you need is basic economics. Great people are scarce, and every group you exclude reduces that pool even further. Your investors want you to have the biggest possible user base to increase your addressable market; don’t you also want the largest possible employee base? Women are 51% of the population, and in the US, whites make up 72% of the population. If you only hire white men, with maybe trifling exceptions, then your target market is only 36% of the country. Reduce to just the working age population, and you’re at 22% of the pool. And that’s before you slice for experience, location, etc., much less silly requirements like a degree from an elite school and experience working at Google or Facebook. Every demographic you exclude reduces your possible employee base, and with it your chance for building a great business.
Let’s say I’ve convinced you. You have to design your organization to include other groups. Now what do you do to ensure it’s working for them?
Again, the facts live outside the building. Even worse, as the founder you don’t get the truth. Most people do not speak truth to power because they either feel unsafe, or actually are. Even worse, most powerful people don’t want to hear it. This attitude helps explain why a lot of cultures are so broken. You have to fight your instincts, your comfort, and often, your happiness to get the truth from those who own it.
In the fall of 2014, I had dinner with eight women who worked at my company. This was my most difficult experience as CEO. They were pissed off. Their experience was very different from what I thought was happening, and hearing it directly from them hurt.
I realized in hindsight that I’d made the tactical mistake of collecting the most upset women in the company - getting together with everyone who was having the worst experience- but that didn’t make their experiences any less valid or their feedback any less important.
Thankfully, I was aware of some aspects of what they were struggling with, and I was able to point to three separate projects I was working on, all with defined goals, owners, and deadlines, that would target what I thought were the biggest issues. But I had not realized how bad it was for them, and I was far from achieving my own goals in this area.
My behavior as a result of that dinner would make an explicit statement about who my company was for. I could have taken that deep pain, that searing discomfort, and run from it. I mean, I didn’t experience any of that, and all I had was these whiny women who had this problem. Right?
Would you accept that with your product? Would you dismiss the feedback of eight customers who were on the verge of dumping your product? Would you look at their feedback and say, well, it’s just eight whiny users, I can ignore them?
Many founders choose this path in culture. They keep around the bad managers, the toxic star player, or the oppressive HR policy. But like with your modern software, you have the opportunity - and I say the obligation - to do better.
So go, build your best culture, set high standards for your team. But be very clear about whose feedback you rely on to test whether you’re meeting those standards. If your goal is inclusion and diversity, which it absolutely should be, then you need to listen, really listen to diverse voices, and to those who are systematically excluded from most organizations.
If you can do this, you can emulate the Dodgers hiring Jackie Robinson and the Sorbonne University promoting Marie Curie as the first woman professor of general physics. If not, you will find yourself competing with them instead.
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.
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
