Building a Growth Engineering Organization from Scratch while on a Rocket Ship 🚀 thumbnail
Conversations

Building a Growth Engineering Organization from Scratch while on a Rocket Ship 🚀

Alon Bartur's headshotAlon Bartur
  • August 11, 2022
  • 18 min read

A conversation with Sarah Brown

Once again, we are extremely fortunate that a talented growth engineering leader has candidly shared her experiences in growth and allowed us to share that conversation with all of you! Our conversation with Sarah Brown, the founding growth engineering leader at Mux, is extremely unique and insightful as she’s just 6 months into building the growth engineering organization at Mux. Throughout our conversation, Sarah shares her experience, strategy, and philosophy for going from zero to one as a growth engineering leader at fast-paced, high-growth B2B SaaS startup.

Here are few highlights from our conversation:

  • At earlier stage startups, growth becomes pivotal as the company establishes product-market fit, demand for the product is rising, and it is no longer scalable for employees to manually onboard all customers to ensure their success.
  • Growth engineering needs foundational infrastructure, tools, and processes to be established before significant ‘growth’ work can commence. The early days for a growth engineering team are extensively focused on building out this foundation.
  • Working in growth engineering and product engineering are very similar with the main differences being goals and scope. Growth’s goals are aligned to business goals, such as revenue or pipeline, while a product team’s goals are focused on the specific feature being built. Growth has a broader scope than most product engineering teams because growth is at the intersection of so many product engineering and non-engineering (sales/marketing) teams.
  • It’s a misconception to believe that speed trumps quality in growth engineering. In reality, it is a question of scope versus impact. If you can narrow down the question you’re trying to answer with an experiment, then you can also narrow the scope of engineering work needed to answer that question.

Meet Sarah

Alon:

Alon

Hey Sarah—we’re very happy to have you joining us today. We’re really excited to learn about your experiences in growth from an engineering perspective at Mux!

To kick things off, tell us how you found your way into growth-related work.

Sarah:

Sarah

Thank you for having me; it’s delightful to be here. I found my way into growth primarily through product work. I have always been very close to product and product engineering. I’ve been on teams that are adjacent to growth work and have seen how they’ve operated in a bunch of different contexts including SaaS and consumer.

I was definitely aware of growth work and how growth teams operate. But what really interested me in taking this jump over to the growth side was the last startup that I worked at and seeing how closely sales and product worked together on the go-to-market motion. I was very interested in how that worked from a SaaS perspective and then realized that there’s a lot of growth work and self-service work that can complement that. When Mux was looking for a growth engineering manager, I was like, this is an area that I’m interested in and I think I can make a really big impact at this particular moment in Mux’s growth.

Alon:

Alon

As you transitioned into growth were there any big surprises or interesting differences compared to your expectations?

Sarah:

Sarah

It’s been surprising to me just how much of the product engineering background is applicable to growth engineering.

If we’re not sure that a particular feature is going to be helpful, we run an experiment. We front-load our work to answer unknowns and work iteratively. If we see that we’re getting a lot of positive data back from that experiment, we keep going. That is just good engineering that you could apply to many feature teams.

If we’re not sure that a particular feature is going to be helpful, we run an experiment. We front-load our work to answer unknowns and work iteratively. If we see that we’re getting a lot of positive data back from that experiment, we keep going. That is just good engineering that you could apply to many feature teams.

So I’m always surprised and delighted at the overlap there.

Founding the Mux growth engineering organization

Alon:

Alon

The previous conversations we’ve had for this series have been with leaders at companies that have had growth teams for years and had built up large growth organizations.

I know that the growth team is relatively new at Mux, and so I’m super excited to hear the early impressions that people end up forgetting about years down the line. Can you share what the impetus was for the team getting formed?

Sarah:

Sarah

Absolutely. There’re a lot of reasons why growth at Mux is new and why now is the right time. For reference, the team has existed for six months now. So we’re really just getting started, which is a super exciting time to be a part of the team.

A couple of reasons for “why growth right now”. One is that it’s been an area that’s under invested in to date. And that’s for good reason. In my experience, when you are first building a SaaS startup you’re often going to have a sales team, a CSM team, a team that can white glove the process for your customers. You don’t need to worry as much about initial impressions because often those initial impressions are coming with a salesperson or a sales engineer or support person who can help the customer understand the value of the feature right off the bat.

