On the Rise of Developer Experience (DevEx)

On the Rise of Developer Experience (DevEx)

On the Rise of Developer Experience (DevEx)

Jesse Adametz, Director of Engineering, Infrastructure from Twilio Segment

Jesse Adametz, Director of Engineering, Infrastructure from Twilio Segment

Jesse Adametz, Director of Engineering, Infrastructure from Twilio Segment

author image

Yena Oh

Yena Oh

GTM

GTM

Sep 2, 2024

Sep 2, 2024

5 min

5 min

With over 20 years of experience in platform, reliability, and infrastructure, Jesse Adametz is a seasoned expert in navigating the ever-evolving developer landscape. As one of Tempest’s key advisors, Jesse brings deep expertise in building and scaling effective engineering teams and offers invaluable insights into driving performance and efficiency across organizations.

In this conversation, he shares with us why the move towards developer experience (DevEx) has become crucial for mature engineering teams, explores the challenges and opportunities that come with this shift, and offers advice on how businesses can successfully navigate these changes to enhance team performance and outcomes.

We’ve seen significant growth in the DevEx space, with many organizations focusing on expanding their platform and developer enablement teams. How does this recent emphasis on DevEx differ from traditional support or DevOps practices?

As with most new things, I think there’s a learning curve around these topics. After a handful of buzzworthy years around DevOps, the understanding that it’s a practice and not someone’s job, is now better understood. Research done by organizations like DORA, who seek to understand the “capabilities that drive software delivery and operations performance,” is now more mainstream, causing a broader group of readers to wonder how they can achieve “elite” levels. And more mature organizations that have completed their “digital transformations” are now looking for “what’s next” in things like the SPACE framework.

So, the emphasis we see is the understanding that: it’s not about running a Jenkins server or making developers deploy their code instead of Operations. It’s about continuous feedback loops in practices like Continuous Integration and folks understanding how their application runs in production.

But that comes with more burden and expectation on Software Engineers than ever. And that burden is where teams are getting introduced to alleviate or abstract away complexity with Developer Platforms. Where a traditional Operations team may write and follow a deploy run book, a DevEx-enabled organization would codify the run book. Reduce the risk of human error. Make deploys fast to deliver value to their customers, letting their Engineers get on to the next most exciting task. This makes teams happy. And happy teams do great work.

How have you seen this shift in focus impact businesses and the bottom line?

From my experience, my answer is completely qualitative; I think the impact is hugely positive and helps to reduce costs. I commend leaders and teams who are ultimately able to quantify the impact of their DevEx efforts, it’s not easy. The impact felt by improving Developer Experience is a pretty large surface area.

Teams often start with the 4 key DORA metrics (i.e. frequency of deployments, lead time to change, change failure rate, and mean time to recovery). Those alone might give an organization insight. But it’s more: it’s employee happiness, retention rate, quality and speed of onboarding new teammates, and so on.

I actually think DORA’s “Core Model” and their terminology around capabilities and outcome are the right way to talk about this.

DORA core model diagram

Image Source

Capabilities such as a climate for learning, fast flow, and fast feedback predict increased software delivery and reliability which in turn predicts increased organizational performance and well-being.

DevEx is a focus on the human side of the business. You have to believe in and trust the process.

In your opinion, what makes a strong DevEx strategy?

I think this answer is different per organization. Throughout my journey, I’ve focused on different pieces based on the size, priorities, and even scope of the business.

I’ve worked at companies where the technical aspects of the infrastructure weren’t important for the Engineer to concern themselves with. So in those cases, we abstracted it away entirely and our migration to Kubernetes was transparent from a day-to-day perspective.

In comparison, the current product I work on is essentially an extension of our customer’s infrastructure. Our Engineers are required to know more about distributed systems, reliability, and the orchestration of both our hardware and software. So in this case, our primary focus is on guard-rails and measurability of the infrastructure / platform. The resulting outcome is actually a deliberate reduction in choice for Engineers, which yields a better developer experience, allowing them to focus on developing software and delivering customer value.

I do think this is a bit of a Venn diagram though. There are commonalities in any strategy where I would refer back to and follow the previously mentioned guidance on capabilities that predict high performance. DevEx teams want to focus on what gives teams missing feedback loops. Practically, things like CI, CD, observability, and tooling.

Significant investments in new approaches tend to carry risks. Do you think shifting strategies exposes businesses or engineering teams to risks? Any advice on mitigating them?

I think it’s smart to let the emergence of a DevEx focus happen naturally in an organization. Sure, if a leader is particularly seasoned at the beginning, they might have an Engineer or two working on things in this area. But like any good product development strategy, if a team is focusing on Developer Enablement too early, they’ll lack feedback from their customers (i.e. other Engineers) and likely fail to build the right things.

Tactically, I think investing in developer experience before establishing a team could look a few ways:

  • Allocate a percentage of engineering investment toward improvements

  • Provide teams with data about their developer experience

  • Assign dedicated internal champions for specific areas

Once dedicated investment is proposed though - and this will look different for different organizations - industry research has shown that organizations are settling in around a 19% (or ~1:6 “DevProd team members to total engineers”) allocation.

Are there any other emerging trends in the infrastructure and platform space that you believe will have a significant impact in the coming years? What do you think the future holds for this space?

Developer Portals are all the rage right now - and it’s not just a feeling! The CNCF’s 2023 annual report showed that Backstage had 4,188 contributions from end user members. That was almost 7x higher than the next project, Prometheus.

What I’m hoping to see next are ways to make IDPs have a significantly lower time to value. A recent example I was blown away by was The New York Time’s experience building their IDP with CNOE. They were able to, without a dedicated team, launch their IDP that now serves over 1,000 developers! That’s the kind of value I’ve been chasing from IDPs, and I want others to experience it without spending the resources that so many other teams have.

I believe Tempest has a significant role to play here :)

Ready to supercharge your team’s developer experience? Sign up for early access to Tempest today and see how our platform can transform your engineering workflows.

Build a world-class developer platform.

Build a world-class developer platform.

Book a demo and get free beta access to Tempest.

Book a demo and get free beta access to Tempest.

Book a Demo