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

- 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:

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:

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:

As you transitioned into growth were there any big surprises or interesting differences compared to your expectations?
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:

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:

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:

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:

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:

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:

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:

Does having the broad purview of owning both the design system and growth engineering offer you any unique opportunities or benefits?
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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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