Why Your Company Is Getting Less Efficient As It Grows, And What To Do About It

This post is a transcription of a Management 101 Podcast episode titled Why Your Company Is Getting Less Efficient As It Grows, And What To Do About It

Intro to Episode

Startups naturally hire more people as they grow because there's more work to do. But as they hire more people, they become less efficient. When leaders see less output, they try to hire even more people to solve the problem. But what if the problem isn't with the number of people? What if it's actually with how they work? In today's episode I talk about why companies get less efficient over time, and what you as a leader can do to stop that (without hiring more people).

Episode Transcript (edited for clarity)

Today we're going to be talking about something less related to people management and more related to org management. I think of people management as, how do we enable one person to be successful? And I think of org management as, how do I enable a whole team or company to be successful? Hopefully, over the course of this episode, you will see that there is a big difference in terms of the practices that you as a manager or a leader would take to accomplish those things.

Today we're going to be talking about one specific problem that I think exists in pretty much every growing startup. It might even exist in every startup. And it's something that you, if you are leading a company through its growth phase, are going to experience. And that is the problem of, as you add more employees, you will see your company's output or efficiency go way down. The individual person's productivity will be reduced as you add more people. This is a very natural thing to occur. But today we're going to talk through why that happens and, of course, what to do about it as a leader.

First, some context. In the early stages of a startup, employees tend to be very effective, operating totally independently from other teams. And that's for a couple reasons. First, employees tend to be just the single person in their department. And then the second reason is they're creating that department totally from scratch. For example, I was recently working with a startup that was maybe eight people. There were two departments with more than one person, and the rest of the departments had exactly one person. In operations, for example, we had one person in this team, and this person was responsible for all of the customer experience, client onboarding and client management. And they were creating everything from scratch. When they were doing their work, they didn't need to check with others in their department because there was literally no one else in the department. And they were doing very basic things like coming up with the process for how to onboard clients. There wasn't something that they needed to keep in mind because this had never been done before. They were literally coming up with this from scratch. The work was very basic and there wasn't very much coordination that was required with others.

Same when I was working with another client who did this in enterprise sales. This person could do everything themselves. They could design their sales funnel, they could manage it completely on their own. They didn't need to coordinate with other sales people, and they also didn't need to coordinate with other departments.

For example, there was no finance department, so they didn't really need to talk with a finance department about what the right structure for these deals was. All they had to do was talk to their manager who was the CEO.

That's all well and good for an early stage startup. But once a startup has any amount of success, of course they're going to hire more people. And when that occurs, another thing is also happening. Not only will there be more people in the company, but all of those individual departments of one person, they're no longer focused on the basic building blocks. They've already got a sales process. They've already got a client onboarding process. Now the work is getting more complex. You have to iterate on those existing processes. That's harder to do than just building them from scratch. You have to figure out how those processes might work between operations and product. Maybe previously operations was handling a process entirely on their own, but the next iteration of that process maybe needs to involve Product.

As the complexity of that work increases and there are more people doing that work, there is this pivot point where the optimal way of doing that work is no longer for individuals to work entirely on their own, and it becomes more optimal to work as a team. This pivot point where companies need to start operating as teams rather than a group of individuals doing work on their own, that point is where I see a lot of my clients, and generally fast growing startups, literally every single one I've ever worked for, get really tripped up.

There are a few reasons for this. First, it makes sense that, as the leader of your department of one, you're used to operating on your own. You've got your own little fiefdom or world, and your time is normally just spent doing work. You don't need to do a whole lot of planning or coordinating because there's no one to coordinate with. There isn't really such a thing as planning, because I just need to build a sales process and I need to move as quickly as I can. There's not much planning and there's not much coordination.

But now that the company has grown and it's gotten more complex, what leaders will start to notice is that their projects that seem like they're going really well will suddenly start getting stalled right at the finish line. That's happening because other teams are starting to bring up concerns about how my work is impacting theirs. We're no longer just operating totally independently. All of the work that we do now has interdependencies between teams. Before, every team was focused on just doing their own work. Now you've got these interdependencies and other teams are suddenly going to be concerned that if you do this thing, if you roll out this work, then it's going to make my job harder. The lack of coordination means that some of those projects are suddenly not going to move forward even after the work for them is done.

Then the other thing that's going on: before, every team was focused on a different problem, and so they never ran into each other. But now leaders, particularly CEOs, might notice, they actually see a bunch of different teams working on the same problem, because there are really only a few problems that need to be solved for a business to be successful. As you get the main building blocks of each department and each function done, then you have to really focus on more business problems. And there are only so many business problems to go around. So you have a bunch of teams working on the same problem now. And more likely than not, they haven't coordinated any of those efforts between each other. And so they're tripping all over each other trying to solve the same problem. Of course, that's inefficient, and it can cause problems in terms of morale and engagement and general output. Projects getting stalled before delivery, and multiple people being focused on the same problem without having coordinated at all. Both of those end up causing very inefficient allocation of the company's resources. What will happen is the companies over time will deliver less work and each piece of work that's delivered will have less of an impact.