What we’re finding now is that we have more and more people who want to kick the tires of the Mux product and either they don’t want to talk to a salesperson or we don’t have enough sales people to talk to everyone who is signing up at this point in time. So, we’re missing out on potential customers that sign up, see the initial experience (which is pretty bare bones) and don’t get it, and then drop out of the funnel. That’s the number one reason why the growth team now exists.

The second reason, which is quite similar, is that growth at this stage in Mux’s startup journey is where we need to be. We’ve found product market fit for a number of products and we’re really looking for how to take the company to that next stage. Not only is this a fabulous feature set, which we already know it is, but also this is a company that can execute really well against that feature set.

Alon:

Alon

I would love to learn more about your role at Mux and how the team is structured. I know you’re also responsible for some core product surface areas and the design system — a super interesting set of responsibilities.

Sarah:

Sarah

Absolutely. Like many startups, the team owns many things, has many responsibilities, and wears many hats. Currently, the team is myself, a designer, a product manager, and four engineers. It operates pretty similarly to a product team, but obviously we are much more focused on growth and particularly growth on the Mux dashboard.

The onboarding experience of the Mux dashboard is our primary responsibility. In addition to that, because our team is so strong when it comes to full stack and frontend expertise, we also are the owners and maintainers of the design system for Mux and the Mux dashboard.

Our senior designer owns our design system on the Figma side of things and we make sure that those components are available for our team and other teams within the code base.

Alon:

Alon

As you’ve been hiring engineers, do you find there are certain attributes or characteristics of the engineers that want to work in growth? Also, I’m curious how you think about the roles and responsibilities of the engineers on your team and how they collaborate with their PMs and designers.

Sarah:

Sarah

It’s quite similar to how other product engineering teams work. I think the difference is that other product teams at Mux are focused on a specific feature — they’re focused on the Mux data product or the Mux video product.

We are much more focused on the overall platform-wide onboarding experience. So, we find that the engineers that are interested in and gravitate to this work are very product-minded folks. They are also engineers that are interested in data, enjoy experimentation, and understanding what actually moves the needle for our product. They delight in understanding what actually makes an impact, not just for the product but also for the business.

Alon:

Alon

Does having the broad purview of owning both the design system and growth engineering offer you any unique opportunities or benefits?

Sarah:

Sarah

A lot of benefits I would say! One of the interesting benefits from my perspective is that engineers can pick and choose what’s interesting to them at any given time. So a lot of times I’ll hear, “I don’t know if I want to go into growth because they only care about things getting shipped and they don’t care about code quality.”

On our team, that’s actually not true. It’s a little bit of the opposite because we have this other work that we can get to really engage in. We take design system components and build these quality components that can be reused, not just on the dashboard, but in other parts of the Mux internal ecosystem. So really, we get to be both super product focused if we want, but we also have the flexibility and the responsibility to create a design system that the rest of the organization can leverage, which is really cool.

Step 1: Build the growth engineering foundation

Alon:

Alon

I’m curious what your experience has been like as a founding member of the team on the engineering side. Where did you get started? What were the early days like?

Sarah:

Sarah

Honestly, a lot of the work right now is quite foundational. We haven’t gotten into the nitty gritty of growth hacking because we really are taking a step back to make sure that the technology and the processes that we have in place can support experimentation.

When first joining Mux, the main focus was figuring out if we could run experiments and do A/B tests and that involves a lot of things. Can we run them effectively? Quickly? Can we actually come up with experiments to test quickly?

When first joining Mux, the main focus was figuring out if we could run experiments and do A/B tests and that involves a lot of things. Can we run them effectively? Quickly? Can we actually come up with experiments to test quickly? All of that requires the foundation of the design system. So it’s really nice that we get to work on the design system because we get to make the building blocks that then set us up to iterate quickly.

We also focused on some more foundational things around testing to make sure that when we’re moving fast, that we’re not breaking a bunch of things in the process.

One other big focus was around processes internal to Mux. Just getting people comfortable with and excited about data-driven or data-informed decisions. That’s something that culturally with the engineering team we’re trying to push towards. For example, we know that this feature, whether it’s auto captioning or custom domains, we know that this feature is great and lots of customers have asked for it. Let’s attach data to that and see how it performs. And that’s not just across growth, but across all of engineering. Just nudging people towards data-informed decisions.

Alon:

Alon

You talked about experimentation being one of the foundational investments that the team is making both from a best practices and organization standpoint but also from a tooling standpoint. How has your team supported the experimentation and data efforts to date? Are you building internally? Are you reaching for tools? Anything that you’ve learned having gone from zero to one in that area that others may find valuable?

Sarah:

Sarah

