The Project
Managing large teams of highly skilled engineers takes real process. Most of ours traces back to Lean, Agile, SRE, and Kata, and it serves us well. But process isn’t something you install once. Every practice delivers some amount of value, that value drifts as the team and the work change, and part of my job is noticing when a practice has stopped earning its place.
When a practice stops earning its place
Time tracking is the clearest example. When I looked at what ours actually informed, I couldn’t name a single decision. So it went, along with hour-based estimation and the sprint mechanics that ran through me instead of the team. None of that was a judgment on the methodologies. The same evaluation keeps plenty of practices in place, because they clearly earn it.
Autonomy inside real boundaries
What I moved toward was autonomy. Delivery and process improvement sit with team leads and engineers, and changes to how a team works happen as small experiments: try it, watch what happens, keep it or drop it. The boundaries stayed where they belong. I built the CAB processes and change communication that keep a high volume of changes and a rapid release cadence safe for audit and compliance, and I still own them. I also drove our migration from Jenkins to GitHub Actions, which we finished in early 2026, so the compliant path is also the fast one.
Wrap Up
I don’t think of this as removing process. It’s tending it. Practices that protect customers or inform real decisions get kept and improved. Practices that have quietly stopped delivering value get pruned, no matter how standard they are. Teams do their best work when every piece of process around them is there for a reason they can see, and when the people closest to the work own how it evolves.