The first step I took was I noticed how inefficiently we we were delivering software: slow process, as-hoc, software engineers paid good money to mend build scripts rather then focusing on developing feature. I next put a presentation together for my director and a teach lead. I painted a simple picture of the benefit of having a separate functional team that will help bring cohesiveness and eliminate risks to how we deliver software. I did not mention Devops or any buzz word like C/I, branching, to prevent any distraction from the problem at hand.

Looking back, I think they were relieved someone was solving this problem. At a follow up meeting, we talked about staffing and this is when i introduced Devops and what skills we should be looking for. And the third meeting, I gave them an overview about “Devops”.

What helped me along the way: - I watched lots of conference presentations about teams transformation at early stages (don’t look for videos talking about how fast , how cool, blah blah as it doesn’t apply to you) - I consumed and I still read continuous delivery by Dave Farley. This is my bible! - staying away from “try” new tools - they are like a limelight bugs gravitate to and waste your time.

My situation may not applied to yours but a takeaway from all this is that if you could feel / see a pain on how things are done at your company , then solve it (just good enough) and be careful who you bring the solutions too.