A common mistake of many first-time CTOs or VP of Engineerings:

Mandating that all engineering teams in their organization start working {the same way using methodology X}.

They usually feel this is a big win for them, and the company. In reality: it's almost always a disaster.

Real-world examples:

“All teams will run 1-week sprints and report whether weekly goals were hit or not.”

“We are mandating Scrum with 2-week sprints, reporting on velocity.”

Leadership pats themselves in the back. Teams and engineers grumble, some do more BS work, some leave.

This approach only helps poorly run teams - to some extent. Well-run teams typically play along with the process theatre, but try to keep their old way of working. If they can.

If they cannot: their output + motivation drops. The VPE won’t notice as they are focused on optics.

A solid observation by @enzsombor on how these top-down changes are often driven by believing poor outcomes must be due to poor processes.

Another common reason for this the CTO/VPE wanting show tangible changes they make that improve results. Too bad these “results” are optics.

The same way “no one is fired for buying IBM”, it’s true that “no one is fired for introducing Scrum/SAFe”.

But better engineers/managers sure do leave because of it: to places where team autonomy is a given.

Take away autonomy: you’ll never have a world-class engineering team.