Every engineer, engineering manager, and engineering leader has ideas for how to make their work more efficient, more enjoyable, and more effective for the business. But getting support from non-engineering stakeholders — in terms of time and people — isn’t always straightforward.
While engineers and technical leaders intuitively understand the value of reducing build times, improving pull request processes, or eliminating CI failures, these technically sound goals may fail to resonate with business stakeholders who control funding.
This disconnect creates a frustrating cycle:
The problems persist and compound, leading to increasing frustration among engineering teams, diminishing trust from stakeholders, and ultimately, customer dissatisfaction.
In this article, I’ll break down how to reframe developer productivity initiatives in ways that win over business stakeholders, helping you secure the resources your team needs while creating lasting improvements that benefit everyone.
The terminology we use matters.
When you frame the objective as “developer experience,” you may be unnecessarily raising the difficulty level of achieving your objective.
The word “experience” might imply that the outcome will simply be engineers having a better time, which doesn’t rate particularly high on a list of company priorities without a clear business impact.
What we’re truly discussing is maximizing how effective an engineer can be with their finite time, attention, and energy. In other words, you’re selling engineering effectiveness.
If your objective is to increase the effectiveness of engineers by improving their experience, you can’t assume the connection between the two is obvious, even if it’s obvious to you. Pitching this kind of work — the kind of work that will lead to happier, more successful, more productive engineers who rave about their experience — is a strategic endeavor.
So while there are many things that could improve developer experience — from premium equipment to near-instantaneous CI feedback — those with a clear business impact are much easier to advocate for.
When we get specific about the sources of interruptions that prevent flow, we can identify metrics that can be measured reliably and consistently. These might include:
By focusing on these concrete interruptions rather than abstract satisfaction measures, we can develop targeted improvements that deliver measurable value.
Developer experience surveys remain valuable as trailing indicators to validate your work, but they shouldn’t be the primary metrics you chase.
Better engineering directly impacts your ability to deliver value to customers. To gain support for developer productivity work, you need to be able to translate technical improvements into business benefits that matter to different teams:
Your sales team needs to be able to confidently promise delivery dates to close deals. By standardizing reviews and limiting work in progress, teams can deliver 90% of features within two weeks of promised dates, giving sales the predictability they need to succeed.
Fast problem resolution builds customer trust. When debugging is difficult and deployments are risky, fixes take days instead of hours. Better observability and automated processes help your team solve critical issues quickly, leading to happier customers and lower churn rates.
Automated testing and deployment directly address the reliability concerns that matter at the executive level. Your product becomes stable enough to meet enterprise SLAs without forcing impossible tradeoffs between infrastructure and features. In the end, everyone wins: you’re able to secure larger contracts and have an even higher quality product for your existing customer base.
If you want to advocate for investment in this kind of improvement, your next step is to identify problem statements/user stories, evaluate effort vs impact for solving each of them, choose a few worth focusing on, baseline current reality, hypothesize solutions, and solicit investment to experiment and iterate.
Congratulations, you’re now a product manager, and your product is effectiveness. Now you need to gather some data from your users: the engineers themselves.
At a smaller company, you might have a shared “friction log” for your team, where you can note anything annoying you ran into, and then discuss it at your team’s retro and highlight items worth attention. There are lots of ways to gather this info, manual and automated, and with various frequency/fidelity.
Get creative, or don’t, but do the easiest thing you can try for your first pass at this, even if it’s just making your own best guess of problem areas.
Your goal is to create a compelling pitch along these lines:
Here are specific things we could improve in a developer’s workflow. If we’re successful, we can save X minutes per engineer per day, or about Y wasted engineering hours a week across our team. More importantly, we can eliminate Z instances per engineer-day when someone has to wait more than 10 seconds for a tool before they can move on. We’re confident we can accomplish this with three engineers inside a quarter.
This approach transforms something qualitative and sentimental (developer experience) into tangible, measurable value to the business.
You’re effectively offering to buy another engineer for free, in exchange for a defined investment. And unlike hiring a new engineer, the impact of this work compounds over time, benefiting both current and future team members.
To create lasting productivity improvements that maintain stakeholder support:
Research shows that people who achieve a “flow state” while working on challenging tasks are more likely to enjoy their work and feel a sense of accomplishment. This, in turn, makes them more likely to seek out and succeed at future challenges.
So if good things come from “flow”, then your job is to figure out how to maximize it – with effective developers as the eventual outcome. Once you’ve identified the sources of painful interruptions in your organization, the next steps will depend on your specific context.
What remains universal is the need to connect technical excellence with business impact — they reinforce each other when properly aligned.
By approaching engineering effectiveness improvements with this mindset, you can secure the resources needed to create meaningful change that benefits both engineers and the business as a whole.
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
