What If You're the CEO

At a lot of companies, if you could see engineering productivity plainly, you would be horrified. The 2:17 question is often the correct question.

It is not that people are lazy. This is not George Costanza inflating his workload for show. These are good, talented, well-paid people who fully believe they are working, because everything around them is shaped like work. The overhead accumulates in layers: internal meetings, standing one-on-ones nobody can explain the purpose of, middle managers who generate work for each other and then for the ICs above and below the exchange. Stewart Butterfield has a phrase for the result: hyperrealistic work-like activity. It fills the calendar, it produces artifacts, it feels like effort going up, and very little of it touches a customer or a line of shipped code. A CEO can sense that aggregate without being able to name a single offender, which is exactly the kind of dread that waits until 2:17 to present itself.

The antidote is the one this course has prescribed to every product person in every chapter: go to the primary sources, and put them on a loop.

Here is my own practice. I am not in our codebase every day anymore; I see the commits and pull requests weekly. But the engineering standup notes are pushed to me daily, and I read them. So when the 2:17 feeling arrives, I know exactly where to hop in. Why are we redoing that? Is anybody on this one? Let's talk about it. The panic has nowhere to live, because everything is verifiable in minutes. If instead I had to schedule a meeting and receive a presentation to learn what people were working on, I would be panicked twenty-four hours a day, and I say that while working with the most customer-connected engineers I have ever been around.

A CEO can ask for this in the morning and have it by the next morning: standup notes, shipped changelog, work in flight, work that's stuck and why, all of it connected to the priorities you named at the last company meeting. Will builds this brief as a standing loop, on live data, in this chapter's video. The build takes less time than the meeting it replaces.

A driven CEO should also demand a real definition before chasing a vibe. Mine: you are a product-driven company when R&D as a percentage of revenue is rising, the stock is rising, and the market, understanding exactly why, tells you to keep going.

Atlassian through its most impressive stretch is the reference case: an enormous share of revenue into R&D, sustained for years, and the market's verdict was keep going. That is a fact rather than a self-image. You can read it in the analyst report and you can feel it walking through the building, and the two agree.

The daily instrument for the same measurement is the two-sip answer from Chapter 4. If you can stop anyone on the engineering floor, a co-op, and the story of their work connects to the story of the company inside two sips of your coffee, the analyst report is downstream. If nobody can connect it, no amount of R&D spend makes you product-driven; it just makes you expensive.

If a CEO who wants all this keeps stubbing a toe on product, my first guess is the toe is voice.

The first person who ever made me a head of product taught me this. It was his company; both of the product managers had just left for grad school, and he took me for a walk and said we needed iPhone apps for a particular customer and I was the only person in the building writing software with an iPhone in my hand and strong opinions. That was my break. And early on he told me something I've repeated ever since: "I have different voices. I am the founder and owner of this company, and there will be times when I use that voice. I also use the software, and I have opinions about the software. The fact that I'm CEO has nothing to do with the fact that I use the software."

David Scott, an investor and board member I learned an enormous amount from, practiced the same discipline past the point of necessity. He would write me about something he'd hit in the product and always begin the same way: I am saying this as a guy outside Boston using the software on my MacBook, trying to do a thing; take it in that spirit and no other. He was a sharp product thinker, and he was guarding against exactly the failure he feared: that I would take off my product hat and read a board member's stray observation as a directive.

