Supercharging Development Speed

My Deep Dive with a CTO

“What if I told you that we could speed up your deployment by 20x?” I casually remarked during a recent coaching session with a CTO.

In our discussion on boosting development speed, one thing became crystal clear: It's all about net speed. From the creation of a new branch to its merge in production.

The Initial Discovery:

Their deployment process? It was clean, ordinary:

Relying on pull requests for staging, to ensure no breaking changes.

"Why is it important to break staging?" I asked. His answer? Ensuring a smooth sail for other developers.

Diving deeper, I got some interesting data points:

A pull request’s life cycle? About a day.

The frequency of a pull request breaking staging? A mere 10%.

What does this mean? Those 10 pull requests translate into a staggering 10-day wait. All this to sidestep one day of debugging.

"What if you bypassed the peer review?" I said, suggesting a direct merge to staging. The math was simple: A potential 10x speed up.

The QA Conundrum:

Post-staging, the QA team steps in, scanning for any bugs - takes a day, sometimes even more.

Venturing a radical proposition, I said, "Why not let the production be the playground for QA?" On the surface, it might seem reckless, but the logic was sound. If implemented, another day is saved, edging closer to that 20x mark.

His fear? A catastrophic error. My counter? It hadn't happened before.

He loved it. 

Emphasizing the importance of team dialogue, I suggested, "Gather your team and take their feedback. Their perspective might offer insights you hadn't considered."

Conclusion:

In the realm of development, I've realized it's often more time-efficient to fix issues than to erect barriers preventing them. A lesson I hope he took away.

Remember: Sometimes, unconventional methods yield unparalleled results.

#Individuals&Interactions>Processes&Tools

#OptimizationHacks #Fractal.Work #AgileEvolution