Less noise, more data. Get the biggest data report on software developer careers in South Africa.

Dev Report mobile

Mental Models for Surviving High-growth Startups

9 February 2022 , by Philip Joubert

This article has been reposted from Philip's personal blog with permission.

“Do you know the best thing about startups? You only ever experience two emotions: euphoria and terror. And I find that lack of sleep enhances them both.” - Marc Andreessen

If building a startup was easy, everyone would be doing it. At the same time, it doesn’t have to feel like you’re “eating glass and staring into the abyss” all the time. In this post I'll be sharing the mental models I use every day to stay motivated.

Philip Joubert: Models for surviving high-growth startups

Here's an overview of each model:

  1. Adlerian triangle: Look towards the future and focus on what to do next.
  2. Root cause focus: Focus your effort on solving the root problem and let the rest go.
  3. Separation of tasks: Work on your own tasks and let others do the same.
  4. Fireline: You have to let some fires burn so that you can focus on what’s most important.
  5. Failure bands: Identify an acceptable band of mistakes that can be made and then let people, including yourself, make some of them.
  6. Future focus: Concentrate on the rate of improvement rather than the current state.
  7. Crude but good: Imagine that after implementing the system you went on holiday for 3 months.

Adlerian triangle

In Courage to be Happy the philosopher explains one of my favourite models:

Adlerian triangle

If something bad happens to us we typically respond in one of the following ways:

  1. That bad person: We blame someone else for causing the situation
  2. Poor me: We have self-pity and view ourselves as a victim
  3. What should I do from now on?: We look towards the future and the actions we can take.

Imagine that you've worked super hard to get ready for a leadership position that would be opening up. Despite all that work, your manager decides to promote someone else instead. You could respond by feeling sorry for yourself or getting angry at your manager for being an asshole. The outcome sucks - no doubt about it - but neither of those responses will get you what you want. Looking towards the future, a better approach might be to talk to the hiring manager and understand where you need to improve so you can get the next role.

It may give us a sense of righteousness to blame others or feel sorry for ourselves, but those responses do not move us closer to our goal. The only way to make progress is to accept responsibility for what happens next.

Root cause focus

Often an endless stream of different problems has a single root cause. Focus your effort on solving this root problem and let the rest go.

In a strange way, dealing with big problems can actually be quite motivating! What gets me is death by a thousand cuts. There are few things more depressing than an endless stream of small problems with no end in sight.

Root cause

Fortunately, there is usually a root problem that either causes or exacerbates all the other problems. For instance, in the diagram above the root cause of the team's problems is that they lack clarity of what their goal is.

Root cause focus is about finding the core problem and solving that. Addressing the problem can sometimes take a while - but I’ve found that just knowing what it is and how we’ll solve it gives me a powerful perspective. Each new problem that surfaces gets filtered through my new lens: will solving the root cause also solve the problem? If yes, then I just ignore it.

Separation of tasks

Work on your own tasks and let others do the same.

Courage to be Disliked introduced me to a powerful model called the separation of tasks. The basic idea is that interpersonal relationship issues often stem from interfering with other people’s tasks, or having your own tasks interfered with.

The trick is to clearly delineate which tasks are yours and which are not. A quick way of figuring out who a task belongs to is to ask: Who ultimately is going to receive the end result brought about by the choice that is made?

Here’s how the separation of tasks works in practice: Let’s say you're the CTO and you spot an inefficient process in the marketing team. If you intervene in the tasks of the Head of Marketing or take on their tasks you’ll add a huge amount of additional stress to both yourself and her. Running that team is not your task. Of course, it’s important that you point out the process issues to the Head of Marketing, but then it’s up to her to decide what to do next.

Keep in mind that if someone consistently fails at their tasks then you’ll want to replace them with someone who can.

Fireline

There will always be far more problems than you’ll have time to solve. You have to let some fires burn so that you can focus on what’s most important.

Fighting every fire can cause you to miss critical opportunities to build your business - you’ll be all reaction and no action. That’s why you have to learn to let some fires burn, sometimes even very large fires.

Reid Hoffman explains in Masters of Scale:

“The trick is knowing which fires can’t be ignored—the ones that might spread quickly and engulf your business—and which fires you can afford to let burn, even as the flames climb higher.”

I categorise issues into a simple framework. If it’s above the fire line then it’s a priority. If it’s below the fireline I just let it burn.

Fireline

There are two aspects of this that help me:

  1. The first is simply to acknowledge that there is a problem and classify it as above or below the fireline. Just from that I usually feel a lot better!
  2. The second is that my priorities become explicit and I can battle-test them against other people in the team.

Failure bands

Identify an acceptable band of mistakes that can be made and then let people, including yourself, make some of them.

I’ve made a bunch of dumb mistakes in my career and I’m sure you have too. It’s a part of learning how to become competent individuals. For some reason, we tend to not like mistakes when others make them. In fact, it can be quite painful watching a member of your team mess something up.

As a result, the default for many leaders is to be controlling. Despite this (or perhaps because of this), things still go wrong. Then these leaders spend their time agonising over the problems and putting out fires. It sucks for everyone!

Failure bands are about accepting that some mistakes will happen. Instead of controlling your team, you identify an acceptable band of mistakes that can be made and then let people, including yourself, make some of them. By removing the burden of perfection you not only free yourself up to have less stress, but you also enable your team to learn faster.

I've found Failure Bands to be particularly useful when leading first-time managers. Nothing really prepares someone for their first management role - and they are bound to make a lot of mistakes. Instead of getting upset when they do, I give them space and let them sort it out.

Future focus

Concentrate on the rate at which things are improving rather than their current state.

Future focus

Maybe you just got blistering feedback from a customer or perhaps you overheard a terrible call that a sales rep just had. My frustration in these situations is usually not related to the current moment. Rather, it stems from the implicit assumption that the problems will continue indefinitely. Without realising it I project a pessimistic view into the future. Am I really going to have to put up with this shit for the rest of my time at this company?

I’ve learned that people can take a lot more suffering if they know there’s an end to it. Future focus is about leveraging this and actively crafting a narrative about the future. I spend time thinking through how we’re improving that part of the business and the progress we can expect. As long as the future is getting better, even if it’s pretty slow, my resilience goes way up.

Crude but good

When building systems, prioritise reliability over effectiveness. Imagine that after implementing the system you went on holiday for 3 months.

Let's say you have created the “best” way to run your weekly leadership meeting. It takes you 4 hours of prep each week but it results in an awesomely productive session. In isolation this is fine, but it turns out that most of us have like a billion things on our plate. So the “best” system goes off the rails after a few (stressful) months because you simply cannot dedicate enough effort to it. Instead of running a world-class leadership meeting, you end up running a mediocre meeting because you're now completely winging it. Despite knowing this happens, I still find myself wanting to implement the “best” solutions. I just can’t help myself!

That’s where crude but good comes in: when designing a system you imagine that after implementing the system you'll go on holiday for 3 months. The result is that instead of focusing purely on theoretical impact, you design something that isn’t dependent on your constant input keeping it going. The result is usually a bit cruder but a lot more robust!

Recent posts

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.