Calibrate Before You Accelerate: Bias Toward Action in a New Role

Another time we got bought, merged into a new company, their CTO was our new CTO. In one of the initial meetings said "things won't change much" and, naturally, we didn't believe. She moved slow on all the things, methodical. Spent some time with each component team. It was months before we started making changes to better mesh with the new company. Very little chaos. Still admire that management style.

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

— https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...

Related: https://news.ycombinator.com/item?id=38653711

CMM says that an engineering team whose processes aren't written down is level 0, and writing them down, even if they are batshit, gets you to level 1. Which leads to a fun bit of catharsis with the older employees where they get to say things like, "and then a miracle occurs".

Also writing things down gives someone else a peek into what's going on in your head and they can correct bad assumptions you have before they get cemented and take more effort to dig out of your thought processes.

So I always start with fixing the documentation, the runbooks, the CI process. It's a deliverable you can engage in without breaking production, it demonstrates mastery, it fixes a pain point that the more professionally mature members of the team care about, which gets you brownie points with the right sort of people. And it makes it easier to onboard the next person, or pick back up a project that has been on the back burner for several quarters.

TODOs emerge from the documentation or get explained away as unnecessary or wontfix. By the time you're touching something you have a better idea of why things are like they are, so you make up for 'lost' time.

It’s critical to start showing some Phase 3 impact, even if not with a sledgehammer, before peers quickly loose faith

Making the ultimate visibility tool isn't just helpful to me as a newcomer. It may be useful to many veterans and people who haven't had the time to make this tool for themselves.

But I'm also somewhat biased towards laziness/observation.