Real quickly, the book, it's a pride and joy.

I actually never really anticipated writing a book, so super, super excited that I happened to write 1 somehow.

And people always ask if you should write a book and authors are kind of obligated to tell you not to write a book, but personally I actually really enjoyed the process.

So if you're considering it, I would highly recommend it.

So what I wanted to do is just like talk through a handful of sections of the book that have been kind of the most controversial or the most interesting and kind of talk a little bit about what the book says and maybe how my thoughts may have Evolved a little bit over time and and this should be fun So that interestingly the thing that was most controversial in this entire book is the first the very first chapter And I'm assuming in part that's because people never read past the first chapter and when they wrote articles, they just had to focus on whatever they actually got to.

But it was this idea of like sizing teams.

And so something I've been like a firm believer in for a long time is that really simple things that you can just do tend to work better than really sophisticated solutions.

And so when I think about organizational planning, I basically call this like org arithmetic, or like the rule of 6 and 8, or I think you can literally design any engineering organization the best possible way is just to divide the entire headcount by 8.

That's the number of teams you have, and then to divide the number of teams by 6, that's number of managers and managers you have.

Then you divide the number of managers and managers by 6, and that's the number of directors and so on.

I've never found any way that works better than this.

And this way, actually, I think, addresses many kind of common flaws in org design, where you often design around individuals, and you end up in really lopsided orgs that just don't quite make sense.

If you've never tried this, and why would you?

You might think org design is like a sophisticated science of some kind.

I think it's just an amazingly useful exercise to just sit down, take your current org, run this exercise, just divide it by 8.

Figure out kind of what are the different areas you think are worth having a team around and see what happens and see how close your org chart is to that or isn't.

I've just found it to be remarkably effective.

And it works even better, I think, for kind of planning into the future.

So something that I found as you talk with smaller companies is that you often don't have like a plan about what the world looks like next year.

Like if, depending on where you are, like any time spent on anything other than getting in market and kind of selling the product, improving the product, like winning as a business might not really make that much sense.

But once you start growing a little bit quicker, Like once the product actually starts having fit, taking just literally 2 hours every 3 to 6 months, and just thinking about where we'll probably be next year, divide that number by 8, run the org plan, figure out like how many managers will you need a year from now?

It's just such a useful exercise, and it's so easy.

You can take a spreadsheet, you can do it in literally less than 2 hours.

And the hardest part is, as always, getting accurate headcount data from whatever people software you have.

And if that's the hardest part, it should be relatively easy overall.

So I just think doing this works so well.

But yeah, people have really reacted to this at times with some anger that you could approach it this way.

But rules of thumbs are not mandatory rules that can't be broken.

Some teams, if you're working with the same group of people for 4 years, you can manage them really differently than if you're working with a group that you're hiring so quickly, or you've worked with most people, like an average of like 4 to 6 months.

If you work with a team for 4 years, you know what they want.

They know you, you don't necessarily need frequent one-on-ones with the team that you're, you're that close with.

You can do totally different things on the edges, and I totally respect and acknowledge that.

But think about it, give it a try and see how it goes.

If it's such an obviously bad idea that no 1 should ever do it, I would recommend just trying it and seeing what happens.

I think you might feel a bit surprised by it.

The next 1 that also had a little bit of controversy is this idea of just like 4 states of teams.

So I often find that people wanna think about teams kind of consistently, where like, oh, there's this 1 way to deal with teams, and you should always handle teams in the same way.

My experience is that when teams are really on fire, that you have to be, oh, sorry, just going to jump back to a question from Matt Anderson about kind of sizing remote organizations this way.

At my previous role at Stripe, we were about 25% remote in engineering.

I've never done this with a fully remote organization in terms of sizing the 6 and 8 rule.

I did manage a couple of remote managers who had remote teams in the previous organization that I was working with.

And also within Calm, 1 of our teams has a fully remote team, our DevOps and infrastructure group.

I've never done it with a fully remote organization.

My inclination though is that this should just work.

My experience is that as a fully remote manager, your management overhead is a little bit higher than in terms of people in the office.

So I think you might adjust the numbers a little bit.

Maybe you take that 8 down to like a 6 or something like that.

But my inclination would be this would just work, but I'd love to hear back if you find it didn't quite work out that way.

I think you have to really think about things differently than if a team

And so this is like 1 of the ideas that I put forth is kind of 4 different states.

In a state that I see particularly in infrastructure teams is like falling behind.

You also see this in like customer support teams.

