Blitzscaling pt. 2: Management

Here’s some notes from the second part of Blitzscaling by Reid Hoffman, where managing a growing company is the topic.

I can relate to much of the book, as I stayed with my former employer while growing from 10 - 100 people over the course of 3 years. I really enjoyed someone putting words on some of my feelings <3

See also pt. 1 for what Blitzscaling is and when to consider it. This part is more generally on how to manage a company of different sizes, which is relevant for any company of any size in any situation.

Summary

This part of the book is about internal struggles of a company and what is should prioritize in different phases / sizes. It’s my favorite part of the book, and I think there’s a lot to learn for any company, especially startups of any size, and particularily those who are growing.

Reid introduces eight transitions and nine counterintuitive rules. Learning them can give prevent feelings like:

Things are not the way they used to be (and I don’t quite know why)

I’m loosing control/ownership/influence (and what should I blame for it)

How come this new person is suddenly telling me what to do (I know better).

Why don’t we fix these obviously wrong things (I am no longer proud of what we make)

No one listens to me anymore, instead I’m being told things (that I disagree with).

These transitions will occur, and if they happen by themselves I think they’ll cause many of the thoughts above.

This post is a bit long. At the bottom of this post is a TLDR of tips from the booking (my own summary).

Terminology

Family, Tribe, Village, City, Nation

These are terms describing what scale the company has. As a rule of thumb, these are 1, 2, 3, 4 and 5-digit number of employees (Familiy 1-9, Tribe 10-99 etc), but it’s not a strict scale.

It’s important to differentiate between the different scale of businesses because there’s completely different ways of managing them. Culture is necessarily different. How you make decisions is different. What kind of people you hire is different.

Eight key transitions

1. Small teams to large teams

At the Family stage, it’s often the case that every member of the team is involved in every major decision. At the Village stage and beyond, this is nearly impossible.

On transitioning from Family to Village size, and not having every team member involved in every major decision:

For new employees, this state of affairs will seem normal, but for early employees, this shift can be disconcerting, leaving them feeling like they used to be insiders but are now treated like outsiders. The answer is not to involve these employees in every decision – that would be inappropriate and logistically impossible. Rather recreate other systems to help them feel connected to the company’s mission.

On tranisition away from the family and towards the village stage:

You’re adding qualitatively different kinds of people to the team. One metaphor I use to explain this shift is to take an analogy from military history: the marines take the beach, the army takes the country and the policy govern the country. Marines are start-up people who are used to dealing with chaos and improvising solutions on the spot. Army soldiers are scale-up people, who know how to rapidly seize and secure territory once your forces make it off the beach. And polic officers are stability people, whose job is to sustain rather than distrupt.

Ok, I’m probably a “marine” then. Nice! Reid then continues:

The marines and the army can usually work together and the army and the police can usually work together, but the marines and the policy rarely work well together. As you scale, you may need to find new beaches for your marines to take rather than ask them to help patrol the existing ones.

I like this. I feel like this maybe was the main thing that caused me to quit my previous job. In 2017, I made and launched a platform on my own initiative while the management team were on summer vacation. In 2019, I added translations and yet another form to the platform to comply with legal, or modify it to fit another market. And no longer on my own initiative – I had a manager added between myself and management who had already decided that task.

2. Generalists to Specialists

Family stage

During the early stages of scaling, the need for speed and adaptability places a hefty premium on hiring smart generalists who can get many different things done in an uncertain and rapidly changing environment. But as the company grows, it needs to shift to hiring specialists who are less fungible but have expertise in an area that is crucial to scaling the organizaition.

First, I am a generalist. Or a “potato” I like to call it. I love rapid, I love having to learn new things. I want to do everything. When asked what I’m good at [within my field of work], I say “nothing, but I’m decent at almost everything”. The quote above sements my feeling of belonging in a startup environment.

Moving towards village stage

The transition that occurs when you bring in specialists to manage or replace generalists can strain the morale of the organization. Demands for functional expertise often outstrip early employees’ abilities to keep up through organic learning. […] As a consequence, functional leadship titles increasingly go to outsiders, and the legacy folks may grow resentful.

Word! It hurts when new hires take some of the most exciting new tasks that I wanted to learn how to do. I feel like I could’ve grown to become a much better potato if I had got the management or machine learning opportunities that were filled by new people.

