Developer Friction
Once upon a time I started at a certain tech company. In the first week, I was like wow the build takes 45 minutes? And everyone was like of course it does why would it take any less time than that ya dolt? The next day my build was projected to complete in 6 hours because it used a merge queue and was behind 7 other builds. Everyone were like yes obviously, that makes sense. Felt like I was taking crazy pills for being the only person who thought this was absurd. I thought they were playing a prank on me. The story of how I made it my mission to fix it is less important than the takeaway - Resist the cultural normalization of dysfunction - when inefficiency or pain points become so routine that everyone stops questioning them. I was the outsider seeing clearly that the existing process was absurd, but the team had been conditioned to accept it as “just how things are.” Don’t let familiarity make you complacent. If something feels broken, it probably is.
Developer friction like this just naturally grows. Nobody starts out thinking the end state would be good or acceptable. There’s always some great reason for each new CI step that only marginally slows things down and sends reasonably on its own. But it becomes death by a thousand slow cuts until shipping a one line change
Fighting it
To fight against it takes:
-
At least 1-2 existing team members with an extremely low tolerance for BS plus a high level of agency and competence on unwinding the slowness/friction.
-
Outside new hires who haven’t slowly gotten used to the pain being unafraid of speaking up or acting.
-
Eng Leadership recognizing the problem and encouraging DevEx investments.
Eng leaders: keep writing code
A good way for Eng Leadership to best understand for themselves is to not stop writing code.
If you can’t get any small coding project done when time-limited to a half a day a week, probably the DevEx friction is too high.
Working on small pieces at a time of reducing dev friction is the perfect type of coding task for an Eng Manager because it’s bite-sized, not critical path, and unblocking / multiplying for the rest of the team.
If you can, take a management sabbatical and go deep on IC work for a period of time. I did this over the summer and better realized how much CI and other friction had built up in our system, and it became one of my main focus areas to improve.
For the last couple weeks I've been on a “Management Sabbatical” – working full-time, but on none of my typical leadership/management work. Instead: exploring ideas, AI coding agents, and shipping code again.
Phil Freo · June 24, 2025I also wrote about why Eng Managers should write some code back in 2020: Should Engineering Managers Write Code?
This was originally posted on X in November 2025.