You see this in all sorts of other functions, but typically see it most in engineering on infrastructure or kind of internal service teams of some kind.

And falling behind is like each day you wake up and there's more tickets for you than the day before, because you simply can't process the work at the rate that it's coming in.

And The thing that you can do there is you just have to make brutal choices about what to do.

And you really have to look ahead and think about what can I do today that will create capacity to succeed tomorrow?

And I think if you're extremely diligent about that and really focus on the long term, instead of doing the short term impactful work.

Because if you optimize for the short-term when you're already falling behind, you know you're literally doomed, not far out.

And when I joined Uber, this was really the state the infrastructure team was in that I was part of.

Each day we got a request to do provision, like a couple more services, like microservices.

And each 1 of those took a couple of days.

Every single morning we woke up and came to work, we were like worse off than the day before.

And we had to make some really hard choices about not supporting people who desperately needed support.

And initially the business is gonna think that you're really doing the wrong thing and you have to really spend time explaining the story of what you need to do to support the business in 12 months, in addition to kind of sustaining it today.

Find the long-term leverage work, even if

And If none of those work, the only thing you can do is hire.

I think this is 1 of those places where you have to have some managerial courage.

I think a lot of teams will ask for headcount and give up.

If you've tried all of these techniques to dig out and your leadership isn't willing to invest, you just have to keep emphasizing that nothing's going to change and that they'll continue to be frustrated with you indefinitely, which is bad for them, bad for you, bad for your team, just not a great situation.

You see a lot of teams, which if you finally hire enough, you graduate from falling behind to just barely keeping up.

And I actually think this is a pretty good spot to be.

Because Once you start treading water, you just need to find 1 small investment that's going to pay off and all of a sudden you're, you're, you're back into a better spot.

And so often I think we, we talk about trade-offs between long-term work and short-term work.

But engineering is also this like inherently like creative activity where we can be really thoughtful, we can find like these.

Different approaches where it's not, not this like fixed trade off between, Oh, we can invest in automation or we can solve the customer problem.

And I think constraints are where a lot of our best work comes from when we don't really have enough capacity to solve it in the correct way or in like the standard way.

And we find like a different path that can actually be better than what we have previously seen, what we've been told is the kind of gold standard to solve something.

And so I really think when we're treading water, we can't get ahead.

This is like the opportunity for us and our teams to be at our most creative or our most brilliant as kind of engineers and not just kind of methodical implementers of what we've seen before.

And this is to me like 1 of the most fun times for us to kind of be able to actually change the trajectory of a company without just hiring.

Hiring is always an option, but hiring is never the right first option.

There's always room for creativity and innovation by the team, but before you kind of move to the hiring lever.

Unless you're just clearly falling behind so much you can't think and then got to hire a little bit in.

Once you got out of that, you can start repaying debt, just continuing to find long term investments that get a little bit more leverage, then finally you move into this innovation mode.

And something I find really interesting is I think a lot of teams are so addicted to fires.

Is like once they finally get out of kind of repaying technical debt and they have the opportunity to do something really impactful.

They finally get into a Greenfield project.

They have no idea how to pick something with that much flexibility.

They just can't explore the possibility space with that many options, and they often pick something that's not very useful to the business.

I think like a classic example is you'll find teams that like finally get out of a bunch of tech debt and they're like, oh, we need to write a brand new framework and migrate to this new framework.

And your users have never been sitting at home, like using your product and thinking like, I wish they used like a brand new framework, like your users don't care.

And often there's not that much clear value around these like migrations from 1 tool to another.

And so I think it's so important once you finally get that moment to really reflect on what the company needs, what your users need, and make a practical, thoughtful choice.

So often engineers have a backlog of what they want to build.

And so often we, as like engineering leaders have this backlog of things that intuitively resonate with us as a useful impactful, but we haven't really thought about the full set of things we can work on.

And so I so often see teams finally dig out.

They have the opportunity to do literally anything that's useful.

And then they build something that just gets them right back into the slog again, that, that actually is not, not valued.

And either they're back kind of falling behind overloaded, Or I even see teams that get defunded after this, where the company is just like, this team actually shouldn't exist because they just can't understand the project.

So making sure you're super thoughtful when you have that opportunity and invest it the right way is how you then get more and more of that opportunity over time.

When I was at Uber, I wrote a blog post around hypergrowth, which turned into a chapter about hypergrowth as well.

pretty interesting dilemma in the sense that there are a few most management situations you can actually make mistakes and recover.

