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.

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.

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.

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.

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