At Red Canary, I founded the Developer Tools team. The pitch wasn’t complicated: our deploy took 35 minutes. Every engineer hit that wall multiple times a day. Multiply 35 minutes by the number of deploys, by the number of engineers, by the number of working days, and you’re looking at a staggering amount of wasted time. We got it down to 3 minutes.
That single change bent the curve on how much everyone else could ship. Not because we built a new feature. Because we removed a pebble that every engineer was stepping over, all day, every day.
Pebbles compound into mountains#
Developer experience problems are sneaky because no single one feels urgent. A slow test suite. A flaky CI pipeline. An editor that doesn’t syntax-highlight your templates correctly. A local dev environment that takes 45 minutes to set up from scratch. Each one is a minor annoyance. Each one gets shrugged off as “not a priority.”
But the math is brutal. Let’s say a slow test suite costs each engineer 10 minutes a day in waiting. That’s nothing, right? On a team of 50 engineers, that’s over 8 hours of lost productivity. Every single day. Over a year, you’ve lost more than a full-time engineer’s output to a problem nobody prioritized because it was “just” 10 minutes.
Now stack the pebbles. Slow tests. Slow deploys. Flaky CI. Manual environment setup. Missing documentation. A config file that breaks every time someone updates a dependency. Each one is 5 or 10 minutes. Together, they’re the reason your team feels slow even though every individual engineer is working hard.
This is a leadership problem, not a tooling problem. Engineers won’t fix it because each individual pebble isn’t worth stopping feature work for. Only someone with a view across the entire team can see the compounding effect and make the call to invest in it.
What DX investment actually looks like#
When I say “invest in developer experience,” I don’t mean hire a platform team and wait six months for results. I mean start with the friction your team hits every day and fix it deliberately.
Here’s what it looked like in practice:
Slow deploys → automated pipeline optimization. At Red Canary, the 35-minute deploy wasn’t one big bottleneck. It was a chain of small ones: redundant build steps, unparallelized tests, an artifact upload that waited on a queue. We broke the pipeline apart, parallelized what we could, and eliminated what we didn’t need. 35 minutes to 3. No new infrastructure, just attention.
Slow tests → smarter defaults. Password hashing is a classic example. Libraries like argon2 and bcrypt are intentionally slow in production because that’s the whole point of password hashing. But in test, you don’t need cryptographic strength. Two lines of config:
# config/test.exs
config :argon2_elixir, t_cost: 1, m_cost: 8That took a 2.1-second test suite down to 0.2 seconds on one of my projects. Multiply that by every test run, every engineer, every day. Two lines of config. Nobody prioritized it because it was “just” a couple seconds.
Missing editor support → better syntax highlighting. When Phoenix LiveView introduced the ~L sigil, Emacs had no idea how to highlight the HTML inside it. Same thing when HEEx templates landed. Each time, I wrote the config to get proper syntax highlighting working, because engineers who can’t read their code easily make more mistakes and move slower. These are small investments that pay off across every file, every day.
The pattern is the same every time: find the thing everyone tolerates, measure the compound cost, and fix it. The fix is almost always smaller than people expect.
Why leaders have to own this#
Engineers will work around bad tooling indefinitely. They’ll memorize the workaround for the flaky test. They’ll open a second terminal to watch the deploy. They’ll copy-paste the editor config from a coworker’s dotfiles. Humans are remarkably good at adapting to friction, which is exactly why friction persists.
A leader’s job is to see the friction that individuals have normalized. You’re the one with visibility across the whole team. You can see that the same 10-minute workaround is happening 50 times a day. You can make the case that spending a week on tooling saves a month of cumulative output. You can prioritize it against feature work because you understand the compounding math.
Fixing a pebble can turn into a mountain if enough people are hitting it. It adds up. And a broken developer experience means your ability to see everyone reach their peak is impossible.
The best engineering leaders I’ve worked with treat developer experience the same way they treat production reliability. Not as a nice-to-have. Not as something you invest in “when things slow down.” As a first-class concern that directly impacts the team’s ability to ship.
Your team’s ceiling isn’t set by your best engineer. It’s set by the friction everyone else has to push through every day. Remove the friction, and the whole team gets faster without anyone working harder.