Agents of Purpose

I’ve set out below some of the main points we discussed on the above.

1. What exactly is operations in a scale-up?

As every business is different, so is the nature of what is considered “operations” and therefore what the Head of Operations, VP Operations or COO is responsible for. It’s also dependent upon the maturity of the business, as the earlier the business is in it’s evolution, the more likely the COO is going to end up doing anything and everything. It also depends on the preferences of the CEO – often a COO ends up being complementary to the CEO, doing the things that the CEO doesn’t.

Here are a few definitions from the group, how they describe operations in their company:

Maybe it’s simply about making stuff happen. In 2007 I had just joined Bookatable. We were 2 months away from cash out and were in the midst of a fundraising round. After my first day at work our CEO (Niklas), Chief Sales Officer (Chris) and I went to meet Tim Bunting of Balderton Capital and his colleagues Sean Seaton Rogers (now ProFounders) and Johan Brenner (now Creandum). On the way over to the meeting (at Tim’s flat over pizza and beer) I asked Niklas our CEO how we would describe what we each do. Niklas said laughing,

“It’s very simple David, I dream up this stuff, Chris sells it and you make it happen”.

That’s was a good starting point for me and ended being quite accurate over the coming years.

One other point that was raised was the role of operations in “scaling”. Scaling as a word I explained is often used in different ways in the startup community. It can often just mean to get bigger. I prefer to think about “scaling” as in “economies of scale”. A startup that is ready to scale has scalable economics.

You reach scalable economics when your cost per transaction comes down as the number of transactions goes up and there is a clear path to profitability.

Here’s what good scaling looks like:

So yes, operations does concern itself with scaling.

Another angle. I’ve often thought how similar operations is to product management. Consider the following definition of product management…

“To assess, define, launch and retire products”

Product managers analyse the market opportunity, the customer needs, the environment and available technology to create a solution for their customer. If you switch out the word “product” and instead say “processes”, “initiatives”, “projects” or “communication structures” (and so on), you can see an analogy where a COO is a product manager and their product is the organisation.

In the end, is there a core essence of what operations is really all about?

I suggested that perhaps the core essence is this… it’s about developing the capability of the organisation, capability being defined as follows,

Capability = (Competence x Capacity)

As COO, you are always thinking “how do we do things better” (competence) and that manifests itself if how the company hires, communicates, captures and reports information, makes decisions and creates it’s own blueprints for success.

You’re also thinking about how to stimulate, keep up with and preempt growth (having enough capacity).

To be truly capable you need both competence and capacity. And maybe therein lies the core essence of operations.

2. The changing nature of team dynamics

People often ask me what’s it like to have 4 kids. The answer is, it’s fantastic. Another point I make though is that a 6 person family is exponentially more complex than a 4 person family. Here’s why.

When you first meet your partner, there is one relationship. Two people with one relationship.

If you then have a child, there are now three relationships. Mother < > Father, Mother < > Child, Father < > Child.

In a family of four, there are 6 relationships….

In a family of 6 however the number of relationships rockets. To 15!

Our family mealtimes can have up to 15 different possible interactions going on. Everyone has to work harder to be heard and needs to be able to listen and wait their turn to talk.

It’s like this in startups. The more people you add, the more relationships are added and most people don’t realise that the complexity is non-linear.

So what happens when you get to 50 people?

As it happens there’s a formula to work out the number of potential relationships. Where r is the number of potential 1:1 relationships and n is group size the formula is this:

r = (n x (n-1)) / 2

50 people gives the following result; (50 x 49) / 2 = 1225

1225 potential relationships!

If you take this out to 150 people the chart looks like this….

Wow!

How do we humans deal with this?

Humans typically deal with the increasing complexity by creating more formal communication and relationship structures, the most common one being a hierarchy.

It’s my opinion that in scale-ups that team dynamics change in a predictable way. I use the analogy of human settlement sizes to illustrate what I mean. I’ll list them below. This is the “default” progression that most teams will see unless they do something to the contrary. There are predictable inflection points where the team dynamics change.