3. Contributors to managers and executives

Managers are frontline leaders who worry about day-to-day tactics […] By contrast, executives lead managers [and] focus on vision and strategy.

In the family stage, one might not even need a manager role and if one does, then that role is often filled by the CEO or founder.

A managers role is to make a team productive on a day-to-day basis.

Managers are needed in the Tribe stage, though it may not need the executive roles: The vision, strategy and path forward is often clear enough at this stage to not need a designated role to lead it.

Managers are often promoted from contributers (early, existing employees) who emerged as natural leaders. A more challenging choice is to hire managers from the outside. (From personal experience…) early employees are often selv-driven, given a lot of responsiblity and feel more ownership that employees hired at later stages. Introducing someone new to the team to manage them can feel like they are stripped from responsiblity and influence, and demoted to a “do-er” in the company, rather than a “builder” of the company.

Reid has some tips on how to hire externally for leader roles:

• Hire someone who is already trusted by at least one member on the team
• Hire them to a lower level initially, and consider promoting them after they’ve gained the teams trust.

When a company reaches the Village stage […] build in an executive layer to keep things running smoothly.

Reid calls this the “standard Start-up Leadership Vacuum”, when a company entering the Village stage needs an executive. He has a few concrete tips:

• Hire executive before you need it.
• The hire must be open to learning and doing things the company way, rather than leading the company their way.
• Hire the executive who has taken companies from your new stage, say Village, to the next. A Family -> Village or City -> Nation CEO is not a good Village -> City CEO.
• Hire the executive you need now, not the on you’ll need later.

4. Dialogue to broadcasting

Every team member can feel heard in the beginning of the company: You’ll likely sit in the same room, everyone has time to hear each other out. There’s almost no time spent for meetings and coordination. You have time for dialoge, but as the company grows, that just doesn’t scale: communcation forms have to change.

[In the Family stage, you got] “praire dog” style of communication that is organic, quick and effective. Everyone is still working on the same initiative, so the interruption is likely relevant and/or productive. The biggest challenge you likely face is keeping the rare virtual employee in the loop.

When the company company grows into the double-digits, this don’t quite work anymore. You’re in different rooms, working on separate things. Some structure is needed to planned meetings or gatherings.

The Tribal meeting should be well organized, with an agenda and other materials provided in advance so that perticipants can engage in an interactive discussion rather than simply listen to senior leaders talking or suffer through text-dense PowerPoint-presentations. The goal shouldn’t be to make decisions in theese meetings, rather it’s to maximize input from smart people and make sure that everyone feels heard.

As in most of the other transitions Reid describes, it’s about maximizing good input, making everyone feel heard, a part of the team while still staying efficient. I actually think this might summarize half the book?

When the company grows even larger, making everyone involved and heard might become too hard, and one should instead aim for feeling included and informed(?)

Brian Chesky addresses this need at Airbnb by sending a long e-mail to every employee each Sunday night. The email isn’t simply a recitation of key performance indicators, rather, Chesky shares his thinking on a topic he considers important to the company.

Typical changes in internal communication as you grow:

• From being open about everything to deciding what’s secret
• Discussing with everyone to discussing with a group
• Informal, in-person conversation to formal electronic broadcasting

5. Inspiration to data

“If this is a decision based on opinions, then my opinion wins”, said Jeff [Besos]. “However, data beats opinion. So bring data.”

This! It’s (brutally) honest, direct and also totally right. Bring data. Seniority means something, but it does not trump data.

But also, “if you don’t have customers to listen to, the best you can do is listen to your gut.”.

Data is good, but might be hard to come by if you have 8 customers, or 120 people have visited your site.

I strongly believe that as a whole company, you can’t get behind more than three to five metrics.

A quote from Selina Tobaccowala, who built up the SurveyMonkay infrastructure. And I believe Jeff Doer, the author that popularized OKRs with Measure what matters said more or less the exact same thing.

This quote is a really important tool to have when you make a dashboard to someone. They will automatically come up with 3+ metrics, then a couple more the week after, then another 4 one month down the road. The end result of which is a dashboard with lots of numbers that motivates no one and tells a too complex story.

