The Bug Was the System
We fixed the tools. We cleaned up the code. But something still felt off. Everyone was doing their job, but velocity kept slipping. I couldn’t shake the feeling that what we were fixing wasn’t the thing that was broken.
I started consulting for a multi-product company that wanted to fix their release processes. Backend delays, redundant work, last-minute patches, force updates for apps they were shipping, but it felt like every release cost twice as much effort as it should.
The ask was simple: help streamline the tech and improve dev velocity. Within the first few weeks, I started introducing small changes - structured deploy windows, better branching strategy, biweekly retros, simple checklists before production pushes. The developers responded well. Some even told me, "We've been wanting to do this for months."
But every time something started working, one of the co-founders would step in. Not with hostility - more like creative edits. "We like this, but let's just do the checklist informally." Or, "Do we really need a release window? We're flexible here."
It wasn't deliberate resistance. Just gentle pushback, ideas being softened, adjusted, or adapted back into familiar patterns. Good systems being partially adopted, watered down, or reshaped to fit old habits.
I didn't push back. Not immediately. I was here to help, not to fight. I assumed - maybe wrongly - that we'd get there eventually.
Developers were optimizing for code clarity and process stability, while product teams were chasing shipping goals. These weren't wrong priorities - just segregated ones, with no bridge in between. Velocity was suffering in the gap.
Three months in, things looked better. Developers were happier. Deploys were a little smoother. But the big goal - consistent release velocity - wasn't improving.
At one point, in a dev meeting, someone said, "We're doing all the right things, but stuff still slows down."
That's when I realized:
The bug wasn't in the code. The bug was the system.
We had talented developers.
We had better tools.
We had decent visibility.
But the underlying decision structure hadn't changed. Priorities still shifted mid-sprint. People still bypassed process in the name of "speed." And nobody had authority to say no to co-founder changes.
Velocity comes from consistency. And consistency needs trust, boundaries, and shared rules.
So I intervened.
In the next dev meet, I laid it out clearly: the team was doing great. But every time the structure bent for one request, it sent a signal - the system is optional.
And if the system is optional, there is no system.
To their credit, the co-founders listened. We sat down. Reset expectations. Drew a clear line between flexibility and chaos.
A few weeks later, velocity actually improved. Not because we added a tool or made a dashboard. But because the team finally knew the process had teeth.
That's what I learned consulting this company:
Sometimes you don't need to refactor the code. You need to refactor how decisions are made.
The bug was the system. And we finally fixed it.