(Side note: if you are interested in exploring alternative methods of organisation I highly recommend reading Frederic Laloux’s “Reinventing Organizations”. In it he explores what he believes to be the next wave of human social maturity, what he calls “Teal” organisations. These organisations are typically less hierarchical and very effective).

As a scale-up COO I’ve seen these inflection points myself.

At Bookatable we grew from 25 people to 170 people in 3 years. At HouseTrip we grew from 8 people to 160 people in less than 2 years. I’ve worked in teams from less than 10 to working in big companies of over 2,000 people.

On each growth journey there were inflection points caused by the number of people in the company.

I’ve found that there are 3 company size inflection points that startups need to be aware of.

Whenever the organisation size goes past one of these numbers the dynamics change. What worked before doesn’t work now. Different skills are needed, different processes and different leadership styles.

You might find that you thrive in one group size but struggle in another. This is TOTALLY NORMAL, and most people don’t realise that the group size itself has a massive effect on what’s needed to survive and thrive as a contributor or leader.

People that join a startup when it’s at 15 people sometimes find they don’t like the way things are changing when they get to 150 people. They miss out on information, they are not included in as many decisions, there are process hoops to jump through and they just don’t like it. This is NORMAL.

What many people don’t realise is that you can predict how human groups will behave in different ways depending on how large they are.

And because fast growing startups (or “scale-ups”) can grow every month, the dynamic changes without anyone realising. Unless, of course, you know these inflection points exist – and that they matter.

The 3 inflection points; 7, 50, 150

Any time the group size increases (or decreases) around these thresholds – everything changes – and nobody realises!

Many companies start with a single founder. There is no group here so there is no group dynamic, just one person trying to do everything and wishing there were more hours in the day.

Then – there is a team…

2-7 people – “The Hunting Party”

In this small group size, it’s as if there is a hunt.

Imagine our ancestors out for the day tracking deer on foot. The group work together in real time with some (but only where needed) planning. A leader often emerges but really only if someone needs to be in charge and people follow a leader because they are happy for that person to be the leader.

Everyone has their own skills and contribution. Everyone is involved and everyone knows almost everything. The team have an objective to catch their prey and they work together on this common purpose using the skills and tools that they have at their disposal.

8-50 people – “Family Huts”

When the hunting party bring back their prey, it’s to a small settlement with a few huts, one for each family. Each family has a recognised leader that’s needed if required but most people still talk directly to each other and everyone knows everyone else on first name terms. The elders might tell stories around the fireplace in the evening and not much organisation is required.

This is what the early stage of a startup is like once you get past 7 people. There are distinctive groups who take on specific responsibilities and challenges – the tech team, the sales team, the marketing team etc. You need leaders for each group but very little process is needed and stuff gets done, albeit chaotically.

50-150 people – “The Village”

Once you get past 50 people, everything changes.

You now have to work at it so that people bond. You need to start developing processes to get stuff done. You try and channel communications. You have to broadcast more information. You start having to channel requests and instructions via group leaders. You have a more formal decision making leadership team.

You have a light hierarchy.

This is like a small village. In a small village there are specialist roles. The school teacher, the bar owner, the mechanic and so on. There are people in charge and there are more rules. You can still know everyone, what their role and how they relate to each other but you won’t know everyone on first name terms.

150+ people – “The Town”

After 150, the village becomes a town.

Here, it becomes almost impossible to know everyone by name and to know what everyone does. Throughout history, humans have defaulted to a hierarchy system to organise themselves in larger groups. There are probably many exceptions, but it is very common to use a hierarchy as an effective organisational method.

In the town there are systems. Systems to make sure that repeated and expected events are handled with predictability. There are traffic lights, drainage systems, planning restrictions and street numbers. There are people in charge and there are people that work within more specialist roles.

The idea that 150 is a threshold that matters was was first suggested by British anthropologist Robin Dunbar (b. 1947) and subsequently popularised by Malcolm Gladwell in his book “The Tipping Point”. Known as “Dunbar’s number”, the number 150 is a theoretical maximum number of individuals with whom a group can maintain a social relationship where each knows who each other is and how they all connect socially.

So – in a group of 150, it is still possible to know everyone else, understand their roles and their relationships with each other. Beyond that, forget it. This number, like 7 and 50 is pretty significant therefore when it comes to shaping organisational structures. With a team of 150 you can still manage with a relatively flat reporting structure, fairly informal communication processes and decision making.