Part of going from zero to one in experimentation is first understanding who in the organization needs experimentation. It’s not always just the growth and onboarding team. In Mux’s case, we found that the marketing team was really interested in understanding higher up the funnel.

We wanted to at least look holistically at whether we can bring in or build experimentation tooling that can support both of those use cases and potentially the onboarding use case that the growth and onboarding team is focused on.

Some growth teams own the very top of the funnel. In Mux’s case, the growth and onboarding team owns signup all the way until the trial is completed. Above us is the marketing team and the developer experience team are doing that pre-login work and experimentation. There’s a strong desire at that stage of the funnel to do experimentation, especially because they have enough traffic where experimentation becomes meaningful.

The other area is video delivery. We deliver tons and tons of minutes of video to our customer’s customers. We want to understand and make sure that the quality of experience is really there. We experiment with what CDNs we’re working with and other other quality-determining factors to understand what we can tweak for folks that, for example, may not be in North America.

Both of those are very high traffic places where you can do experimentation. We wanted to at least look holistically at whether we can bring in or build experimentation tooling that can support both of those use cases and potentially the onboarding use case that the growth and onboarding team is focused on.

Ultimately, we ended up with both build and buy. We’re looking to use external tools for targeting and experimentation analysis that can also be integrated into our data pipelines and data warehouses, so we can do further analysis with all of the other instrumented services that we already have.

The tool that we’re looking at right now is called GrowthBook. You can either host it yourself or I think they also have a hosted version that you can pay for. In our case, we’re looking to host it ourselves and that is currently in a proof of concept stage. So far so good.

Alon:

Alon

What’s been hardest technically so far in terms of getting those foundations set up and building out what you were just speaking to?

Sarah:

Sarah

Starting from zero to one is always challenging, and that’s where we’re at when it comes to experimentation, frameworks, and tooling. We just don’t have a lot there. The team members are also quite new and trying to understand just how to deploy within the current context that we’re in—an engineering culture that is still forming and trying to codify best practices around developer operations.

Coming up with a design system that’s using all of the technologies that we currently use—we inherited a lot of technologies like React, Redux, and we’re using styled-components. Taking what people already know and love and building a design system on top of that has been interesting and challenging. One of the challenges that came up was TypeScript types and just making sure that given all of the specific set of libraries that we’re using, we’re creating types that are going to help the developer understand what’s needed versus just get in their way.

Alon:

Alon

What’s top of mind for the team right now if you look out at the next quarter or so? Is it more of that foundational work or are there other initiatives that you are especially excited about or you think are going to be impactful for the team and the business?

Sarah:

Sarah

Oh my gosh, so much work that we get to do for the rest of the year that I’m really excited about! Some of it is still that foundational work. We’ll continue to work on experimentation tooling. We’ll also continue to work on best practices when it comes to testing and experimentation for folks who are in the dashboard.

We are excited to experiment with some tried and true self-service funnel tactics like checklists, tutorials, those kinds of things. But still a little unsure exactly how that’s going to play out. In part because so much of the user journey of Mux — of integrating an API into your application — happens outside of the dashboard. We don’t want to have a checklist that’s just ‘Do this and this inside of the dashboard’, because that’s not really exemplary of the kind of user journey that we see successful customers go through.

A lot of our work in the dashboard is defining best practices for other teams. It’s really exciting that other feature teams are going to start building more and more into the dashboard and they’re going to need assistance on the standard practices that we’re looking for them to work towards. Definitely a lot of that.

Later this year, we’ll work on our first project where we’re actually going to reassess the signup flow and how it’s working for us from a design perspective and also from a marketing perspective. We’ll be looking at whether the signup flow is getting us the information that we need about these potential customers so that we can understand how best to help them and determine when the right time is for sales or marketing to engage with potential customers. I’m very excited about that.

We are excited to experiment with some tried and true self-service funnel tactics like checklists, tutorials, those kinds of things. But still a little unsure exactly how that’s going to play out. In part because so much of the user journey of Mux — of integrating an API into your application — happens outside of the dashboard. We don’t want to have a checklist that’s just ‘Do this and this inside of the dashboard’, because that’s not really exemplary of the kind of user journey that we see successful customers go through. Part of that will be figuring out how we can get more of the customer journey inside of the dashboard to make it more clear what the value of the Mux product feature set is when you first signup and enter the dashboard.

Growth engineering for developer products

Alon:

Alon

That’s an interesting parallel to what we’ve seen with developer tools, where so much of that journey is people reading documentation and people trying to build something outside of the product. It’s really interesting to hear how you are thinking about trying to turn that into a more cohesive journey and experience.

