Adopting the right scaling objectives as your company grows

Identifying what works with your team on a small scale and how to scale that as you grow can be one of the most valuable lessons you learn as a leader.

Our latest guest, John Laban, Co-Founder and CEO of OpsLevel, talks about his experiences growing a team (and a business) and how he learned to delegate tasks to the right people at the right time for professional growth across the entire organization. 

Join us as we discuss:

• Scaling your company and building a successful team
• Creating clear ownership for each team
• Identifying performance bottlenecks
• Adopting microservices

Scaling your company and building a successful team

‍

When John started as a software engineer at PagerDuty, he was their very first employee to be hired. At the time, the company was in a very transitional phase of development, still figuring out next steps after going through the famous Y Combinator startup accelerator.

But it was through these uncharted waters that he was able to learn the ins and outs of scaling a company.

Key to achieving that was communication. Since the company was growing at such a quick pace, frequent check-ins were needed to make sure that the strategies in place still worked for the size of the company and team. 

As more and more people were hired and the client list grew, different growth strategies were put in place to keep up with the changing circumstances.

“There's inflection points where the company has to change pretty dramatically,” explains John. “You might look back every year and the company might be an entirely different company as to what it would look like a year ago.” 

Crucial to scaling the company was being intentional with communication and breaking major challenges up into smaller, more manageable pieces in order to be as efficient as possible.

Creating clear ownership for each team

‍

As your company grows, your teams will start to grow with it. You’ll want to utilize this growth in employees to its maximum potential.

Breaking up your team into specific groups allows for ease in operations and for team members to specialize in one area or product. If your engineering team is growing, for instance, you can break it up into a front-end team and a back-end team. 

But if you stop there and just keep dividing up teams more and more, ultimately, they’ll still be depending on each other — and the work will end up cycling through multiple teams until the project is complete. 

To avoid this, John suggests creating cross-functional teams that focus on a specific product or feature, working on it end to end. This limits the amount of outside dependencies that a team is relying on and allows for a project to be worked on by only one team.

Identifying performance bottlenecks

‍

John hesitates to suggest that there is some sort of “nirvana” in terms of scaling your business, but identifying what slows your company’s growth will create a continuous flow of improvement overall.

These performance bottlenecks can be anything from external dependencies to internal baggage and you’ll want to minimize them as best you can. Following the state of the company and making changes accordingly to increase efficiency allows your team to move quickly. 

When building OpsLevel, John says his team reflected on what was best for their company but also learned from others' mistakes.

“Seeing what we were dealing with — and what other companies in the same boat were dealing with and how they tried to solve the problem — gave us visibility into what services and systems existed and standardized how we build our systems,” says John.

Adopting microservices

‍

Shortly after graduating from the University of Waterloo, John began working at Amazon, where he joined a massive team of engineers. By the time he got there, Amazon had switched from a monolith architecture to a microservice architecture.

“This environment was one in which you had a bunch of small services, all communicating over API's, and anything you needed to do, you could figure out how to do by figuring out how to call the API's of these other services,” explains John.

This was beneficial for John and his team as they were able to call API’s and look at customer data systems, customer clickstreams and transactions. They had easy access to tons of data that made their jobs that much easier and allowed for teams to work well independently.

Despite the benefits, a microservice architecture can make teams become siloed and prevent them from seeing the big picture of the company. Often, engineers only knew of other systems through colleagues or tribal knowledge, but weren’t able to easily discover them on their own, leading to rebuilding the same systems over and over. 

But by building new functionality, features and products, things still worked out overtime and the team was able to continue moving forward in the “organized chaos.”

‍

Want to learn more about scaling throughout growth stages, identifying and minimizing performance bottlenecks and adopting microservices? Listen on Spotify, Apple Music or wherever you find your podcasts.

‍