At Mux we have a team called “Developer Experience” (“DevEx” for short). This is the team I work on and we believe we have a critical role in driving long term growth for the company. It’s fairly common for companies these days to have “Developer Advocates” or “Developer Evangelists,” but at Mux we like the term “Developer Experience” and think it encapsulates more of the meaning behind the work that we do.
Some companies use the term “Developer Experience” to refer to the team that writes internal tooling for their own development teams at the company to use. We use this term differently in that our customers are the developers, and we’re wholly focused on building their experience.
DevEx Engineering
DevEx Engineers touch every part of the business and have the ability to move things forward and leverage their engineering skills to make an outsized impact on the company. One side of DevEx is the product marketing side. A developer will first hear of Mux from a blog post, a social network, a link on Hacker News or from a conference. If our product marketing and branding are on point, then when that developer needs video, they will remember that Mux does video and they’ll start poking around our documentation and the “developer experience” is now well under way.
We expect a developer at this point to be researching and vetting Mux, engaging with blog posts, looking up documentation, and asking questions to other developers in their network. At this point a developer is quickly trying to figure out if Mux is going to solve their video needs.
Each step of the way this developer is forming an opinion and a judgement about:
- How legit is this company?
- If I build with these APIs, can I count on them to be really good at what they say they do?
Their entire opinion about Mux up until this point is based on what other developers have told them, and what they have read or seen. All of this falls under the umbrella of developer experience.
At this point the developer’s biggest risk is that they spend precious time creating API keys, writing code, and starting to integrate with a product that does not live up to the promise. You may think developers like writing code, but a dirty secret is that developers HATE writing code. Developers are goal oriented and the best want to write as little code as possible to get the job done in an elegant and efficient way.
You can think of this with the popular “jobs to be done” framework. A developer has a job, and they are hiring Mux to do it. If Mux does that job well, then Mux is hired. For an API product, the job starts when a developer installs SDKs and starts making API requests. If this part goes well, you likely have a customer for life. If this part goes poorly, it will be hard to win them back.
Up until this point a developer has interacted with documentation, looked at example code, Googled for answers, and made API requests. Every single one of those steps the developer has interacted with is covered by the DevEx team. For a large portion of customers, the “sale” ends here. It is closed and done, and we have a new customer all because of a good developer experience.
For larger companies and enterprise customers, there will still be a traditional sales process where the sales team engages, conversations are had, and contracts are signed. But, unlike traditional software sales, the Mux sales process is delayed until the prospect has already used the Mux APIs, read documentation, and started integrating Mux into their workflow. The part that we call “developer experience” has already influenced much of the decision making.
We believe that developers are increasingly becoming the center of power in an organization. They are more and more becoming the the people that we need to convince in order to win.
Day in the life
Let’s take a little bit of a closer look at what a day in the life of a DevEx Engineer looks like at Mux.
The other day I shipped a big PR for adding TypeScript support to our node sdk. A few weeks ago I got to hack around with cool new tools like NextJS and build an open source example project that handles video uploads. We sponsor developer conferences and that gives me the opportunity to run a workshop with Phil teaching people how to build their own live streaming app. Sometimes I write guest blog posts on other partners’ blogs or build integrations like the Mux app for Contentful.
For context, Mux is not a huge company. Last year when I joined we were about 25 people and now we’re roughly 50. The core DevEx team is about 5 right now, and we are ready to grow our team aggressively this year.
Come join us
We are looking to expand the team of developers on the DevEx team as our goals and ambitions over the next couple years far exceed what we have done up until now. We are looking for developers who have fun hacking on example projects, are open to writing content and want to join the team at Mux that backs every developer interaction with the product. Being a DevEx Engineer requires a balance of pure engineering, plus a desire to interact and talk with people externally.
If this sounds like you please reach out to me directly, I would love to talk to you.
