_edited.png)
In the early stages of a startup, employees can be very effective while operating independently from others on the team. This is the case because most employees are departments of one person, and they are responsible for creating their department from scratch. Doing the basic work of building a department as the sole employee in that department requires very little coordination with others. In the case of a client of mine, there is one person who does all of their enterprise sales. Assuming that person has at least a basic understanding of the product they’re selling, they can design and manage a sales funnel completely on their own. They don’t need to coordinate with other salespeople. They also don’t need to coordinate with a finance department (because there isn’t one).
Every startup goes through the transition from individual to team-based work, and that transition is really challenging
Of course, that setup doesn’t last forever. Any startup that has even modest success will have to hire more people. And those fledgling departments with only the most basic of processes and best practices eventually grow to be more complex. As the complexity of the work increases, and there are more people doing that work, there is a pivot point where the optimal way to approach the work being done goes from individual to team-based.
That pivot point is where I find most of my clients, and fast-growing startups more generally, get really tripped up. The leadership team is used to operating in their own little worlds, and their time has historically been spent just doing the work with very little advanced planning or coordination with other teams. Now that their company has grown and gotten more complex, leaders might notice that projects are starting to stall right at the finish line because other teams are bringing up concerns about how this team’s work might impact their own. Whereas before, every team was focused on completely different problems and never ran into each other, now leaders might start to notice multiple teams actually focused on the same problem, more often than not without having coordinated those efforts at all.
Projects stalling before delivery, and multiple people being focused on the same problem without having coordinated at all, both result in inefficient resource allocation. Companies deliver less work, and that work has a lower impact. Those alone are problems for a startup that is 1) cash-strapped and 2) under pressure to grow. But, in my experience, these problems aren’t all that hard to solve. The really impactful, much harder to solve problems are the ones that occur from leaders reacting to this situation.
Lack of output = needing more people…right?
When a leader sees that their teams are struggling to get things done, they will often conclude that their teams aren’t appropriately resourced. And, of course, when a team isn’t appropriately resourced, it needs more people. So they hire more people for their teams. But instead of solving the delivery problem, speed and quality actually get worse. There are now more people throwing up concerns or blockers on projects. And there are more people working on the same number of problems. I’ve seen this happen repeatedly 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 gets slowed down because they’re being asked to review or participate in more and more work from other teams. It becomes a vicious cycle of added resources and reduced output.
If more people won’t help, then what can startups do to get themselves out of this downward spiral of productivity? Well, what if the problem that actually needs to be solved isn’t resourcing-related at all? Many leaders jump straight from “lack of output” to “more resources”. But it may make more sense to focus on how the work is getting done. I recently started working with a client that is experiencing this growing pain and was on a mad dash to hire more people to fix it. I spent my first few weeks with them meeting people, asking those people about what they do, understanding how all the different pieces fit together, and determining what problems needed to be solved and how I could help solve them. With this client, I noticed a bunch of teams were all focused on the same problem. The operations org was trying to fix it in one way. The product org was trying to fix it in another. And they were both tripping over each other, causing themselves to make no progress in solving a problem that they had more people than ever working on.
More planning and coordination will go a lot further than more people
With this team, I recommended taking a counterintuitive approach: focusing fewer people on the problem. Maybe Ops could figure out a short term solution while Product worked on some other areas of the business for the time being. This immediately helped. The Ops team started moving much faster, and the Product team was also able to deliver value elsewhere.
The next step was to improve coordination. Lots of the concerns and blockers that were slowing down projects were being presented once projects were already being worked on. With this client, we decided to try shifting more effort to upfront coordination in the hopes that this would prevent downstream problems. This also had nearly immediate benefits. At the beginning of big projects, team leaders were asked to create overview documentation that could easily be shared around with other teams for review and comment. Now other teams were getting the opportunity to provide input and identify blockers at the beginning, rather than the end. The process has been a slow one for the org to adjust to, but the time invested upfront has resulted in a lot fewer concerns being brought up later, and projects are making sustained progress over time, all the way through to delivery.
The final way we improved team impact was through standardization. When this team was just a few people, it was easy to make sure they were all doing something the same way. But now that they were a larger team, this was a lot harder to accomplish. In the case of this client, it was a customer-facing process that was the culprit. The customer service organization was handling client onboarding in completely different ways from one person to the next. This created differences in client satisfaction that required a lot of deep-diving and shadowing to understand. It made managers’ lives more difficult because they were having to personally identify best practices and independently train every member of the team on them. And it made the job of every other supporting team, from Product to Sales, a lot harder. How can you automate a process that is done differently all the time? How can you identify ideal customer profiles when customers were having entirely different experiences on the platform from one another from the very beginning?
The process of standardization consisted of two parts: process breakdown and Standard Operating Procedures. The first thing we did was to identify what we wanted our onboarding process to look like. We took our happiest customers and figured out what their onboarding steps had been. And we looked at our highest-rated customer service team members and identified what their approach to onboarding was. Then we mushed those all together to create a set of steps that we believed made sense for every customer to go through as part of their onboarding process. This wasn’t going to be perfect, but it was at least a pretty ideal foundation we could then systematically iterate on.
The next step was to create a Standard Operating Procedure (also known as an SOP for short). This is a document that’s meant to be used by anyone in the organization to follow a process. The customer onboarding process was turned into a set of easily comprehensible steps, each with scripts, screenshots, and videos explaining exactly what to do. We circulated this SOP with all of the major stakeholders in the company to make sure they agreed with how this would work, and then we trained all the customer service team on the new process. Almost overnight we started onboarding customers with significantly greater consistency, both improving the customer experience and significantly increasing the team’s efficiency as everyone move along the learning curve of a now-very repeatable process.
The tools I use to help my clients deliver better work faster
Below I have gathered a number of resources that could be useful to you if you think your organization might be experiencing similar growing pains. Implementing even a basic RFC process, a standardized project plan document, and a standardized SOP design can do wonders for your team’s efficiency.
Request for Comment (RFC)
HashiCorp’s RFC template - may be slightly technical for most startups but can be customized