I’ve been at my currently company for almost 20 years. I’ve seen a lot of people come and go, most of them thought they were going to fix everything… none of them did.

The problem is everyone comes in with their own ideas of what things “should” be like, this comes from their past or what they read online last week, not based on the needs of the organization. Have you talked to those 100-200 engineers and listened to what their actual issues are? You could spend a lot of time trying to push them onto k8 where it doesn’t make sense, or when other very basic problems aren’t solve for yet. You could setup all these new things and no one will use them, because they don’t know how, education could be needed, and depending on where they are starting from, you may need to do this it steps. Taking them from crawling to sprinting could take years of realistic steps toward an ultimate goal. If you dump it on them all at once, they’ll just keep doing what they’re doing and wait for you to leave. You don’t know what that goal should be yet, because you just took the job. You may think you know, but you don’t.

I’ll give you a perfect example of this problem in action. I did the math last week and on average, in my years at the company, we change our CMDB every 3.8 years. This usually aligns with a new leader seeing asset management as a problem and decides a new tool is going to fix it. We spent a couple years re-writing everything we have to work with the new CMDB, almost get to a point of stability, and then that person leaves and someone else starts the process all over again. Our problem has never been with the tool, it has always been an issue with the data. It’s still the problem. However, none of the new people who come in ever take the time to listen to the people who work there, so they migrate an existing problem to a new tool, cause thousand of hours of needless work, and solve nothing. They assign someone to own the tool, but no one is ever accountable for the quality of the data. Good luck with automation when the data sucks… the lack of data and standards mean all our code is 10x longer than it needs to be to cover all the edge cases, and new edge cases show up all the time. This is one problem, I can give you a long list of other problems that follow a similar pattern, some are specially done under the umbrella of “developer experience” and all they’ve done is create chaos and confusion among developers who just want to focus on their app.

Don’t start implementing anything until you talk to people, and let their pain points and requirements influence the direction. Actually listen to them, don’t just go through the motions. This process will also build trust with those in the organizing. You’re new, they don’t know you, they have no reason to trust you, and you’re trying to change systems you don’t understand. That’s going to go poorly.

It sounds like step 1 is putting a system together to know who all the employees are and what their roles are. That can be used as a way to get to know who you’re actually dealing with, and can then facilitate the conversations to find out what you’re dealing with. Having visibility into who all the teams are, publicly, can also help facilitate teams talking to each other and breaking down silos.

Also remember, the technology isn’t the product. Your company has something they make and sell, and the customer doesn’t care if it’s on VMs, K8, or any of that. Make sure you don’t load people up with so much stuff that they don’t have time to work on the actual product being sold. The technology should help get things done, not be the blocker that prevents new features from going out the door. Keep the workload and timelines related to the idealistic state realistic and the priorities clear.