Every startup that scales faces these challenges.

In summary… what to expect and plan for:

Think about your own preferences and where you thrive.

Some CEOs that launch startups can really struggle in a big organisation. Some big company CEOs would struggle to launch a startup from scratch. We all have our sweet spot.

I’ve learned over the years that I am best suited to Family Huts and Village Life. I can hunt if I need to and I prefer not to be a townie. I’m more of a village dweller. That’s where my skills are best used. It suits my management style, partly because I like to do – and a village is full of do-ers.

Whatever, your preference, pay attention to group size and what it does to your culture – you underestimate it at your peril.

3. Getting away from hierarchies

What about alternatives? Hierarchies can be slow. What if you don’t want to be part of a hierarchy?

If you want to reduce complexity and increase speed and quality, this can often be achieved by creating small autonomous groups who have a clear purpose and the freedom to pursue this purpose. Mini hunting parties if you like.

These types of groups are highly motivated. If you’ve ever read Daniel Pink’s “Drive”, you’ll know that great motivation comes from autonomy, mastery and purpose. Great motivation can lead to great results.

There are a few examples from the tech world which show us the benefits of small groups and autonomy.

4. What are you optimising for and why?

At the heart of organisational design there is this question. It’s often a question that goes unasked. Many people joining a startup from more mature organisations are inclined to optimise for efficiency. Once you have a business model that works, optimising for efficiency can make sense. It can be overdone too – think of all those hours you’ve wasted waiting in phone queuing systems. They might be efficient for the large company but they are not giving a great experience to the consumer.

In a scale-up there are different ways to optimise.

You could optimise for:

Which one to choose? At HouseTrip I had a triple challenge.

First of all, our operations team had to keep up with growth. We were growing at more than 10% per month. That meant, unless we changed the way we worked, we needed 10% more people, every month. In fact, we grew from 2 people to 90 people in our Lisbon customer service team in 12 months.

The second challenge was to improve quality of service. We started measuring our customer satisfaction with the service received and then systematically found ways to improve it.

Finally, we had to gradually reduce the cost of servicing a booking. That meant removing unnecessary enquiries by improving the core product as well as providing better self-help tools. It also meant helping the team to be more efficient with better tools including a library of pre-written responses.

One thing I learnt fast was that above all else we should optimise for quality.

The way to do that was to use both qualitative and quantitative data and most importantly – organise the team around the customer. At one point we made the mistake of creating too many specialist teams, each focusing on one particular task such as complaints, payment queries or host relations. Thus creating expertise, but it had an unfortunate side-effect – it slowed things down because several people were involved in solving a case.

In contrast, what we found was that the single most important driver of customer satisfaction was speed of response. So – to solve that we needed team members who could deal with as much of the issue on their own, including having authority to make refund decisions (up to a point) thereby increasing the speed of the response and the quality of the customer experience.

We optimised for quality by organising ourselves around the customer experience.

5. The concept of organisational debt

Many startups are familiar with the term “technical debt”. Technical debt refers to situations when suboptimal code is produced to get a feature or product out the door quickly. There’s often a good reason to do this (such as winning a new client or testing a new concept cheaply) but it does mean that at some point someone is going to need to refactor the code and build the system properly and until they do so the code base is more difficult to maintain.

The interest that you pay on this debt is the increasing complexity of the code base (thereby making new developments more difficult to write, test or ship), more bugs to fix and the knock on the effect on morale of the dev team.

This concept of technical debt helps us to understand another type of debt, organisational debt.

All startups have organisational debt.

In the early days of a startup, it’s just not possible to create an entire company and system in one go. These things take time and sometimes you need to hack solutions. For example, until you’ve built your back office system, you might have people doing manual work to make it all happen behind the scenes. Another example is if you outsource a function to a third party until you’re big enough to do it in house.

This is organisational debt. It’s a temporary solution that you’ll put right in the future and until you do you’ll pay the cost of doing it sub-optimally. The price of organisational debt could mean having a higher salary overhead than needed to complete a task, it could mean high complexity or it could mean delays in gathering information.

