Agency. Exactly. You can just do things. Marry the outcome, not the process

And it also speaks to how I sort of see IC versus management, which is that it's not that management is going away. It's not that everyone's an IC, but everyone's kind of both now. If you're an IC, you're not typing code out character by character. You are managing something. You're managing agents, you're managing work that is happening that comes together to do a certain thing. If you're a manager of teams, you're doing the same thing, just at a different granularity.

Everybody's sort of defined less by the fence and the boundaries of where design stops and engineering starts, but more the average of where they're working. So if you average up all of the things that somebody on our design team does, there's plenty of code-writing things, there's plenty of things that are product work, but on average their dots are over here.

the most valuable person right now is someone who can take an idea from idea to done with the taste to know this is great. Just shepherding throughout, this obsession with making it awesome, this kind of high agency, high taste person

The same product ships six times before it works, and the shape never changes

• Product used to fail because of shape and communication. Now it often fails because the model underneath wasn't smart enough yet.
• You may need to release the same thing six times before it lands, with the shape unchanged each time.
• Whether a feature is good stopped being a question about its design and became a question about intelligence.
• Codex proves it. Andrew is confident the February Codex app would have failed in the market if it had shipped in November. Nothing about the product differed. The only change was the models between November and February.
• Operator, Atlas, Codex and ChatGPT all carry the same underlying feature. Operator didn't work out. Very cool idea, wrong moment.
• Re-releasing it with better intelligence changed the outcome completely.
• So don't be stubborn about calling something a bad feature. It might not be ready yet.

Decentralization only works with accountability attached

• The goal is giving people a unit they own, with real flexibility to pursue goals and real goals to hit.
• This gets underthought as companies grow.
• At 100 people it's a non-issue. The only place you need it is the management team.
• At a few thousand you need units that move quickly, make their own decisions and hold real autonomy. It's very natural to lose this as you grow.
• In a small company, people with decision-making freedom sit close enough to everything that they just do the thing that makes sense. That's what you lose at scale.
• It took Confluent a few years to go from fully centralized to product areas that act like 45% of a company.
• G&A is handled for them. They carry a revenue target, dedicated marketing, dedicated sales support, a plan for success and a plan for growth.
• The message becomes real: you own this, figure it out, don't wait for someone to come to you.
• The failure mode it kills is narrow ownership. I wrote the specs, engineering shipped it, design did their part, hopefully it works.
• Owners think end to end about what's working, why customers use it or don't, and what's holding back growth.

For engineering decisions, they're mostly knowable and there's mostly kind of right and wrong answers. But usually, especially the early phase of the company, you're making a lot of very big critical decisions with a lot of unknowable aspects. It will certainly impact how the company turns out and you know that, but you don't know what the right answer is and you won't find out until later. The CEO job generally, you operate much more in a kind of fog of partial understanding. I don't know that everybody understands that, but very quickly as the organization gets bigger, it's impossible to know everything about everything. And so you have to kind of be roughly directionally right.

in practice you can't understand everything about everything. You have to understand a lot about the most important things and enough about some of the other things, and try and make that judgment.

There's always two lenses in a company. One is what can we do? And then the other is what do we have to do? And so, what can we do? That's an opinion from the team. What do we have to do is kind of imposed by the world, the market.

Teams, because they spend all their time thinking about how to do something, they become very fixated on what can be done. And it's actually very important to step back and be like, hey, to be successful in this product area, what do we have to do? And then, it's weird. Once you know you have to do it, then you find a way to do it.

Diagnosing what's broken is the hardest work in a company

• You get a top-level result you don't want. Figuring out what caused it is shockingly difficult.
• A disproportionate share of the time it's people. It's also product philosophy, timing, and being a year early. It's genuinely all of those.
• Sometimes a team gets trapped in a failing mindset or methodology. Changing the person is really about opening the aperture on what that part of the org is willing to try.
• The default diagnosis is always sales. Sales are down, so the sales lead is bad.
• That's often right and commonly true. It could also be anything else in the chain of value leading up to the sale. That's the maddening part.

