"The first thing you should do with the data is find some problem that developers know they have, that you know you can do something about in a short period of

"The first thing you should do with the data is find some problem that developers know they have, that you know you can do something about in a short period of time (like a month or two) and deliver that solution. This doesn’t have to be life-changing or completely alter the way that everybody works. In fact, it really should not do that. Because the point of this change is to make your work credible." This approach has worked well for me in the past. In one of my past roles, I was writing tools to try to improve "quality." One of the main problems we had was the bugs written were hard to reproduce, or had some kind of invalid configuration or incompatible build. It took me a while to figure out that everyone is using host files to point to environments, and different mixes and matches of servers, which were causing lots of problems (but not real bugs). This was taking developer's time (testers couldn't debug the problem), tester's time (waiting for resolution, blocked), and made us think real bugs were not real bugs. In the end the solution was to centralize hosts file management through a tool, where there would be approved configs that could be chosen, and they would be set automatically. Thing caught like wildfire. Super simple technical solution, and that gave me the street cred to make more complex proposals (like a CI system). Be on the lookout for the small gains, and use them to build your cred. Also, if you get your foot in the door technically (like everyone running a tool they know they want), it's easier to add more things to it and keep the momentum going. I do have to point out that there is one type of person missing from the author's "people who will push back", and that is people who have a vested interest in keeping the code base terrible, or designed the way it currently is. Reasons include "we're trying to log all this time against a re-write", "that code is too fragile and risky to change", and anything else the developer might think are idealistically correct, and nothing else will do.