Organizational structure determines product outcomes

There's different types of PMs... it's not really about is this person good or bad or whatever, it's is this person's skillset and context to the problem that is really needed.

We have something called a five-day escalation rule, which makes sure that if someone has something that they haven't been able to escalate and solve, that's probably then on the next level of person.

I believe a central model, a center of excellence is superior... You get more consistent and higher talent, growth opportunities, consistency of methodologies and metrics, and team culture brand.

You have to make sure that it is thought of at the C-suite. What some organizations do is go, 'Oh, no, that's IT work. Let me push all the software strategy down.'

Organization design and empathy... I recognize the job's different. It's more about building a great team, creating the right incentives for the team on blocking them, guiding them, and helping them work efficiently. Those mattered way more than anything else.

I think that by eliminating or reducing the size of the team, we've forced other people in the company to think like PMs and I think it's been a huge value add to our culture.

I think you want to be able to be innovative and pivot and when you have a well-designed sales plan or a very structured sales plan, that can be challenging.

As you cross a hundred to 200 people, somebody has to be responsible for knowing how data flows through tools, how it's worked, what's the schema. And that's not even considering procurement and legal stuff. You have infinite liability if you don't manage your contracts well.

As you grow the company, scaling in increments of seven engineers just creates a ton of overhead. So, obviously, our teams now tend to be much bigger, maybe two, three times that at least per manager to maybe have 14 or something instead of seven and just less overhead roles.

There's no perfect org structure. It's like the Toyota Kata, like grasp the current condition. You'll experience you have challenges. What's the next evolution or the next target condition? How might you get there? And then you're there and you're like, okay, grasp the current target condition.

A lot of large companies turn to Scrum or to the frameworks, and it's because they traditionally didn't grow up building software.

It's always too early until it's too late. Founders will go to their lawyer and the lawyer will say, 'Listen, sounds great, but you don't need to do that right now. You can always do it later.' And then it's 18 months from the IPO and it's 'too late.'