Are there any other ways where building for the developer persona has impacted how the team or the company has thought about growth product work?

Sarah:

Sarah

Yes, it’s definitely been a huge impact. We have been thinking about the different developer personas even within our customer base. There are customer personas who know a lot about video. Then we have other customers who know almost nothing about video and would like Mux to lead them through that experience.

Trying to create a one-size-fits-all for all of those customers is pretty challenging. That’s why we’re not jumping first to ‘tutorialize’ the dashboard because there are many different customer journeys. It’s also why at this stage, even though we’re pushing towards data-driven/data-informed decisions, we are still using a lot of qualitative data to augment our quantitative data. We do a lot of customer research and user experience research into that customer journey.

Alon:

Alon

A lot of teams are thinking about how to tailor experience. Oftentimes things like what customers are actually trying to use your product to do comes up. Another that comes up is the level of maturity or knowledge about the space. I know developers can be sensitive to things that interrupt workflow and a lot of the traditional approaches to those types of experiences can seem jarring or counterproductive.

Sarah:

Sarah

Developers are a fun cohort of customers to work with for that reason. They don’t want to be sold to, which makes sense. They want help. They want assistance getting the thing that they’re trying to do done; or the questions they need answered, answered.

As much as we can go back and focus more on the value that the product is truly delivering and work from there, the more successful our efforts have been. As opposed to a more top down approach where we dictate exactly what the journey is that you need to go through. Because the developer usually already has a strong sense of what they’re trying to do.

As much as we can go back and focus more on the value that the product is truly delivering and work from there, the more successful our efforts have been. As opposed to a more top down approach where we dictate exactly what the journey is that you need to go through. Because the developer usually already has a strong sense of what they’re trying to do.

Alon:

Alon

It might be too early to ask this question, but when you’re starting to think about what the journeys might look like for different types of users, is it upfront qualitative research into how people are thinking about the world that you’ll be doing?

Sarah:

Sarah

We do a fair amount of customer research, largely run by the fantastic product design team at Mux, digging into the motivations and journey of the user. We augment that with an understanding of where who gets to which part of the self-service funnel. How we even define the different pieces of the funnel has been an interesting challenge on a per feature basis. What active means or engaged means when a customer is using Mux video versus Mux data. All of those are interesting to dig into and understand before we start planning the specifics of what it is we’re gonna implement.

Scope versus impact

Alon:

Alon

You mentioned earlier in the conversation that there is a common perception around the nature of growth work and the tradeoff between speed of iteration and quality. How do you think about that quality vs speed tradeoff when it comes to engineering practices within the growth team?

Sarah:

Sarah

When it comes to design system work, we make it quite clear to the engineers on the team when they’re working on something that needs to survive for the long term or if it just needs to survive for a couple of weeks while we instrument it and figure out if it is the direction that we want to go. Those two things are pretty clearly divided in that way.

For growth work, I think about it as scope vs impact rather than quality vs speed. I would much rather reduce the scope of what we’re engineering to answer a very specific question that we have.

For growth work, I think about it as scope vs impact rather than quality vs speed. I would much rather reduce the scope of what we’re engineering to answer a very specific question that we have.

I think people get into trouble when they want to run experiments on everything that they put out. It just slows things down because you have to wait a long time to get data back for the question that you’re asking. If you’re going to slow down the rate at which you can make a decision, hopefully the question is worth asking. Get really clear on the question that you want to ask and then drive towards the smallest scope of work that could answer that question.

To date, we haven’t had a problem with the quality of the experiments that we’re running. A much bigger problem for us at this stage, is making sure big design system or web platform changes have been well tested, especially with some of the areas of the product that haven’t been touched in a while and don’t have clear ownership.

Alon:

Alon

Got it. I like that framing of the scope and impact, and the expectation setting up front: “what am I putting into the product? What role will this play? Is this a two week test? Or is this something that we think is gonna be built on top of?”

Curious how those two different types of work, the design system work that the team does, and the experimentation that the team is starting to ramp up on, differ from a product development process?

Sarah:

Sarah

Surprisingly, no. The product work and the growth engineering work it’s quite similar, at least in how we approach it. I will say that our roadmap compared to other teams’ roadmaps consists of projects that are shorter in scope. We take an incredibly iterative approach to the experiments that we’re interested in running for the next half of the year.

That just looks different than some of the other product teams that may may be doing larger migrations or refactors. But for us, we end up with projects that are in the two to four week range. And we evaluate them from there: “did this work really well? Great.” Then we can continue with the next iteration of this project.

