Growing your influence as a developer acceleration team

Jonathan Biddle didn’t initially set out to start a Developer Acceleration group – his original intention was to solve the problem of making python at Wayfair accessible, low effort, and high output. 

The initiative wasn’t viewed at the time as something that could grow into a dedicated function focused on driving developer productivity across all of engineering, but it grew into that anyway. It did so because Jonathan’s team repeatedly exceeded expectations, growing the team’s scope with each success over time. 

“Eventually we rebranded to Developer Acceleration and started to go after anything that could unlock developer productivity,” Jonathan says. “Ultimately, today we help the business get more returns on its engineering investments.”

In this interview, Jonathan describes the concepts his team has applied that have helped them repeatedly find success and grow their scope over time. 

Identify early adopters

Early adopters are the type of customers that are willing to use an early version of your product and give feedback. Internal-facing teams can leverage the concept of the adoption curve to know where to focus first: find the early adopters. 

Consider the adoption curve for the first iPhone. Early adopters were willing to spend a high price even with a bunch of absent features. Those are the customers you want to find and build for first. 

In early stages of the adoption curve, don’t worry about the people waiting for a more mature product. Build for the innovators, who have three distinguishable characteristics: 

• They have a healthy risk appetite. The innovators want to be the first over the line, and are willing to chance a solution not working for the possibility that it will.
• They have high technical expertise. They will be better able to implement solutions, adjust as needed, and provide knowledgeable feedback.
• They perceive high relative advantage. Solve for the people with problems who will look at your group and say, “This makes my life a lot better.” You can solve for everyone else once the innovators demonstrate the advantage.

Jonathan’s uses the adoption curve concept to consider a product’s Service Addressable Market. “Not every single engineer at a company will be a potential user of the thing you’re building,” he explains. “This describes the users who are legitimately potential users of your thing. The relative advantage is there: if they were using your thing instead of whatever they’re using today, their effectiveness would go up.” 

Jonathan’s approach to building and rolling out a product evolves as it moves through the adoption curve: 

• The first 2.5%: You’re dealing squarely with the innovators. This stage is about surfacing assumptions and answering questions. Does the thing improve ability or reduce friction in some way? How can you start to measure that?
• The first 15%: You might call this the beta stage. You’re trying to stabilize the thing, refine it, and get it ready for general availability.
• After that: You’re in general availability mode, driving adoption of the thing to as much of the SAM as you can get.

Build for your core customers

Your early adopters and “core customers” may overlap, but these are two different concepts. Your core customers fit into a persona you have identified that you are focused on. Core customers might be anyone with a particular role or using a particular tool, for example. 

The key idea here is if you build for everyone at once, you end up diluting the product. Jonathan was introduced to this idea from the book Let My People Go Surfing by Patagonia founder Yvon Chouniard. Patagonia designs products for people doing extreme outdoor activities. They may generate more revenue from people who don’t do extreme outdoor activities – people living in cities, using their bags and jackets to commute. But they still design for their core customers. 

“I’m a good example. I have a Patagonia backpack that I use to take a train to the city. They’re not designing that backpack for me – they’re designing for someone who’s taking that backpack over the Appalachian trail. That bag is getting muddy, dropped – that’s  the person Patagonia has established as their core customer. I just happen to be a happy byproduct of building a good product for that core customer.

“The thing is, if Patagonia started designing backpacks for me, they would not only lose their core customer, but I would become less happy with the product as well. The quality would go down and the reasons I love their backpacks would be gone.” 

Jonathan borrowed that concept at Wayfair and identified senior engineers as the Development Accelerator group’s core customers. The group looks at what those engineers’ needs are, what engineering documentation they require to be effective, and solves for their needs first. This prevents creating safety-scissors versions of solutions that dull their value.

“Cement the idea of the core customers, solve their problems in an uncompromising way,” Jonathan says. “Then figure out how to get other people to make the journey to having the same characteristics as your core customer.” In Jonathan’s situation, a goal of theirs would be to help more engineers become senior engineers.  

Know when to leverage organic or mandated adoption

When rolling out a new tool or change, Jonathan’s team leverages either a mandated or organic approach to getting adoption:  

• Mandated adoption is where adoption is mandated through an entire team or organization. “You lean to centralized diffusion when you have centralized expertise and low levels of uncertainty,” he says. “If you need everyone rowing in the same direction, if consistency is important, this is your choice.” 
• If you can afford to have people adopting things at different times and inconsistencies are okay, you can run with organic adoption. “If uncertainty is high or you have strong decentralized expertise, all of your potential adopters are very smart, capable software engineers (as they often are), then decentralized diffusion becomes a really appealing choice,” he says.

The two adoption styles each have tradeoffs, and both can be situationally correct. Plus, you never have to go completely one way or the other. 

Jonathan tends to lean on organic adoption first. “What you get from organic adoption is higher degrees of innovation, generally stronger local optimums,” he says. “You end up with a better, more effective solution, which people choose to adopt because they see it as so valuable. That’s a great signal back to us that we’re actually solving real problems for them.”

If you get to the point where half the addressable market is using the tool, then begin mandating adoption to close the gap—because it can get expensive to maintain a proliferation of options. 

One notable exception, where it makes sense to solely mandate adoption, is it’s important to achieve 100% adoption quickly. “An example of where we’ve applied this was when we made a decision to migrate our source control provider,” Jonathan explains. “You don’t want to have people confused about where source code is. So once a decision was made, we tried to roll it over to 100% adoption as quickly as we possibly could. It still took a little bit because it was a big migration, but that’s an example of where mandated adoption is really useful.”  

Growing into a dedicated Developer Acceleration team

Most tech companies of decent size are underinvesting in developer productivity space. At the same time, the tech industry is wising up to the investment opportunity that they’ve been neglecting. For Jonathan Biddle, this is an opportunity to leverage these applied lessons into more resources for a Developer Acceleration group.

“Chances are, if you’re on one of these teams, there’s a lot of untapped value just waiting to be realized,” Jonathan says. “Your team could make a strong case for it.”

For more from Jonathan, listen to his interview on the Engineering Enablement podcast or connect with him on LinkedIn.