Working as a DevRel for a DevTools company, I sometimes find myself advocating not just for our users/our company, I often do advocacy strategy for our users toward their leadership because they need to convince their org on why they're buying in.
It's hard if their non-technical leadership cares about only MRR and ARR numbers (which is most of them).
Wait, some teams don't run tests?
Whether we're on Reddit, Tech Twitter, or DailyDev, we share (or pretend to share) an understanding of striving for cleanly written, well-tested, and well-maintained code bases.
The reality, however, is that many engineering orgs struggle to do the basics.
I've heard something similar to this several times:
We don't need to keep tests from failing in main. Some individuals on my team don't even believe in writing tests. I don't think they'll buy into a merge queue.
Or something like:
Our non-technical leadership doesn't like it when we spend time working on code or tools that don't impact revenue. Linting and formatting falls into this category.
Or even:
100% test coverage is not necessary, some parts of the code is so simple, I don't need to test it to know if it works.
These people will often make it to engineering leadership in an org for being pragmatic. EW...
But "I" know better!
Now we know better. We know that full test coverage helps us make changes faster and more confidently because we have guardrails that prevent us from breaking other people's code. We know that untested code is code that doesn't work. We know we need linted and formatted code so everyone can focus on problem-solving instead of arguing about how many tabs to use. We know that linters can help catch anti-patterns that can impact security and performance.
I know that you know better. How do you ensure that leadership understands why these things are important?
And no, saying that they're incompetent and engineers should lead your org isn't a valid answer, most of the time.
How to sell to non-engineers
Our concerns about DevEx, code quality, testing, and well-architected code are all valid. Where it goes wrong is how we sell this to leadership.
The problem is that we're too abstract in how we sell it.
We often focus on saying this is the standard, this is better practice, or this is what other top engineers do. This is abstract. Engineers take these "standard practices" as truth because someone else (and maybe even you!) has felt the pain hundreds of times and learned to avoid it. Your non-technical leadership and even some technical leaders who haven't wet their toes in years will not relate easily.
Instead, this is what you need to focus on. This is the story you need to tell.
Focus on impact
Poor testing has a cost. If you change code and there's insufficient testing to ensure you won't break someone else's code, it will resurface unexpectedly during development/code review or in production.
If your code base has poor coverage, this has probably already happened. Collect these anecdotes, or create them by doing some mocks. Create some innocent-looking code change that will have an unexpected impact to use as an example.
Same with code quality and linters/formatters. If you can't find stories, commit a change with tabs instead of spaces, 4 wide tabs instead of 2 wide, add your line breaks in the wrong places, argue with your coworkers for a few hours, and save the email exchange or Slack thread.
Quantify the impact
How much does it cost to break the main? How much does it cost to argue about code quality? How much does it cost to take down your production application?
Remember how much you and your teammates' time cost? What we often fail to illustrate is how fucking expensive it is for a dev team to argue about where the { should go or how an innocent-looking change is breaking tests in main.
While your leadership won't understand pain, they understand developer_hours == $$$. Now you have your anecdotes, make a chart of how much it costs to manually retest things every code review, or argue about code format.
For example:
- Every PR has an 80% chance of containing a formatting issue; 4 engineers argue for an hour 20% of the time.
- Every PR has a 20% chance of breaking something unexpectedly; 50% of the time, it's caught, but it costs 2 engineers 4 hours on average to find the issue. The other 50% of the time it takes down prod for an hour.
- We put in 10 PRs per week.
- Engineers make $75 an hour.
Now do the math... Actually I feel lazy, here's what ChatGPT says.
Here's Claude:
Wow they disagree, but regardless, that's a big number, probably easily 10-20x the cost of a tool, and in a year, enough money to justify hiring an intern to do nothing but address these issues.
Restricting scope
Now, pitch your fix. How much time, what tools, how long, and what's the ROI. Focus on 1 high-impact issue that has a clear scope. Focus on how long you think it will take and what you get back. You're looking to achieve ~10X ROI in a year for a pitch that they can't resist (and it's not hard).
Time to practice
This stuff takes practice and is often the differentiator between staff engineer/tech leads and your run-of-the-mill dev. You should try these tricks if you're not yet a staff engineer/tech lead. It shows initiative and has 0 risk for you (because it's not your job anyway).
A word from our sponsor
Trunk makes several dev tools that you can use to refine and practice your pitch:
- Formatting and linting in big repos
- Prevent conflicting changes from breaking main at scale
- Find and fix your flaky tests
If you'd like to get some advice on how to write your pitch, chat with us on Slack.
Top comments (0)