Now I say these things and you say, well duh, bad, right? But I think that they're really bad for a startup that doesn't have a lot of money. It's not like they can just hire a bunch of people. It's not like they have unlimited runway. This reduction in efficiency, this slowing down and reduction of impact, is really problematic.

They're also under pressure to grow. There isn’t unlimited runway, so we can’t just take as long as we want. We’ve got investors who are expecting certain growth metrics to be achieved. When a company's not doing that, that's obviously a problem.

These two problems 1) the work slowing down and 2) the people running into each other, aren't really that hard to solve. I think what's much harder to solve is when leaders react to these problems, they tend to take the wrong approach in solving them and they actually cause more problems that are much harder to solve.

Let's talk through the mindset of a leader in this situation, which will happen to pretty much every leader over time as their company grows, and definitely isn't a fault of theirs. This is totally a feature, not a bug. But it's something that we can still figure out how to manage around. When a leader sees that their team is struggling to get things done, there is a natural thought process, or logical leap, that goes: my team is struggling to get things done, therefore, that means that it is not appropriately resourced. And if the team is not appropriately resourced, my job as a leader is to bring more people onto the team. So they hire more people. But this actually makes the company move even slower, and further reduces the quality of the work.

The reason that's happening is because there are now more people throwing up concerns or blockers on projects than there were before because there are just more people at the company. And there are also more people working on what is really the same number of problems. Whereas before maybe I was running into just a couple people and that was problematic, now I'm running into five or six people as I work through these same problems and that, of course, slows me down. It also slows them down.

I've seen this happen many times with my clients. The more people that get hired, the more people that every project needs to be aligned with. And as those additional people get hired, everyone else around them gets slowed down because they're being asked to review or participate in more and more work from other teams. I, as a leader, have gone from just delivering work on my own, to needing to coordinate this with some people, to suddenly being pulled into a lot of meetings just to verify that other teams are doing things that aren't problematic for me. This becomes a vicious cycle. Added resources. Added resources. And then reduced output. Reduced output.

This reaction by leaders of just deciding to hire more people, that's the problem. We're in this situation as a startup, I see my team is slowing down. I think that they need more help. So I'm going to bring on more people, but now I'm being told by Max more people isn't going to help. Well, what then can I do as a leader to get my team out of this downward spiral of productivity that I'm looking at and observing as a leader?

Quality over quantity

Let's think about this from the perspective of what is the underlying problem here. From my experience, the problem that actually needs to be solved isn't related to resourcing in the slightest. I watched this jump happen from not seeing enough output to needing more people. Every C-suite executive, every director, every leader of teams is going to say they need more people if you want them to get this work done. But instead of focusing on how many resources a team has, let's talk for a moment through how the work is getting done.

I recently started working with a client that is experiencing this exact growing pain. And again, I've seen this happen with every startup. If your startup is at all successful, you're going to grow and you're going to experience this problem too. This startup that was having this growing pain of reduced productivity, and people running into each other, they were on this mad dash to hire more people.

And it makes sense. Like I said, that’s a very natural reaction. Leaders don't want their teams to be underwater.

When I started working with this client, I just spent the first few weeks meeting people in different parts of the org asking them about what they do. I was just trying to get context and see how all of the different pieces fit together and also trying to see what kind of problems needed to be solved and if there was some way that I could help solve them. What I noticed was the same thing that happens with a lot of companies, which is a lot of teams were all focused on the same problem. They were just trying to fix it in different ways. The sales team was focused on one problem. The ops team was focused on the same problem, but focused on it in a slightly different way. And of course, the product team was also trying to fix this problem, and they were doing it another way. All of them were tripping over each other. They weren't coordinating at all. In fact, they thought they could work entirely independently of each other, because I'm sure that's how it actually had worked for the longest time. But they were all getting to the finish line with their work and then getting these blockers thrown out by other teams who said, well, if you do this, this is going to impact what I do in a negative way and make this other problem worse. They were all intending to solve the same problem. They all wanted the same outcome, which was to fix this problem, but the fact that they were focused on it independently meant that none of them were actually capable of fixing it. They were ultimately just making no progress in solving this problem despite having more people than ever at the company working on it.

With this team, based on my experience of having had the same problem in many other contexts, and seeing how it doesn't work to just bring more people in, I recommended taking a slightly different approach. What we tried to do instead, because I had seen this not go well so many other times, is I said, what if we just focused fewer people on this problem? What if we said, for now, one team is going to focus on this problem, and another team is just going to focus on a totally different area of the business. This helped almost immediately. The team that was focused on this problem started moving a lot faster, and the other team was able to deliver value in other parts of the org and solve other problems.

