Counterintuitively, Adding Capacity doesn't Help
The company has been doing well. They have managed to become EBITDA positive, they are heading for $100M ARR, and as a result, there is a majority investment from private equity.
Uh oh!
Of course, getting an investment isn’t a bad thing, but with it comes increased expectations. No firm invests in a portco just to watch it sit. They want improvements! More growth, better margins, more ownership of the marketplace.
The company starts growing and changing quickly so they can meet their new targets. But when the workload starts to increase, areas that were once high-leverage in the organization can very often become the bottleneck.
With very good intentions and rational decision making processes, leaders often set out to alleviate the bottleneck.
More process
What you think will happen: There is too much work coming in and the teams can’t execute on it because they don’t have enough information. The team believes it must be Product’s fault, or Engineering’s fault, but they have written a lot of documentation so it can’t be theirs.
They decide to put more process around it so that when the work does arrive, it will be ready to execute upon and they will spend much less time on the back and forth. Often this looks like some kind of intake meeting, similar to an Architecture Review Board. Work is submitted for approval by the requesting team, designs are checked, improvements may be suggested. If everything is ok, they get the rubber stamp from the receiving team.
What actually happens: The extra process slows things down even more. Now instead of having to just wait for the tickets, people have to wait for a slot to open for the intake meeting. Just like with a Change Advisory Board, if the person in front of you takes too long, your request is often bumped to the next meeting.
The requesting team just wants to be able to get their work done, but now there is a wall of process standing in their way. The receiving team thinks that the value they bring to the organization is that they have the permission and expertise to execute on the requests.
Instead of finding out what people want and giving them a safe and easy way to get it, we give them paperwork. As Sidney Dekker says in The Field Guide to Understanding Human Error, “paperwork gets in the way of talking and listening to people.” (pp. 149)
What to do instead: Instead of trying to push more work through the system, change the system.
Focus on standardization and automation. The best way to ensure that developers meet the intake requirements is to give them self-service tools. The tools will not work without the proper inputs!
Make it easy and safe (shift left) to do things earlier in the process so the team is left with hard problems that are focused on value creation, not task completion.
More people
What you think will happen: We will hire more people. We are so close to being able to handle the amount of work coming in, that if we could just hire a few more people, we will finally get over the hump.
I’ve literally had a VP of Engineering inform me that he’d like the outcome of my investigation into the organization to result in a recommendation that we hire a few more people. Spoiler: that was not the outcome.
What actually happens: It turns out that the problem isn’t that we just need a few more people. It’s that there is no real direction to the work. Work comes in and the team is expected to react to whatever comes their way.
- There is not a great awareness of upcoming work. A lot is “emergent” and “unplanned” and the team complains about this.
- “Most of the work is on the walls and the roof, not the foundation.”
- “I wish there was more centralization of planning like picking technologies and architecting solutions.”
Each team member comes up with last minute solutions to whatever problems come their way and the wheel is reinvented time and time again. Adding more people makes the problem worse, because now there are even more things in flight simultaneously, and even more wheels being invented.
What to do instead: Aristotle said that “nature abhors a vacuum”. If we add more capacity to the team, that capacity will quickly be filled without noticeably increasing throughput .
A leading middle market operating partner has said, “If you want to grow, add capacity. If you want to scale, add efficiency”. A private equity investment requires that we scale the business. It’s not enough to add a few people.
-
Make a serious effort to classify the work. What are things that we see over and over again? Environment creation? Manual Regression tests? Standardization and automation can help.
-
Leaders need to connect with their partners in other departments and stay 3 weeks ahead of their teams, understanding what work is coming, and what needs to be in place for their teams to be successful when the work arrives. All the while, looking for patterns and efficiencies. As we say in Agile: maximize the work not done.
More specialization
What you think will happen: We will break off a team that is solely focused on the routine tasks that are necessary to keep the lights on. This will free up the more experienced engineers to focus on solving those problems once and for all. Once we get to a better place, we can roll that team back into the larger group.
What actually happens: The “thousand paper cuts” team does a lot of restarts and disk allocations, problems that should be solved through application logs and capacity planning. They may take some work off the rest of the teams, but in reality, they just push the pain to a different part of the organization: their own.
Because the more experienced engineers are no longer feeling the pain, they work on more interesting (to them) projects that do nothing for the paper cuts team. The “temporary” paper cuts team sticks around for years.
What to do instead: Breaking off a team to handle toil does not have the intended effect. Instead, we need to reduce toil and increase efficiency. The team that needs to fix the problems needs to feel the pain and they all need to work as a team, together, to dig themselves out of the hole. Maybe that means each team member takes a week rotation handling the toil tasks while the others support them with new tools.
Maybe that means adopting a new SaaS tool that will handle some of the heavy lifting like maintaining the monitoring system or the CI/CD pipelines. The costs might look high, but would you rather pay your staff to work on undifferentiated heavy lifting?
More capacity
What you think will happen: We will approach one of our engineering outsourcing partners and we will spend a lot of money getting extra capacity. We will use this capacity to do all the things we can’t get done right now because we are overwhelmed.
They can write Terraform, rewrite software to be more modern, and automate tests. There are all kinds of projects they can build for us. They have the engineering talent and have seen it before!
We will get a One Time Investment from the private equity firm to pay for it, and when the projects are complete, we will make absolutely sure that they train our people on what they’ve built so we can run it ourselves.
What actually happens: Millions of dollars are spent to build things that our people know nothing about. Sure, they are asked questions here and there, but for the most part, they are busy enough doing their own jobs that they don’t have either the time or the inclination to worry about what some people on the other side of the globe are doing.
The outsource partner writes a ton of code knowing that they will not be responsible for it at the end of the contract. The most important thing is that they can demonstrate to the client that it works and that it’s documented. Meetings are held where progress is shown over and over and many people in leadership justifiably begin to feel very confident about the path they have chosen.
The engagement ends, the team spends some time training the internal team and then hands over their projects. The internal team has a superficial understanding of what was done, but wasn’t involved in any of the real decision making that went into the project. They may know what the software can do, but they don’t know any of the “how “or “why” that is actually necessary to operate the system at a professional level.
When something inevitably breaks, they have no idea where to look to figure it out because they were not involved in creating it, and all the people who were, have left.
What to do instead: There are definitely situations where bringing in outsourced partners makes sense. But the teams that will be responsible for the results of those projects need to be involved in what happens every step of the way.
What about their regular jobs? Well now they have a much larger team so they can figure out how to both keep the current system running, while also building the new one. They can even use this to their advantage by leveraging practices like “the strangler pattern” to make sure that the new systems are suitable replacements for the older ones.
When the surge capacity finally rolls off, they will do so with everything in a much better place and the people who are left to maintain it will be capable and competent to carry on, even if at a reduced pace.
Outcomes
Almost all companies are trying to grow and improve. A private equity investment puts time constraints around this activity while also empowering the organization to make real change. This creates challenges. By moving away from trying to push more of the same work through the system, and embracing a product-oriented approach where we understand the demands of our customers and work to satisfy them, teams can unlock true scalability and efficiency.
This type of transformation requires strong and diligent leadership. By focusing on these principles, engineering teams can move from frantically treading water to confidently swimming toward their goals, ultimately contributing to the success of their portfolio companies.