Watch out for what Eric Ries dubbed “vanity metrics” – numbers that present a rosy picuture of the business but don’t actually reflect its key drivers of growth.

Eric Ries says the opposite of vanity metrics are actionable metrics. It’s not about unimportant metrics, but vague and unactionable, unaccountable metrics that you can’t learn from.

Example of vanity metrics:

• Total revenue
• Number of active users
• Number of signups (in total or e.g. after at Marketing campaign)

Example of actionable metrics:

• Per customer engagement
• Customer acquisition cost
• Lifetime value of customer
• Retention rate
• Virality coefficient: how many customer comes from the action of an existing customer

Actionable metrics encourage you to find out what you can do to improve the product, while vanity metrics encourage you to improve next month over previous month.

Almost all quality Village-size businesses will use a dashboard to assess the daily health of their companies.

Yes! When is the last time you were in a discussion where someone came with an argument that basically says “must be better at X”, or “can never be good enough at Y”, or implies that “more Z is always better”. It’s meaningless.

One example: Pinterest reduced percieved load time with 40% and got a 15 percent increase in conversion rate to signup. Performance is no doubt important: I’d vager that performance issues are the most common low hanging fruits at most companies.

However, it makes little to no sense to argue for “better performance”. During GOTO 2018, Christof Leng talked about Site Reliability Engineering at Google where he argues for “Error budgets and SLO”. Basically, you can have 900ms responsetime, 10% Click-through rate or 100 hours of critical bugs live per month. These could be acceptable for the given service. You then work on systems that do not work in an acceptable manner.

To know this, YOU NEED METRICS AND DASHBOARDS!

Without it, without any sense of where we’re at, where we’ve been, where we want to be or where we’re going, it makes little sense to argue for “less bugs”, “faster website” or “higher convertion”.

6. Single focus to multithreading

We don’t know of a single startup that succeeded without starting out as single-threaded. That focus is the key to beating larger competitors in the early stages of a company’s existence.

Don’t do multiple products at once as a new company. Find 1 thing that might work. If it doesn’t try other things, but do them one at a time.

Once you’ve found one thing that definitely works, you can consider other products in parallell after having reached a certain size.

“Finding out what not to do is as important as deciding what to do”, [Steve jobs] told his biographer.

This can be applied down to employee or feature level. It’s always easier to see the value of the next feature, than it is to see the value of not having a new feature. Likewise, it’s easier to see the value in new employee than the (non-financial) cost of having another employee.

..This is why it’s generally better to have your ten best people working on a single important project rather than splitting them to attack different opportunities.

7. Pirate to Navy

Startups are pirates: they lack formal process and question or even break rules. […] Pirates act quickly and decisvely and are willing to take risks because they know that the default outcome is death.

You play offensively at the beginning, and more defensively at the end. At the start, you don’t care about customer retention, because you have none. You don’t take precautions to keep your advantage, because you don’t have an advantage. There’s fewer rules toyou should follow, you’re just pushing your way to get in there, and you have little to loose. You’re the offensive challenger, the Pirate, instead of the defensive (but also offensive) leader, the Navy.

In other words, you will need to start caring about what you can loose when you’re a village or city sized business. This includes customers, reputation and product advantage. You’ll need to do things right, including following regulations more thoroughly (e.g. GDPR, )

8. Founders to leaders

As the company grows, you’ll be streching thin if you keep doing the same level of things. You’ll need to narrow your efforts where they count the most and scale yourself.

There are only three ways to scale yourself: delegation, amplification, and just making yourself better.

As you grow, you’ve got to delegate to others. You haven’t got the bandwidth to go into the details, instead you must trust your employees. Personally, I’ve been lucky to avoid bosses looking over my shoulder, but I’ve still got a way to go in let others do things suboptimally.

You can also amplify yourself by hiring assistants or teams to make time you spend more efficient (by finding relevant material, or prepping you and others for meetings). I’ve never felt that need for or worked with people who are or have assistants or supporting teams, so… ok, yeah, thumbs up.

I like some of his thoughts on making yourself better, and I think they apply to everyone at any job:

There’s no job description for founders. If the role doesn’t change, there’s something wrong. […] You’ve got to keep your personal learning curve ahead of the company’s growth curve.