That was only the beginning point. Making sure that people are focused on the right things and that we're coordinating who's focused on what makes a lot of sense. But then there was this piece around coordination. What I saw was that lots of the blockers that were being thrown up by other teams and lots of the concerns being thrown up by other teams were being thrown up when projects were already being worked on. Some team had decided they were going to start focusing on a problem. They make some progress on it. And then, kind of through happenstance, another team finds out about it and they say, you can't do this because X, Y, or Z other thing is going to be impacted, or we don't have the resources to help with that thing, and you need our help in order to deliver this. That makes sense because there wasn't any coordination before the company. So there wasn't the muscle built to say, I need to check with these other teams before I start doing anything. And so one of the big pushes that we made when I joined was, let's focus more on coordinating beforehand rather than communicating after the fact.

With this client we shifted effort to upfront coordination. And this also had immediate benefits. At the beginning of big projects, we had leaders of these projects write out a relatively short document called a “request for comment”. If you're interested in these resources, I'll talk more about them later. A “request for comment” was a short 1-2 page document that said:

• The problem we want to solve

• Why we want to solve this problem

• How we're going to go about solving this problem

They were then asked to share that document with every other function that either would be impacted by this work being delivered, or whose work was needed in order to deliver this project. Now, instead of teams throwing up blockers after the fact, teams were getting involved early on and we were coordinating efforts amongst teams. This process is ongoing, and it is something that an org has to get used to. But there was a very big shift once we started sharing information up front before projects were started. All of this effort that had been essentially wasted when individual team members were going off and doing their own thing and then telling other people about it after the fact, now that was all being avoided. The only way that you could go off on your own and do work was if every other team was already made aware of it and given the opportunity to give input. Projects are now making a lot more sustained progress over time, rather than being tripped up by other teams after the fact.

Don’t forget to standardize

We have focused the team more, reduced the number of cooks in the kitchen, so to speak. And then we've also improved the coordination amongst those cooks. So not everyone is trying to grill the fish. Some people are plating, right? Now you know the extent of my kitchen knowledge. And then the last piece that we focused on, and I think is really important for startups going through this growth phase, is standardization. Most startups, when there are just a few people, it's pretty easy to make sure that everyone's doing something the same way. If you have two engineers, or let's say you have two customer service agents or two customer success managers, it is pretty easy to make sure that they're largely following the same process that they're both doing. But now there's a larger team. In the case of this client, let's say they have 40 customer service agents, but this is true even at 10, this is a lot harder to accomplish.

In this example that I'm talking about, there was a customer facing process that was the culprit here. The customer service organization, which historically had been just a couple people, handled client onboarding completely different from one another. This person was handling it in six steps. This other person was handling it in three. And this created differences in client satisfaction that were really hard to pinpoint the root cause of, because not everyone was following the same process for onboarding them. We did some deep diving and some shadowing and discovered this might not be related to the client's experience once on the platform. This might actually just be related to what information they got in the beginning. And that's just due to differences in how the different customer service people were onboarding clients.

This also made managers' lives a lot more difficult because, instead of having a best practice that they could train everyone on with central resources of documentation and training videos and you name it, they were having to personally identify all of the best practices within their team. They were having to decide this person's doing this better than that person, and not based on much data. And then they were having to independently train every other member of the team on these best practices. So it made managers’ lives harder, and also made the job of every other team a lot harder too. The product team comes in and says, we want to automate some of the client onboarding process to save time. It's really hard to do that when there's not a standard process. If 10 different customer service agents or customer success managers are all handling onboarding a different way, how can you automate that process? It became a lot harder for Product to do its job of automation, because there was no basis upon which they could automate. How could a sales team identify ideal customer profiles if the customers that were successful were all having entirely different experiences on the platform from one another due to our own internal differences in how we approached it, rather than due to just what their experience was on the platform with that piece removed from the equation?

Standardization, it became very obvious, was really important to the company's productivity. This process consisted of two different parts. The first was to break down the process in question, in this case a client onboarding process, into its component steps. Then the next was to document and train on it. The process breakdown, the first thing that we did was we wanted to identify all of the possible steps that could be taken to onboard a client. We looked at the happiest customers. And we looked back on their onboarding process and we tried to figure out what were the steps that had been taken for them. And then we also looked at our highest rated customer success managers, and we tried to identify what their onboarding processes were independently. And then we pushed those all together into some Frankenstein onboarding process. It certainly wasn't perfect, but at least it could become a foundation that we had some data to support as the correct systematic approach.