Organisational debt makes sense if you are still developing and testing the business model. Startups are organisations in search of a viable and repeatable business model. Investing in processes and systems only makes sense once there are customers to serve and revenues being generated.

There’s the right time to take out debt and there’s a right time to pay it back.

Scaling a business with a lot of organisational debt is risky. An organisation that works at 100 transactions a day could self-destruct at 1000 transactions a day if there are lots of manual processes. In the same way that taking on more financial debt than you can handle can put you at risk of bankruptcy, organisational debt can cripple an organisation trying to scale.

In what order should you pay back the debt?

The way I think about this is in three levels of priority in terms of reducing the debt:

1. First, consider which processes and systems are closest to the customer and optimise those first. Above all else, the business needs customers and it needs a great customer experience. If it affects the customer experience, fix that first.
2. Secondly, I would focus on fixing the unit economics of the business. This allows the business to start generating a better contribution from each transaction gives a good base from which to scale.
3. Finally, I would optimise back-office and overheads. Examples might be customer service systems, finance systems, procurement.
   If the business is scaling and addressing point 3 before point 1 or 2, it would cause me concern. If 1 and 2 are getting good attention, it builds a good base from which to optimise point 3.

Of course this model is a huge generalisation but it’s the best way I’ve found to express why it’s OK to maintain some organisational debt as you grow.

It’s OK to have the right kind of debt.

As a COO I often had colleagues proposing ideas or projects that improved the efficiencies of the business. If these were in category 3 and we hadn’t yet fixed 1 or 2, I would say that it was better to hold off on these projects and suffer the ongoing organisational headaches until we’d built a business worth optimising.

There’s often a bumpy ride that a startup takes after raising Series A funding and much of it can be understood by the fact that some parts of the business mature first whilst the rest hasn’t yet caught up. It can feel very difficult for the people involved and the challenge for the management team is to help people understand that it’s a conscious decision to hold off on improving some parts of the business because it’s the right thing to do to be in debt on that area at that time.

I think it’s about recognising and sharing with the team that yes, we can and should do better (in the area which is chaotic), we will fix it but now is not the right time. It’s not an easy thing to communicate and requires sharing with the team the big picture about what areas are improving and why they are the important pieces of the jigsaw to solve first.

As always, it’s about priorities and it’s about not taking on more debt than you can handle.

6. Creating quality ratchets; building in process, but only just enough

A process is a basic building block of the operation manager’s toolkit.

Processes are like ratchets that secure quality. As the scale-up spins forward to growth, processes ensure that high quality activity is repeatable.

Processes are built upon principles.

The more clearly you state your principles and the more they are understood by the team, the less need you will have for overly detailed instructions in your processes and the more autonomous the team will be.

Examples of principles:

Processes build on principles into a set of repeatable instructions or methods that explain how individuals, teams and systems act out the principles. A process will describe step by step what is required in a particular scenario. It usually also explains who is responsible at each stage.

Examples of processes:

To describe a process without explaining the principles that underpin it risks that people following the instructions don’t appreciate the context in which they are working. Blindly following instructions means that should the instructions be missing a small point of detail or should the circumstances be so unusual that the instructions are incomplete, the team member would not know how to act. However, if they can also understand the principles upon which the instructions are based, then they are more able to act in the interests of the company and of the customer.

So, consider process creation as a way to create quality ratchets.

I find they are best created by the people who already do the work, not the people managing the work, or – if needed in collaboration between the two.

Ideally every process should also be measured with KPIs so people know how well the process is working and most importantly, it should be reviewed regularly and changed. If it never changes it will never improve, so always revisit and improve processes where you can.

However, you can have too much process. You can over-engineer and optimise which can strangle growth and agility. Equally you can have too little. You might have processes that worked well for you last year but this year, because you’ve grown, they no longer work. The balance I’d advise is to have process “but only just enough”.

To sum up

So there you are, operations in a scale-up has many dimensions. As every scale-up is different, every COO needs to chart their own path. My experience has led me to the beliefs and advice I give above, but this theory is nothing compared to the practice that it derived from. Every scale-up needs to figure it out for themselves from first principles.

There is no playbook.