When your company is growing extremely quickly, and Uber at that point was doubling headcount every 6 months, Stripe for the period that I was there was growing, engineering was growing about 60% year over year, every year from about, I think 150 when I joined to a little bit over like maybe 11 or 1200 engineers when I left Stripe and Uber went from like 200 to 2000 in just like a 2 year period while I was there.

The interesting thing about hyper growth is that you see the results of your decisions so quickly and you experience the consequences of them so quickly that I think it really penalizes mistakes in an interesting way that is both, I think, 1, extremely painful.

And I always told candidates when I was pitching Uber, the best thing about joining Uber is that when you don't solve problems that hurt so badly, you make sure you solve them very quickly.

You never have a lingering problem because the pain became just insurmountably awful quite quickly.

I'm not sure if it's a good pitch, by the way.

And I really think hypergrowth is rewarding because it allows you to learn so many things so quickly and see that there was feedback on your decision.

So quickly, but to me, the thing that's been the most helpful in these situations, where I think like our, our general mental models, like just struggle to think about the rate a company is growing or expanding is really systems modeling.

And so there's a series of techniques, the book goes into a little bit more.

But using them to model basically what happens when you look at the number of people that you need to have, then you back that into the number of people you need to hire.

And then you can have a whole recruiting funnel, and then you

have the number of people you need to hire.

And then you can have a whole recruiting funnel.

of people you need to train, number of interviews you need to do, and how many trained interviewers you have.

You can actually back all of this into a spreadsheet, or there's more sophisticated software as well.

You can just understand if what you're doing makes sense.

I think it's so easy to get into a spot where you actually are getting slower because of the interviewing load, because of the training load, the interview training load, the onboarding costs, just all of this.

And it's really hard for companies to acknowledge that they're following a hiring strategy that's actually making them worse off.

And I think often we put our teams in spots where we basically frame them as not working hard enough or not being committed enough.

They can't just overcome this huge quantity of scaling problems we throw at them.

But I think that's really on us as leaders to be much more thoughtful, more aware and cognizant and deliberate about the things that we're putting on our teams.

And so I think just taking the time to model out how does your full funnel work, including training of the interviewers, including onboarding, including retention, and really looking at that and understanding like how fast can you grow and how does that impact product velocity now if you do that level of growth, I think is so important.

And that's really to me just the core theme of the book is like how can we be more accountable and responsible for our decisions?

And through that accountability, learn how to make better decisions.

And through better decisions, lead better orgs that are more effective with healthier engineers that are still more impactful for the business.

And I hope that theme comes through in the book overall.

So I think strategy is kind of like an overloaded word.

It's pretty hard to say what strategy really means to most folks.

There's a great book whose name I just quickly forgot, which has a framework for, yeah, good strategy, bad strategy, there we go, which has a framework for what a strategy is in just like 3 parts.

It's a kind of analysis of the status quo, like how are things actually now, it calls it a diagnosis.

It's guiding principles, like what are the general approaches you want to take to improve?

And then it's like actions, like what specifically will you do to apply your guiding principles to the diagnosis?

The most interesting thing to me is I've applied this approach like a number of times over the last like several years Is that the biggest challenge is I find like often people don't agree on reality And so I find that like kind of fascinating because I think when you get a bunch of really smart people working at the same company, you sit down and you're like, we have this important problem that I want to work on.

We're like, Oh, we should hire more people.

Oh, it's our, our development process is actually slowing our team down.

You like have all these like solutions, but like classically, if you actually agree on what the problem is, picking a solutions, like almost always like quite easy, if you have some data showing that you're getting stuck in QA, then like either changing the QA process or hiring more QA, like dead simple, obvious.

If you have data showing that your team's actually launching at a really high velocity, it's just like more user requests coming in and they can get to even at that, then Maybe it's like re-architecting or maybe it's like hiring again.

But if you don't have this data, you start solving, you can't actually do a very good job at it.

And then you have really smart people who are really capable debating kind of in these different worlds, and then they can't get on the same page because they have all these unstated assumptions that just don't sync.

So if you were thinking about a really hard question of strategy, I think the brilliant strategy is a lot less important than I once thought it was.

To me, the really important thing that gives you like 99% of the way there is just agreeing on like what's actually happening right now.

And particularly when you have people with different perspectives on it, I think that can take some time.

And if you simply sit down and you're like, what's actually happening?

I think it's just remarkably impactful to solve problems, so just sit down.

It also removes a lot of the anxiety and the conflict from it, because you're just like, what's actually happening?

