How This Growth Engineering Team Responds to Changing Business Needs

CircleCI’s growth engineering team experiments often and runs autonomously. In 2021, the team will continue to scale and is looking for engineers who share in their curiosity. Interested in learning more? Read on. 

Written by Kelly O'Halloran
Published on Dec. 29, 2020
Brand Studio Logo
circleci
circleci

Growth teams are an anomaly among engineering functions. But at CircleCI, the growth team is embedded across the entire platform. 

The continuous integration/continuous delivery (CI/CD) platform’s growth team is broken down into three fields — activation, engagement and buyer experience — and from there, the company modifies the team to support whatever the issue requires.

“Whatever the problem needs, the growth team is built around it,” Senior Engineering Manager Mohammad Badrah said. 

If it’s a UX/UI problem, Badrah said they curate a mix of front-end and API engineers. If it’s a relevance or speed goal, then they dedicate mostly back-end engineers. Additionally, if CircleCI’s most leverageable products don’t have enough resources, then the growth team steps in.

“By having a growth team that is not bound by a specific product-line roadmap and responsibilities, it gives us more freedom and autonomy,” Badrah said.

As CircleCI continues to scale its growth engineering arm, Badrah and his colleagues shared why their structure works and what challenges it presents for its engineers. 

 

CIRCLECI’S PLATFORM

CircleCI’s continuous integration/continuous delivery (CI/CD) platform provides VCS integration, automated testing, notifications and automated deployment for developers looking to build, test and deploy code. Its platform runs on servers or in the cloud and averages 35 million builds every month.

 

How has the growth team evolved over time? 

VP of Product Growth Sammy Shreibati: We initially had one team doing all of the growth that was tackling large metrics. These metrics were hard to move, and we didn’t have the right experimentation framework to measure success. It was what we called the “user engagement” team. As we spotted that the conversion rate earlier in our growth funnel was one of our top leverage points, we refocused the user engagement team on activation. We then created another team, “engagement,” to focus on retaining and driving product usage motivated by maximizing the ROI of using our product for our users. Now, we are expanding and building a dedicated paid-conversion team. This is how we change a team’s focus to address a more pressing pain and add dedicated teams when it calls for it. 

 

What benefits come from embedding the growth teams into the product engineering team?  

Senior Engineering Manager Mohammad Badrah: We sit at the same table as most of the other engineering teams that are working on the CircleCI platform. This empowers us to collaborate with the rest of the engineering team and advocate for A/B testing and feature flagging, as well as foster the growth culture in our engineering organization.

 

STRUCTURING THE TEAM BASED ON BUSINESS NEEDS

CircleCI’s growth team shifts toward the needs of the business. That means if the company’s biggest challenge is losing paying users, they would respond by assigning a growth team. Similarly, if its largest issue was activating and retaining authorizations, then teams would be added in those spaces. “Some of these areas are evergreen areas, and some of them you can change the charter,” Badrah said.

 

Walk us through an example of how CircleCI’s growth team operates.

Engineering Manager Daniel Lanthier: Our onboarding process involves a significant learning curve. Almost immediately, our users are confronted with reading and having to customize YAML files. The language itself has a significant learning curve, and there’s also a learning curve on how to use it on our platform. We assumed that our users wanted to be educated, so we responded with working start samples to give insights over what a small configuration may look like for a simple CI/CD pipeline, a call to action that provided contextual links for our users to our developer documentation, and promotion of our concept of orbs, which are reusable configurations to simplify the configuration.

However, we discovered that our new users wanted to quickly build proof of concepts and get things working without using our guides. This led to them making countless mistakes and iterating over and over until they got it right. 

We needed to remove friction in our product to allow clients to iterate faster and deliver a proof of concept. As a team, we decided to allow users to commit configurations from within the product that would help them iterate faster while also giving them immediate feedback when they make a mistake in our web application by running YAML and configuration validation.

 

What was the outcome? 

Lanthier: Both of these experiments have resulted in a net improvement of 10 percent additional activations. This was massive and has confirmed that our users aren’t necessarily looking to gain expertise at this stage. Rather, they’re focussing on getting incremental results. 

 

 

Lastly, what’s ahead for CircleCI’s growth team in 2021? 

Badrah: Our growth teams have scaled considerably in the last few months. We’ve learned how to experiment with our product over the last couple of quarters, but we also need to improve how to scale our contributions to the rest of the organization. We are looking to scale and optimize how we work with other teams, as well as how we enable strategies to remove some of the dependencies with other teams. On the activation side, we’re trying to minimize friction points for our users to help them quickly get to a CI/CD proof of concept. On the engagement side, we’re aiming to maximize the ROI of using our products to our users and understand how to better engage our users into collaborating around their CI/CD process. 

Responses have been edited for clarity and length.