Cross-functional collaboration

Alon:

Alon

I found that growth as a team tends to sit at the intersection of lots of work that’s happening across many product development teams. You touched on this earlier with the core dashboard surface area that you own, which I’m sure is a very important surface area and vehicle for other teams to reach users with information or route them to the right place.

Have you faced any challenges managing that collaboration with other teams working in the codebase that you own, or with your team working across the breadth of product code that Mux has built?

Sarah:

Sarah

Yeah, absolutely. Growth ownership is tricky because a lot of things within the dashboard are in the service of growth. We introduce more products into the dashboard so that people can understand what products are available, use them, and get value out of the platform and we grow our user base.

With that lens on we could own everything! So, where are the boundaries? For us, this has been less challenging at the moment because we are an incredibly small team. Capacity-wise, we can’t own everything.

We’ve been really successful by adopting a collaborative model when working with other teams, where we contribute in the form of code reviews or reviews of their design. If they have questions about how best to use the design system or just how to get started in the Mux dashboard, those are all things that our team takes on because growth is everyone’s responsibility to a certain extent. There can’t be just one engineering team that’s responsible for all of it.

We’ve been really successful by adopting a collaborative model when working with other teams, where we contribute in the form of code reviews or reviews of their design. If they have questions about how best to use the design system or just how to get started in the Mux dashboard, those are all things that our team takes on because growth is everyone’s responsibility to a certain extent. There can’t be just one engineering team that’s responsible for all of it.

Some of the feature teams at Mux have been just fantastic and have focused on their specific feature growth. Then we really get to focus on the platform-level growth and onboarding experience. That’s how we’ve been interfacing with other engineering teams.

When it comes to other teams outside of engineering, it’s been interesting to try to figure out what works for us given our context and stage right now.

For example, email and notifications are very interesting. That’s something that could potentially be owned by the growth and onboarding team or could potentially be owned by the marketing team. Since the marketing team has a stronger setup and process for email right now, they are largely driving our email campaigns—like nurture campaigns when people first sign up.

As we get more folks working on growth and onboarding and can devise more complex and interesting campaigns that make use of product data—that’ll be an opportunity for us to revisit how our working relationship with marketing looks going forward. Right now, they’re doing a great job as is and we make sure that whatever we’re doing within the dashboard is reflective of the messaging that they’re sending.

Alon:

Alon

In my experience, because growth teams collaborate with other non-engineering functions, such as sales and marketing, they end up doing a lot of crosscutting work. Growth can be a place where lots of extra stuff falls because there’s not really a clearly distinguished owner in the org, things like implementing systems for marketing, billing systems, or just getting data for the sales team. Have you encountered that? Or can you talk about how the team defines its boundaries or where you’ve stepped up to support other functions to make sure they’re successful?

Sarah:

Sarah

Yeah, like engineering management in general, growth does seem to attract coins in the couch for lack of a better description. So yes, in the immediate term, I have taken point on our product analytics tool and understanding how that’s setup, where we get the data, and where do we need to ingest data from other sources, etc. I’ve also taken point on getting more cross-functional discussions happening and just getting those people in the same room to start building those relationships cross-functionally.

Yeah, like engineering management in general, growth does seem to attract coins in the couch for lack of a better description. So yes, in the immediate term, I have taken point on our product analytics tool and understanding how that’s setup, where we get the data, and where do we need to ingest data from other sources, etc. I’ve also taken point on getting more cross-functional discussions happening and just getting those people in the same room to start building those relationships cross-functionally.

There’s no one right now whose job it is to do this. As we hire more specialized roles, the growth marketer and a couple of other folks, it will become clearer who owns these things. But for now it’s more of a cabal within the organization of people who care about growth, who care about the self-service funnel and how it interacts with the go-to-market funnel.

Thanks Sarah!

Alon:

Alon

Makes sense! We’ve seen lots of growth teams, either formally or informally, build these really cross-functional groups. Again, growth work touches so many different parts of the business that they end up owning a lot of the holistic end-to-end journey and all the implications and gaps that arise out of that.

OK, that’s the end of my growth questions! Before we wrap, we’d love to learn something surprising about you that most people don’t know.

Sarah:

Sarah

Something that most people don’t know about me? Hmm, I’m a very secretive person. People probably don’t know a lot. Growing up I played the tuba, starting in middle school all the way through college, so I’ve been in all sorts of marching bands, jazz bands, winds, orchestra, the whole shebang.

Alon:

Alon

That’s awesome—you have a life skill that very few other people have!