There is a lot of literature about how to run a company in its startup phase. There is also a lot of literature and even MBA programs that cover how to run a scaling or a scaled organization. There seems to be a void, however, on how to transition from a small company with a small team into a scaling organization without dying in the process. That void is left for entrepreneurs to figure out.

I’ve discussed this with many entrepreneurs who have faced failure at this stage, not for lack of clients but due to the difficulty of handling the load. Others have preferred to stay small, to have more control, as they describe it. I found that “From startup to a scalable enterprise: Laying the foundation” by Joseph Picken does a great job describing eight challenges that companies face in this transition period: keeping direction and focus, positioning, maintaining responsiveness, building the organization and management team, processes, culture, financial capability and managing risks.

We lived this challenges several years ago after opening our office in Los Angeles and landing a contract with a Fortune 100 company. What started as some software development and maintenance of an iOS and Android mobile TV streaming app grew to multiple OTT apps (FireTV, Android TV, tvOS, Chromecast) plus a backend in less than a year.

When we moved, our company was made up of seven people in total. We had doubled the team a year later and had gone from supporting two platforms to 10 if we included other clients. We were starting to see issues with team focus, responsiveness, processes, and culture. It was not that we didn’t have a process — we considered ourselves “Agile,” used JIRA and Scrum principles, and had coordination meetings, but things had started to slip through the cracks.

‍

The Symptoms

• Release times started to slip. Even with the addition of more employees, team velocity was not improving.
• QA expressed that they were idle a couple of weeks and then crunched with tasks a week before release.
• Feature requests started to get lost at the bottom of a to-do list.
• We had internal meetings, yet problems only surfaced at the end of the sprint when they were harder to solve.
• Every product request seemed like a priority.

As a result, we brought our first dedicated product manager to the team. He had plenty of experience implementing scrum at different companies. We explained the symptoms we were seeing and the challenges we were facing.

‍

The Challenges

These are some challenges we faced that you are likely familiar with when scaling your own development teams:

• Teams were technology focused so developers continuously jumped from iOS to tvOS, Android to FireTV, backend to Chromecast. You get the picture.
• Changes were introduced in the middle of sprints, pushing builds and limiting time for QA during the sprint.
• QA received story tickets by batches when they were already done by the developers.
• We had one designer, who had way too much work for one person, making resources limited.
• Teams were too product focused, having little to no time to explore new technologies such as AR, VR, Magic Leap, and Oculus. Our team also couldn’t test new tools and features that would have been of great help in our day-to-day work.
• There were too many people to coordinate.

The project manager’s diagnosis was simple and clear: “You are great, but your process doesn’t scale.” With that, we were given an action plan and we got to work.

‍

The Actions

Here are the steps we took to scale our processes more efficiently and coordinate our teams. If you’re facing challenges like those outlined above, consider implementing a similar plan:

1. When there are simply too many people to coordinate, split the teams. Small teams communicate, execute and adapt better.

2. Rather than having technology focused teams, have each team focus on a product for a specific platform paradigm (e.g., mobile stream app, OTT/connect app, backend). Product focus leads to specialization, which in turn leads to speed and quality.

3. Assign team members, especially product managers, and developers, to dedicated teams. Dedicated teams create ownership, accountability and team building.

4. Reduce sprints to two weeks. Shorter and predictable sprint length produces rhythm and cadence, leading to faster results, faster reactions and the sense of incremental and constant progress.

5. Lock sprint goals and priorities as much as possible. Changes in the sprint break rhythm. If you set goals correctly, it shouldn’t happen; if it does, you can always adjust on the following sprint.

6. Detach releases from sprints, thus detaching regression testing, too.

7. Make clients a part of sprint planning and sprint review. You can even involve some of them in your daily standups. This facilitates vision alignment, priority buy-in, faster client feedback and a sense of victory at the end of each sprint.

8. Add sprint retrospectives as a ritual for each sprint. Retrospectives allow you to learn and self-correct from sprint to sprint, establishing a growth mentality on the team.

9. We created a group concept that is more technology or field-specific. It is not for product coordination, but for growing team knowledge of each area.

Although we try to avoid it, when we do have shared team members, product managers negotiate the work and priorities so that everybody is on the same page.

‍

What were the results? Well, our team has grown to 40-plus people who are able to coordinate different projects, clients and teams. When a new project is coming, people already know how to structure it: a scrum, a board, rituals, a series of sprints. We have grown and scaled dynamically. Surprisingly, everyone adapted faster than expected once scrum was implemented.

New learnings and challenges have appeared as we have reached this scale, but I hope this will get you started in your scaling journey. Have you faced similar challenges? How have you addressed them? Don’t forget to share it in the comment section below. Clap and follow!