Why a DevEx Manifesto?
First a small disclaimer: DevEx is a broad term that may refer to many topics and capabilities, more than what is in scope here.
In my time working on platform engineering and developer experience (DevEx), I’ve realized something important: we need a solid set of principles for measuring developer productivity and enhancing the overall developer experience. It’s become clear to me that:
Measuring developer productivity across teams requires high levels of trust and transparency.
That’s what led me to create the DevEx Manifesto. It’s a way to bring these values front and center in our industry.
A bit of history…
My journey to creating the DevEx Manifesto started with countless conversations with some really sharp minds in IT - leaders, managers, developers, and those driving change. We all share a common goal: To boost developer productivity and the overall experience of developers.
A lot of these discussions circled back to how improving developer productivity isn’t just a nice-to-have, but it’s key for hitting broader business or organizational goals. Think about cutting down lead times or reducing the costs of running software.
To hit these targets, I noticed a pattern: they were all leaning heavily on metrics to track progress and measure the impact of their initiatives. This could be a leader trying to figure out the real impact of a DevOps transformation or an enablement team using these metrics to steer their efforts in making life easier for developers across different teams.
But whether it’s a leader or a team, the big question that keeps popping up is:
How do we measure developer productivity?
I’ve seen a lot of leaders get jazzed up after reading “Accelerate” or checking out the State of DevOps reports. It’s like they’ve found the holy grail in the DORA metrics, which are often seen as the go-to indicators for performance. Let’s take a quick look at what these metrics are:
- Deployment Frequency - How often an organization successfully releases to production
- Lead Time for Changes - The time it takes from making a commit to getting it to production
- Change Failure Rate - The percentage of deployments causing a failure in production
- Time to Restore Service - How long it takes to recover from a failure in production
Now, these metrics are solid, I’m not advocating against them. They’re valuable and can tell you a lot, but only if you use them right. I’ve seen too many cases where these metrics just lead teams down the wrong path. Why’s that? Because they’re not being used thoughtfully or with a healthy dose of curiosity with what they’ll provide.
There are newer, more holistic ways to look at developer productivity, like the SPACE framework or the DX framework. But here’s the thing - is picking a framework or a set of metrics really the best place to start?
The Pitfall of Metrics-First Approach
Here’s the catch with starting with metrics – like focusing solely on Deployment Frequency. We often forget to ask some crucial questions: What’s our end goal here? Why are we measuring this in the first place? And what are we going to do with the data? Laura Tacho, CTO at DX, hits the nail on the head with this question:
What decisions will these metrics help us make?
If we skip this question at the beginning, we’re basically just fishing for data. We grab numbers and then scramble to build a story around them. But that’s backward, right? It misses the whole context of our organization, our teams, and the people in them.
And there’s a real danger when we use these metrics nakedly to directly compare teams or individuals. It breeds a kind of unhealthy competition. It’s like saying, “Hey, let’s see who can jump the highest,” without caring why we’re jumping in the first place. This erodes trust big time. Teams start gaming the system, focusing on looking good according to the metrics instead of making their day-to-day work better.
Metrics can always be gamed pretty easily if they start feeling like a threat.
So, whether you’re going for a numbers-driven approach, a more qualitative one, or a mix of both, the key is to ground your approach in solid values and principles. It’s kind of like the Agile Manifesto – you start with the core principles and values, and then you pick the methods that align with your organization’s goals, abilities, and situation.
Unveiling The DevEx Manifesto
So, what exactly is the DevEx Manifesto? Well, it’s more than just a list. It’s a collection of principles and values that are critical to measuring developer productivity in a way that’s fair and meaningful.
I’ve put together something like this, and it’s really about setting a clear and transparent foundation for how we approach this whole thing:
By embracing these principles, we’re not just agreeing to a set of rules. We’re making a commitment. It’s about holding ourselves to a standard that shapes our progress and becomes the benchmark for our achievements. More importantly, it’s a promise to every developer who plays a part in this – a pledge that we’re dedicated to upholding these values consistently.
If the DevEx Manifesto strikes a chord with you and you’re thinking of adopting it, or even just parts of it that fit your needs, here are a couple of tips:
- Make sure to communicate the principles and values broadly, both to your teams and stakeholders.
- Have leaders explicitly sign off on them. The higher, the better.
Together, these two points creates a good starting point for holding ourselves accountable and responsible. But remember, it’s the ongoing commitment to these values and principles that really builds and maintains trust.
Please contribute 🙏
Now, I didn’t get to brainstorm with top minds in the Wasatch mountains of Utah like the Agile Manifesto folks did. But hey, it’s the era of GitHub – who needs mountains when you’ve got the cloud, right?
The DevEx Manifesto isn’t just a bunch of ideas on paper; it’s a living, breathing set of values and principles. It’s meant to evolve, to grow with our understanding, which is why I’m keeping it versioned.
I’ve got this hope, maybe a bit naive, but a hope nonetheless. That the DevEx Manifesto will turn into something driven by our community. It’s only as strong and meaningful as the contributions and insights we all bring to it, and how we put it into practice.
As our grasp of developer experience deepens, so will the Manifesto. That’s why I’m all for collaboration and input. Got an idea? A suggestion? Jump onto GitHub and let’s make it better together. Open an issue or a Pull Request – every bit of input is a step towards shaping a manifesto that truly reflects our collective wisdom and experience.