You can make the discipline mechanical. Put a label on every piece of product input you give: a hashtag that says what it is, running from directive at one end down to random thought at the other, the bottom rung marked for the dream interpreters only (Chapter 5's job description). Whatever the labels, the point is that the culture has defined the voices, so a musing can be a musing without freezing a roadmap. The same mechanic cures the inverse problem: the masterful operator who spends ninety seconds disclaiming that they're not a product person before dropping something you needed on your radar. Once the voices exist, they can just say it.

At the far end of the range sits the decree, and you should know the great ones. When the market decided Facebook couldn't do mobile and the stock sank after the IPO, Zuckerberg called a company meeting with one slide that said mobile, and the internal web version of the product was shut off so that everyone at the company lived in the mobile app except the people building it. Mike Vernal carried the product leadership of that turnaround, and it made the company. At Slack, when enterprise arrived at IBM scale, the memo as the story reached me said: our roadmap for this year is no roadmap; everything works to five nines. Elite conviction, total clarity, company-defining results. Keep the decree in the drawer as a real option. Just remember that Zuckerberg and Butterfield are elite product minds spending that voice about once per era; a decree per quarter is a louder way of having no voice at all.

The voices inventory governs your output. The input side is the same primary source material the rest of this course runs on: everything in one place, indexed, permissioned, multiplayer, so you can be the best-read person in every conversation you enter.

I get everything from our sales motion pushed to me: the themes, the details, the moments. I am not a salesperson and I don't walk in telling sales leadership how their world works. But when I have a question, I arrive having done the homework, with a mental model on the table, asking to be corrected. What happens next is the entire payoff: the person briefing me skips everything I already know, says "great, here's the new thing," and the conversation starts at the frontier. Someone catches me by the couches to update me on a deal at the finish line and can refer to everyone involved by first name, because I've met them, watched the clips, read the thread. It's not a set of best practices. It's attitudes and information: an expectation of being caught up, so the human part of the conversation covers the gap that remains. When everybody arrives cold, finding common ground is the whole meeting; when nobody does, the meeting is short and it moves something.

None of this survives politics unless the CEO underwrites it. Chapter 8 asked the product team to flip its cards face-up on the table. If another department comes for their throat the first time the cards show a wart, and you let it happen, they will fold the hand and go back to glossy decks, and they'll be right to. Only the CEO can make it true that exposure is safe: that trying and missing in the open is treated as better than hiding.

One story about what the reciprocation buys. At one point I built a way for our executive team to stack-rank the product priorities: every functional leader, independently, across the whole roadmap. Then I showed the combined ranking next to the ranking our own product team had already committed to before the exercise. They matched. It took hours, and it only had to be truly done once. The next year at the offsite, when I announced it was stack-ranking time, the functional leaders answered: we're good. We trust you. The year after that, one leader was ribbing me about the ceremony, and the CEO cut in with "just do it, they're gonna do whatever they want anyway," and the room answered with a warm laugh, because by then the line was affectionate and everyone knew it. The ranking had become a ceremony precisely because the trust underneath it was real.

When the product team is gracious and vulnerable, and the CEO answers with trust and models that answer for every other leader watching, being gracious and vulnerable becomes okay. Shortly after it becomes okay, it becomes cool. And if you want to know what your company's culture actually is, ask anybody who works there one question: what's cool here? Whatever they answer, that is the culture.

An incoming CEO gets one extra chapter of advice, because arriving with a mandate for change is a different situation from founding.

Your arrival is a re-adolescence for the company. Some resetting of flows, ownership, maybe business model is expected, and that expectation is an asset; use the tender moment. Two traps sit on either side of it. The first is obvious: "this is the way it works here" does not mean the way it works here is correct. The second is subtler and I have watched it tear organizations apart: when something genuinely does work, especially in the wake of an intuitive, reality-distortion-field founder, you must understand why it worked before you touch it, or decide explicitly to leave it alone. Cultures with real power on the front lines look self-operating from the outside, as if your only job is not to screw them up. They are not self-operating.

Autonomy comes not from the absence of rules, but from the presence of very few, very simple rules.

If incoming leadership cannot articulate and repeat those few rules, the magic goes. You will not be operating at the edge of chaos; you will have actual chaos, and it gets ugly fast.

Then lead from the front. Do the world tour, and produce something with your own hands along the way: sit with the CS leadership and whiteboard the pie-in-the-sky view of your accounts, show the photo of the whiteboard at the next all-hands, then show the real thing running, and give the credit away even if you built it yourself. The single strongest reason people want to work for a boss is the boss's ability to do their job with some mastery. I am a student in every function, and in some I know just enough to sketch a mental model. I offered mine on partner programs to Brian, who is a black belt in them, and he told me it put me in the point-one percent of CEOs he'd met. It was not a sophisticated model. The bar is that low, and the trick is the same one this whole chapter teaches: have the conversation rooted in the source material. Have the numbers, the names, the faces, the clips. Have it hit your heart while it hits your head, and people will trust you, and they will tell you the part of the story you're missing.

If you're the CEO:

1. From memory, list everything you currently want to say to the product team, from the existential to the petty.
2. Label each item: decree, strong opinion, user feedback, or random thought for the dream interpreters. Beside each, guess the label your team would have put on it.
3. Run the prompt, then deliver the list with the labels on.

If you lead product:

1. Write the company's top priorities as your CEO would state them, and the question about R&D you think wakes your CEO at 2:17.
2. Run the prompt to build the one-page morning brief that answers it.
3. Hand the first edition to your CEO, ask what they would open first and what's missing, then put it on a schedule.

Paste this into whatever AI you work in, ideally one connected to your company's material: Claude Code in a company-brain folder, Cowork, Codex, or similar. It works from either seat; finish your list first.

CEOs and founders, obviously, and it works read aloud to one. If you're a CPO or product leader, read it as the request list: the brief, the voices, the backing are all things you can ask your CEO for by name, and building the first one yourself is the fastest way to get the other two.