If you’re a savvy engineer or engineering manager at a company with a growing team (or just a growing codebase), chances are good that you’re already part of conversations happening about the developer experience of writing software at your company. There may even be conversations happening about whether improving developer experience could improve outcomes for the business overall.
I’ve spent probably too much time debating the merits of “experience” vs. “effectiveness” vs. “success” vs. “productivity” when it comes to “developer [x]”. Every one of these words speaks to a slightly different audience and has slightly different implications. When you’re trying to get your company to invest in developer whatever, you want to be speaking the language of the people in a position to fund your ideas.
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. Buckle up.
When you frame the objective as “developer experience,” you may be unnecessarily raising the difficulty level of achieving your objective. The word “experience” can imply that the outcome of the effort will be engineers having a better experience. In the absence of some business impact, experience does not rate particularly high on a list of company priorities.
And experience isn’t all you care about either, right? Really what we’re talking about here — what you’re trying to get investment in, what you can make a business case for — is maximizing how effective an engineer can be with their finite time, attention, and energy.
There are plenty of things you could work on that would improve the developer experience of your company’s software engineers, from buying everyone the $1,000 mechanical keyboard of their choice (I’m fine though, thanks), to making CI feedback near-instantaneous via parallel execution and magic. The first, maybe, has a retention story you can attach to it; the second is a whole lot easier to tell a whole business story about.
We know that people who can achieve a “flow state” while working on a challenging task are more likely to enjoy working on the task and are more likely to feel a sense of accomplishment upon completing the task, which in turn makes them more likely to seek out (and succeed at) future challenges.
If good things come from “flow,” then your job is to figure out how to maximize it, with effective developers as the eventual outcome. This is distinctly different from thinking in terms of “what will make engineers happy?” and focuses us instead on how to create a state we know leads to happiness — and better business outcomes.
If we look at it this way, we’re pointed in the direction of questions whose answers we can potentially automate, such as:
- How often do developers have to perform time-consuming manual tasks?
- How often are developers waiting for an automated process to complete?
- How often do developers have to ask another person for synchronous help?
- How often is potential flow time interrupted by a meeting?
In fact, there are lots of things to consider that might be negatively impacting flow. I find it really useful to make a mind map to gather and organize these opportunities.
When we get specific about the source of interruptions that prevent flow, we have something more satisfying than satisfaction surveys: metrics that can be measured reliably and consistently, and thus metrics that we can seek to improve. That doesn’t mean you throw out the sat survey; you just accept it as a trailing indicator as you improve the things above. Satisfaction is a measurement you use to validate your work, not something you try to chase week to week.
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 get to something like this, tailored to the specific details and challenges of your engineering organization:
Here are 10 specific things we could improve in a developer’s workflow, mostly a few very frequent tasks that we think we can make an order of magnitude faster.
If we’re successful, we think we can save 5 minutes per engineer per day, or about 40 wasted engineering hours a week across the 100 engineers who use these tools daily.
More importantly, though, we can eliminate 100 instances per engineer-day when an engineer has to wait more than 10 seconds for a tool before they can move on. We’re confident we can get this done with three engineers inside a quarter.
This is your pitch. Developing it will take work, but it’s going to be a lot more effective than sharing some generic research and ending your presentation with “trust me, it’ll be good.” You’ll have taken something squishy and qualitative and sentimental — experience — and reframed it as tangible, measurable value to the business.
You’re offering, effectively, to buy the 101st engineer for free, in exchange for 9 engineer-months of work, deliverable in a quarter. You’re also ensuring that the 101st engineer will never experience this pain ever, and the first 100 engineers will never experience it again: the impact of this work will only increase over time, until there’s some fundamental change in the system.
This pitch buys you the room to prove that your approach is a valid and impactful one; if you prove that, further well-reasoned investment will be a lot easier to come by.
If this is your first time pitching an investment to engineering leadership, it can be disorienting, but you’ll be OK. Just remember:
- Connect your pitch with tangible business value, not abstract research.
- Get specific with outcomes, impact, and initial timeline/headcount.
- Take a principled approach, informed by research, when deciding what to work on.
- Effective investment compounds over time, even if headcount stays stable.
Every company is going to have a different answer to “what gets in the way of flow?” — never mind how to measure it and improve it. Once you’ve identified sources of painful interruption, the next step will depend a lot on what’s on the list.