Reid said you’ve got to make yourself into a learning machine (one of the few places in the book where he uses bold). How he suggests to do this is to talking to other founders, learning from their mistakes and reading good books.

These are great tips no matter what you do. I might be narrow-minded about this, but I can’t understand how anyone can feel fulfilled at anything without constantly learning new things.

Everyone needs feedback. Brian Chesky, for example, likes to say, “I’m shameless about getting feedback.”

Feedback is golden. It’s one of the main motivational triggers in games (I wrote on motivational triggers in computer systems for my pre-master thesis). It should come often, and for efficient learning: as soon as possible after the activity that was performed.

I spoke to two students writing master thesis recently about feedback. On about instant computer generated feedback in programming. One about the improving the latency of feedback in school. Feedback in school is often delayed by a week or two – the result is often that the student has moved or or lost interest in the subject by the time they get the feedback, and how the feedback then looses most of its value.

Feedback can also be a source of disagreement and frustration. It should be neutral and justified, but that’s often difficult to evaluate. One way of combating it is getting lots of feedback. The average of 10 opinions is often more correct than what you’ll get from one or two.

Get and give much feedback, get it often, and don’t take one persons feedback too seriously or assume others should take yours too seriously.

You might feel like you can’t afford to take time out from your busy schedule to make yourself better. […] I was too busy chopping wood to sharpen the axe.

I’m a fan of sharpening metaforical axes, so this quote rubs me the right way. Automatic formatting and tests, ESLint feedbacks, IDE shortcuts, status dashboards, searchable logs and bug tracking systems.

These tools lower the chance something goes wrong, gives you a heads up before it does, and when it does goes wrong (it always will), it helps you immensely in figuring out why and where so you can fix it. It allows you to understand things quickly, and that’s when you can make progress quickly.

Nine counterintuitive rules of blitzscaling

1. Embrace chaos

In the start, and as you change, there’ll be missing systems and routines and many things will fall between cracks. All of a sudden you’ll need a new set of skills, but only for a month when things suddenly shift back. You want adaptable people being capable of learning and doing anyting.

• You need potato people.

2. Hire ms. right now, not ms. right

No one is a correct hire. But many can be the correct hire for what we need now.

Seasoned Silicon Valley professionals tend to be aware of their preferred stage and role.

Interesting question: What’s your preferred stage and role?

For me, I think I could be a developer at the family stage. I’m not sure if it’s enough for me at the Tribe stage, because I am shit poor at taking directions that I disagree with. And that’s the same reason I don’t think I could be anything at the Village stage. When 100+ people work together, no one (should) decide (?), and everyone takes directions from somewhere.

3. Tolerate “bad” management

Chaotic, unstable organizations make employees nervous and hurt morale. […] When your company is growing 300 percent per year, you might have to promote people before they’re ready and then swap them out if they sink rather than swim.

Reid has more examples of lack of good management that is sacrificed on the fire of speed: decisions that are made quickly without involving everyone. Business cards or job titles or other (somewhat low-priority things) that are ignored. And it might make additional sense to avoid finding good procedures for things or that might anyway change in 6 months when you’re twice the size.

4. Launch a product that embarrasses you

Any product that you’ve carefully refined based on your instincts rather than real user reactions and data is likely to miss the mark and will require significant iteration anyway.

Love it! Don’t perfect any product before you’ve tested it properly. Perfection often leads you down a road where you’re less willing to change things.

Assuming one is willing to iterate on a product (rather than immediately making new products or features) I wholly believe that a product that just works, is the one with the best chance of success.

I also believe staying lean and iterating on product is one of the areas where CXOs execute least well. Is this not taught in economics classes?!

5. Let fires burn

The right thing is often not doing what should be done, but what must be done. There can be too many fires going on to put out all of them, so focus your efforts on those that might kill you first, and worry about the others later.

For instance, shitty support might not bring you down, though it hurts you. You should fix that by bringing up documentation, FAQs, chat bot, increase support staff or by other means. But you might have to just let those emails go unanswered.

The art of course, is knowing which fires to let burn. [… 1. Urgency)] Which fire is going to kill your business the soonest? [… 2. Efficacy)] Which fires do you have the ability to extinguish right now, and which will be easier later (and visa versa)? [… 3. Dependency)] Which other fires will make it easier to extinguish this one, if they are done first?

