Faster Customer Delivery

Not all companies value developer productivity projects equally. Framing is often difficult to make sure stakeholders truly grasp their impact. I used to find myself explaining over and over how "refactoring X" would make the team more productive. It was a pretty fun experience, honestly, showing the CEO how much effort it took to add "a simple feature" she requested. There was a moment of "ooooh" that I'll never forget as her eyes widened. She finally saw the pain I had to go through now so I could go fast 6 months prior. From then on, any time I would need to move quickly, she would acknowledge that there was a price to be paid. Still, I minimized that price as much as possible.

Where I am now (MongoDB) everyone is tech-savvy so the back-and-forth is minimal. The discussion becomes more about how pressing the next feature is for the customer, understanding that I'm negotiating time allocation now to eventually "get it back" later. No empty promises though, which would otherwise damage trust. This is true for my immediate team but what about my boss's boss, and their boss, and their boss? How can I justify engineering investment up the management ladder so it doesn't look like I'm wasting time on projects that don't translate into profits?

Here's what I learned along the way since I became a manager that I would recommend to you as a starting point. The work starts before planning for the quarter. Having a vague idea of how a developer productivity project can benefit the product will not play in your favor (or anyone's favor). There are two ways this can and should be framed to stakeholders.

The first one can be measured. You can estimate (for example) time wasted waiting for your CI/CD pipeline to tell you your changes are safe. You can also expose all the downstream effects of it (TimeToResolution in case of a critical bug). These numbers are your bridge to faster customer delivery. The second one is a hidden cost that helps as supporting evidence. Bad developer experience can drive talent away. You risk to lose not only good teammates but also their domain knowledge. On top of that, you'll have to hire and go through the aches and pains of that too. I label this as hidden because it's not evident to other stakeholders and it's more challenging to justify with numbers or metrics. Add this as an "addendum", but not necessarily the driving force behind a project as it will make it harder to sell.

Here's how to execute:

• Draft a proposal where you identify and quantify the measurable costs. Collect evidence for hidden costs to strengthen your case.
• Loop in your manager if you haven't already. Their buy-in is crucial.
• If you're the manager, support and help your team ensure measurable costs demonstrate faster customer delivery. Hidden costs should stay as an addendum.
• If, even after framing it correctly, it doesn't make a strong case, archive and move on.
• If it makes for a good case, put it on the plan and negotiate for it.
• Once the project is completed, follow up 30-60-90 days later. Show how the measurable costs validate your initial thesis. This will help build trust.
• Rinse and repeat.