Why “by developers, for developers” matters

Philosophically, we believe our customers are the innovators. We stand behind the amazing things they’re building and are proud to play a role in their successes. We reflect this sentiment in one of our core company values, focus on the customer. But inside Fastly, you may also hear a different phrase: “by developers, for developers.” 

Our customers’ ability to build innovative online experiences on our platform depends upon the team of Fastly engineers — working across applications, infrastructure, network, data, internet standards, security, and sales — who love helping to solve the hard problems our customers face. We give our developers what seem like impossible challenges, and they find groundbreaking solutions. This ethos has kept us close to our customers’ problems, attracted companies who also believe in empowering their developers, and deeply entrenched us in the global developer community as a whole. 

Now more than ever, it’s important to talk about how we’re maintaining our ethos of a by-developers-for-developers culture. We’ve all seen that COVID-19 raised the stakes: entire industries have had to speed up digital transformation at unprecedented rates. Almost 90% of companies believe their industries will be digitally disrupted — but less than half have a plan to address it. The way to solve it begins with your developers — and companies that operate with a dev-first mindset at their center will have the strategic advantage, now and into the future.

Developer empathy is non-negotiable for CEOs.

As the CEO, I’m honored to be in service to our employees and our customers. When I accepted my new role in February, I was very conscientious of how I could support the “by developers, for developers” ethos we had built over the last nine years — particularly as someone without a background as a developer. I’ve quickly realized that this doesn’t start with learning to code. It starts with a relentless commitment to listening and learning. 

Fastly works on complex problems. But understanding the challenges our customers are facing, and the ways in which our technology solves it, helps me create common ground with our technical leaders and teams. With that as a starting point, I can cultivate a more empathetic view and understand what our engineering teams need in order to make our customers successful. It may not have mattered quite as much if I understood what my developers said and did 10 years ago. But now that we know developers are critical to innovating ahead of our customers’ demands, it’s imperative that I can help tradeoff discussions at the highest strategic level, and bring our developers’ point of view into how I guide our roadmap. 

Here are some of the fundamental things our developers have taught me about our customers: 

We must prioritize the way developers want to work 
From the early days, our founders knew that a critical advantage we had was the ability to genuinely empathize with the people we were building products for. That’s because they were the people building and using the products. Artur, Jason, Simon, and Tyler created Fastly to solve their own problems as customers: things like better visibility, performance that wouldn’t sacrifice security, and the ability to work with the tools they already used and loved. In other words, we started with the mindset of “I’m building this for myself,” which is an incredibly powerful perspective. Developers build our platform, and developers build on our platform — so we'll always care deeply and understand intuitively what our audience values.

We know we’re just one part of a bigger, massively important ecosystem of developer tooling. It’s one reason we function like an extension of our customers’ current stack, giving developers as many choices as possible around what tools they want to use: whether that’s through integrations and partnerships, or new ways to support multi-CDN, we encourage companies to break free of legacies and let developers use the best tools for the job. 

We must continuously earn the partnership
We know that core to being a developer is the freedom to solve problems with the right solutions for the task — not the one you’re locked into because of a multi-year contract. That’s why we subscribe to a usage-based model, designed to grow with you. In other words, we have to earn their business, every day, by offering the best possible solutions to their challenges. 

Modern architecture is complex, so we have to build beyond ourselves
It’s also why we focus on standards of the internet so much: online experiences shape our worlds, and we believe in making the web a more trustworthy place. You can see that shine through in partnerships with Bytecode Alliance and our Open Source and Nonprofit Program, as well as decisions around how we build our products. 

Sean Leach’s recent post on our serverless compute environment, Compute@Edge, is a good example of this. Rather than use an off-the-shelf technology like V8, which could have supported the popular language JavaScript from the get-go, we knew from our customers that the power and flexibility offered in other solutions doesn’t go as far as developers want it to. As CEO, I had to believe my engineering org and our customers that there was a better way to solve this problem — and create the space for our teams to address it. So before building our own custom compiler toolchain from the ground up — an ambitious feat — we had to invest outward in the community. The teams continue to contribute massive amounts of open-source code to AssemblyScript, WebAssembly, Rust, and more so that Compute@Edge will be a more powerful, secure, and functional tool for developers. 

The path forward lies with developers.

When our solutions engineers or product managers are in a room (or more recently, a Zoom call) and they’re whiteboarding alongside a customer, their challenges are our challenges. We immediately see the problems they’re trying to solve and are invested in solving it alongside them. Our customers often wind up being our friends, and we tackle challenges together. We don’t always get it right, but by utilizing “by developers, for developers” as a north star, we seek to build authentic experiences, solve real problems, and connect with the broader community.

Wherever a company may be in their journey, the model of dev-centricity will steer their ship toward greater competitiveness in the market. One of the most important questions businesses can continuously ask is, “What can our developers teach us about our customers?” The companies that champion developers today are the ones that will launch the next groundbreaking innovation — the kind that defines businesses and changes the way we all experience the web.