This is lean thinking of extinguishing fires. Which are most important to do, which should be done first and what will it enable us to after having done this one. Thumbs up!

6. Do things that don’t scale (throwaway work)

Founder Brian Chesky [of AirBnB] describes this strategy succinctly: “Do everything by hand until it’s too painful, then automate it.”

I like AirBnB a lot after reading this book. This quote is great, as it includes thoughts on both experimentation, learning, lean and scalability.

“Do everything by hand…”:

Quite often, we can have an idea about what we need or the customer wants that is not right. Doing things by hand lets me internalize the need for it, learn the circumstances where it’s performed, and consider alternative ways of solving it.

“…until it’s too painful…”:

By waiting until it’s painful, you’ve confirmed that it’s needed and important. If it wasn’t necessary, you would’ve found a way to not do it before it became painful. At this point, you know the problem so well that the solution you have in mind is likely much better than initially. In addition, you have strong personal motivation to fix it; motivation is key to efficiency and job satisfaction – you’ve tricked your brain to be excited.

“…then automate it”:

You didn’t build it before you really needed it, and you’re building it after having learned everything about it. The solution is better, and you only fix what you need to fix – you’re staying lean!

7. Ignore your customers

The key rule is: Provide whatever customer service you can, as long as it doesn’t slow you down… which may mean no service!

I imagine the reasoning behind these statements are:

1. Customer support can take a -lot- of resources for a small team. Remember Instagram selling their company with 100 million users to Facebook when they were 12 employees themselves? Could you imagine them answering support emails?

2. A good product with poor support is going to win over a poor product with good support.

3. News of poor customer support is not going to matter as much when you’re growing quickly, or is small (having few previous/existing customers).

As an argument against this: I think support is an extremely valuable source of customer feedback that should be used to shape the product. Maybe especially in the early days should one keep an eye on it, so I’d like to read this counterintuitive rule as Provide shitty (or even no) support rather than ignoring customers completely.

8. Raise too much money

Act like you’ve got half the amount you have in the bank […] Investors always prefer to give money to someone that doesn’t need it.

At my previous job, my CEO told me how they almost run out of cash the first year, and had to sell of parts of the company dirt cheap. Those who buy/invest in companies are often good at getting deals, so when you’re on your knees: they’ll rob you.

9. Evolve your Culture

Ignoring your culture is not an option […], culture is actually a substitute for bureaucracy and rules. The stronger you make your culture, the less you’ll have to bind people’s behaviour with rigid directives.

I haven’t thought about culture that way before, but yeah, sounds sound to me! Give smart people a set of (company) values, and they’ll usually make the correct choice from there.

TLDR

What do the eight key transitions and nine counterintuitive rules have in common? They reflect the fact that when you’re blitzscaling, the need for change never stops.

So don’t invest too much in where you’re at now. Because you won’t be there for long. Invest in things that’ll be important in the future too.

Stay lean, in addressing the crucial issues before the important ones (which you may not have time for at all) and with building product (single threaded). on’t expect much if anything to be perfect, and expect to have to postpone important things (as long as they won’t kill you).

Worry about your culture. Communication forms and how decisions are made will change more than once: employees will go through poor management, cultural changes, less influence and feeling less heard. Handling this in a good way is all about maximizing good input, making everyone feel heard, a part of the team while still staying efficient. Good luck!

Begin trusting data over gut feeling. Anecdotal stories, (quality) gut feelings and instinct build startups in the Family and Tribe stage, but you got to get and trust data more as you grow into the Village stage.

Be careful when hiring managers and executives from the outside. Existing employees may feel like they’re loosing ownership (rightly so). Promote from within or hire to a lower position first.

Hire generalists at first, then specialists. Make sure your early generalists are still happy with a situation where newcomers get to do the exciting work, maybe with new initiatives?

Don’t get strapped for cash: others will squeeze you dry if you are.

Learn all the time, by experimenting, measuring, doing new things, talking to knowledgable people and getting a dashboard.

Do things that don’t scale, because you’ll learn so much: you’ll identify what’s crucial and not => allow you to stay lean and you’ll build a culture of learning. What you think you’ll need is usually not what you need.