Once we had that standardized set of steps, it would be a lot easier to iterate on those. If we had everyone handling all of the onboarding steps the same way, it's a lot easier for Product to automate some of those, because they're happening the same way every time. It's a lot easier to measure a customer success manager's performance because they're doing, in theory, all the same things that every other customer success manager is doing. The difference in performance is not based on what steps are being taken, but rather the actual performance of the individual. What we tried to do was go from no documentation, no standardized steps in a process that we were repeating frequently and we know is pretty core to the success of every customer on our platform, and therefore important to the business. Let's identify what all the steps are that we want to take. And then let's do the next thing, which is document and train on them.

The document we made is called a standard operating procedure, and this is often referred to as an SOP. And this document is meant to just be a literal step-by-step guide to how this process works. It's meant to allow for people with minimal amounts of training to understand and implement it. This customer onboarding process went from black box to easily comprehensible steps. Each of these steps had scripts with either things that the customer success manager would say or write. It had screenshots explaining how to add the client onto the platform, and then also videos that walked the customer success manager through what to do. We took this standard operating procedure, and then we solicited it with all the other teams in the company, just making sure they were all on board with how it works. Got some really good feedback and ideas on how to improve it. And then we implemented it.

Almost overnight we went from onboarding customers completely haphazardly to onboarding customers with not perfect but good consistency, and this improved the customer's experience dramatically. It also improved the team's efficiency, because now instead of having to remember every step of the process, we could take the customer success manager's brain out of the part that was just memorization. We could say, just look at this document and follow these steps and check them off as you do them. It became really easy to get good at that and get fast at that as they repeated the process a few times. Then they could allocate their brain to other things that required a lot more creativity. So the whole team got more efficient as they moved along that learning curve of this repeatable process.

I shared this story because I think it is illustrative of the problem that many startups go through, which is, as the company grows, people start having a harder time working together and everyone slows down. And the result of this work was not that this client of mine hired any more people. In fact, there weren't any more people that were hired as part of this process. But there were still tremendous improvements made in the company's efficiency and output. They went from having a really hard time improving the quality of their customer experience to seeing almost immediate benefits and improvement in that area, all through using the right productivity and coordination tools.

I think the lesson here is, as your company grows, if you are saying to yourself that you think you need to hire more people, check that logic for a moment and make sure it isn't because people are just not coordinating well and tripping over each other. Some of the warning signs that the answer might not be to hire more people is if you are hearing from team leaders or individuals in your organization, that they’re getting really frustrated with this other teams because they keep being told by that team that they can’t do something. That might be an indicator that there isn't enough coordination in the early part of a project. Also, if you are hearing from different parts of the organization that their functions are focused on the same problems as each other, then there's clearly not enough coordination. They may not even be saying they’re focused on the same problem as each other. They might just be saying independently that they’re focused on solving the same problem. You as a leader need to make those connections. And if you're seeing multiple teams through their own planning processes, or just in talking to your direct reports, that there are a bunch of teams focused on the same problem and you're not 100% sure that they have coordinated their efforts, then the opportunity there is not to add more people, not to add more cooks to the kitchen, but rather to figure out how they could better coordinate.

I bring up these tools that I talked about, the request for comment and the standard operating procedure, because they're really basic tools that can do a lot of good for an early stage startup that has historically not documented super well, not maintained a knowledge base super well, and not coordinated amongst teams super well. A request for comment can allow for input to be given by a bunch of different teams in a way that just didn't even exist before. And all it requires is the project owner to write a one to two page document. The standard operating procedure turns a process that might have no standardization whatsoever, and certainly no documentation and no training on it, and suddenly allows for your whole team to be doing something the same way. It allows for you as a leader to hire more people in the future as you need them and have them immediately follow the same process rather than creating their own. You can just see how both of these tools, one, they avoid wasted work, and two, they increase efficiency of the organization tremendously.

And then the final piece I'll recommend is just having a project plan. Even something basic that says the steps you’re going to go through to complete this project. Having that tracker, and having deadlines associated with it and specific steps being taken, and milestones, that will help other teams know what's going on. It'll also help that individual clarify their thinking and maybe identify areas where they're going to need help that they might not think of off the top of their head. Creating a project plan, a basic one, can take as little as 10 to 15 minutes. But if there is a document now that someone else in the company can reference and say, I wonder what they're doing in this area, or, I've heard about this piece of work, I need to go ask someone about it, now they can just reference this project plan. They can give their input that way, or at least have knowledge about it such that they can go do work accordingly. That's at least reasonably better coordinated with a project that's already underway, because there's a plan to look at.

As you reach the inflection point of much faster growth and you run into as a leader, issues of productivity or your teams bumping into each other as they try to do work. Hopefully this was a helpful primer on what you can do instead of just hiring more people, and why just hiring more people may not be the answer.