Nobody told me what to do on that first migration. They just expected it to happen. No direct reports, no budget, no formal mandate. Just a mess of legacy systems and a vague mandate from leadership. I had to convince three different teams to change their deployment pipelines, and none of them worked for me.
The mistake I made early on was leading with the architecture. I walked into the first meeting with a full diagram, color-coded, showing exactly how everything should connect. The room went quiet. Not the good kind of quiet. One senior engineer asked who put me in charge. Fair question. I had no good answer.
What worked instead was showing up with problems, not solutions. I started by asking each team what hurt most in their current process. The database team was drowning in manual failover drills. The frontend team had a staging environment that broke every Thursday. The platform team was fielding the same support tickets every sprint. I wrote all of it down and shared it back. No diagrams. No proposals. Just a list of pain points that everyone recognized as real.
That list became the foundation. When I eventually suggested changes, I could tie each one back to something someone had told me they hated. The database team adopted automated failover because they had told me the manual process was burning them out. Not because I had a slide deck proving it was technically superior.
Another lesson that took too long to learn: deliver something small before asking for anything big. I spent weeks trying to get approval for a cross-team observability standard. Got nowhere. Then I instrumented one service on my own time, showed the team lead the dashboard, and asked if she wanted the same thing for her services. She did. She told her manager. Suddenly the standard had a champion who actually had authority.
The hardest part was accepting that influence moves at the speed of trust, not the speed of good ideas. I had a technically perfect proposal for consolidating our message queues that died in a meeting because I had not built enough relationships with the teams who would be affected. The same idea, presented six months later by an engineer who had spent that time pairing with those teams, got approved in one session.
Technical credibility matters, but it is not enough. You need to be the person who remembers what someone said three months ago and follows up on it. You need to be the person who admits when an approach is not working and pivots without ego. You need to be the person who makes other people look good, not the person who needs to be right.
I still do not have a title that matches the scope of what I influence. That used to bother me. Now I realize the work speaks for itself, and the relationships I built doing it are worth more than any org chart placement. Authority is given. Influence is earned. The earning never stops.