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

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.

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.

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

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.

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.

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.

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.

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? 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.