Nobody inside a function can diagnose a cross-functional problem

• Anything not working at a high level is inherently cross-functional.

• People in each function usually lack the global context to diagnose it, and personality decides how they get it wrong.

• Someone on the product team assumes the answer is more product features. Maybe. It could also be that nobody knows how to sell the thing, and they're not thinking about that at all.

• Other people go the other way and blame a different part of the org out of defensiveness.

• The CEO has to think flexibly about changes across every part of the org, which is exactly what diagnosis requires.

• The method is simple. Go ask everybody why this is happening, collect all the answers, work out which makes the most sense, and ask what you'd do if that were the cause.

• You're not doing it in isolation. You're aggregating views that are each too narrow on their own.

• You're doing all this inside a fog of partial understanding. Past a certain size it's impossible to know everything about everything.

• Aim to be roughly directionally right. Know a lot about the most important things and enough about the rest.

• Jay's target is knowing about 80% of what each executive knows about their function. Not enough to do the job, enough to know what good looks like and whether it's going well.

Tenaciousness, pain tolerance, I think that's actually probably the most important ingredient for the willingness to go after the things that you have to do.

And then I'm also just tenacious. I'm not necessarily an optimist. It helps if you're an optimist. Some of the best founders are just these inherently optimistic people. It gets you there if you're just determined. Where you're like, well, okay, then the probability is only 20%, but we're not going to give up until we've lost all hope, right? Just willingness to keep working on things well past the point where it's a bit painful is important.

We need to go through everything we are doing and rederive it, because, again, everything is based on a very long tree. Like, you start with axioms, and then you make a huge amount of decisions on top, and then you get to a conclusion, and that means this is how you spend your day to day building this thing because of these things. If any variable along this way is invalidated, what you should be doing is rederive the entire thing on top, right?

Again, people like to be consistent over time. I just don't find that important. I found the cheat code to always being right is just change your opinion every time you get better information. Because as you get closer to a point that you have to make a decision, that means you will wind up with the right one. It's like if you'd not stop at some point to incorporate new information

humans are reflexively scared of change, too. They'd rather be in a boring or even miserable environment than actually change, because the fear of change is so great.

Curiosity turns work into play

The best protection is always to be working on hard problems. Writing novels is hard. Reading novels isn't. Hard means worry: if you're not worrying that something you're making will come out badly, or that you won't be able to understand something you're studying, then it isn't hard enough. There has to be suspense.

Just being curious and wanting to learn about all the parts of the business and how it worked, our customers, how they work...

Business is something you make the peoples life better so there's infinite opportunities

Our capacity for harm is part and parcel of our humanity.

If you never encountered any Model, Care, or Execution failures, you would be God, and none of us are.

Remedies

Model problems?

• supply better information.
• interpersonal level: make the other person's preferences legible in advance, establishing standing defaults
• institutional level: the analogue is blunt explicit feedback
• premise: someone acting on a bad model is acting reasonably, so information rather than sanction is the lever

Care problems

• change the incentives or the relationship
• make the desired behavior cheaper or more rewarding
• ask directly to be prioritized higher
• if nothing shifts, the last remedy is to stop relying on that person

Execution problems

• treatment and structural workarounds
• find what actually works mechanically
• remove the failure point
• treat the underlying condition

Generic fallbacks when you're not confident in any of the three

• outsource the decision to someone with better models, care, or execution than you
• fall back on asking directly
• be conservative when errors are asymmetric, skew toward the cheaper mistake
• postmortem afterward: own the harm non-defensively, and on the other side, forgive
• without a culture that tolerates some mistakes, everyone plays defense and the whole framework stops producing good expected-value decisions

Fostering a culture of forgiveness with room for some mistakes makes MCE work way, way better. It allows us to make the best decisions in expectation for one another without having to play defense for every choice we make