You talk about it, and then you can just ask questions You don't even have to say what's happening You can just have a lot of questions and have the kind of truth Bubble out and identify the data you need to like really agree on the truth But you don't actually have to argue about the solution.

The solution is trivial once you actually agree on what the problem is.

Career narratives are an interesting technique that the book talks about a fair amount as well.

we kind of developed this technique together.

Although I think literally millions of people have developed this technique independently, it's not kind of novel.

But I think something that you run into is a lot of people, particularly earlier in their career, kind of view their career evolution as the responsibility of their manager.

And I think in some companies that is kind of how this works.

But particularly in small, fast-growing companies, like managers are really busy as well.

And they're often busy kind of doing business critical gap filling, where there's a role that you haven't hired before, and you as a manager just have to fill the gap.

And once you hire someone or like train someone to close that gap, there's like another business critical gap.

And I find like development often falls on the wayside.

And I think that's, again, something that we can be really methodical about as managers and leaders to make sure we don't skip over this work that is really impactful but not on fire.

And so we developed this idea of a career narrative, where it's really pushing it a little bit back on the individual to think about like what they want to do to develop themselves and what their goals are and really asking them to bring that document.

If you've ever seen like a manager readme, I think these are super controversial.

I personally don't love the manager read me.

It's kind of like to talk to Will, like please write a document first.

It kind of like gives people an algorithm to interact with you, which feels like a little bit

But like a career narrative is more like the person

It's like, here's how I want you to support my growth.

And I think that's like a really powerful conversation for people to have.

And I think it really has to come from them at

I think as a manager, you can give them questions, you can give them themes, you can give them role models and talk about how the role models have done their own evolution of their careers.

But you really do have to have some of it come from them.

You can't just give them the career that you would assume for them.

And I found just having a written career narrative is incredibly impactful.

And you can just review it every 6 months, every year, it really would depend a little bit on the company, just to identify areas of development and growth.

Because that's the other thing that I think is really helpful is that as you really focus people to talk about what they want, you can focus them to move away from these really transactional things they want, which is like, I want to have this title.

Like, I want to have this, join this meeting, or things like that, which are like scarce resources that you can't just give everyone access to this 1 meeting, the meeting no longer works when you have more than like 6 or 7 people in it.

So how do you take away kind of status as a thing that people focus on for growth and instead like really push them on to development?

So speaking, group leadership of projects, writing, access and communication to executives, which is like a kind of a mind-blowingly challenging skill for people early in their career who haven't been exposed to kind of the executive mind, if you will.

This has been something that I think is incredibly helpful.

And just maybe riffing on this idea just real quickly, I've also spent a fair amount of time thinking about how should we, as leaders, think about our careers.

But People get so stressed out about having the right career.

2020, We're some of the most privileged people in history, and certainly some of those privileged people right now.

And it's okay to be methodical and thoughtful about what you want.

There's gonna be a lot of opportunity, but I find a lot of people have this privilege, have this access and opportunity, but keep taking jobs that they hate.

And I think it's really kind of interesting to think about how our view of what expectations should be for us in our careers, and then our needs get like swallowed up because I think often some people aren't even really clear about what they need from their careers or from their roles.

And I think it's really kind of terrifying to see at times.

I've thought about is that no career has to be a straight line.

And what you need from your career and your job over time can change.

I think I'm quite, quite close to having my first child.

And I think my amount of availability for some of my writing, some of my speaking is just way lower.

Even just the mental capacity to think about writing something professionally is just vastly smaller than it was even a couple months ago.

I think you're a person, you're not a machine.

You have to listen to yourself and think about what you need to get.

And so something I've thought about as the way to think about different opportunities and what you want kind of at different points in your career, is thinking about how do you develop your network, the people element.

Going to larger companies at certain points creates this amazing breadth of connections that is so valuable to you throughout your career, and no matter what size you go on to later.

It's so much easier to develop a huge network if you go to a large company.

You just can't really do it with the same level of effort as small companies, because they're just much smaller, there's fewer people can actively network outside of it, but with no effort at a large company, you'll need thousands of people.

your career, you have to think about managing your pace.

In terms of just the amount of work you can actually put into your job versus balancing with the other things around you, and that can be family, that can be causes.

But also I think I see a lot of people who just like bounce from burnout to burnout.

And it's unhealthy and I think it's easy to get caught up in that.

But if you, you know, you can't really do your best work when you're on the edge of burnout all the time.

I think just finding some ways to create some space for yourself to pause and heal.

See all Insight Partners transcripts on Youtube

Insights From the Author of "An Elegant Puzzle: Systems of Engineering Management"