After more than 20 years as a senior individual contributor and technical lead, I'm moving into my first DevOps management role at a new banking organization. I won't know anyone initially, and I'll be managing a team of about 10 people. I'll also be the most senior DevOps manager and engineer in the Platform Engineering group, so I'll have both technical and managerial authority. What would you recommend focusing on during the first day, first week, and first month?
4 Answers
Start by listening rather than proving how much you know. Introduce yourself, explain your background briefly, and make it clear that you want to understand the team before changing anything. Meet everyone individually during the first week and ask what they own, what is painful, what works well, what they have stopped trying to fix, and where they want to grow. Also learn who people rely on for different technical areas; the informal leaders may not match the org chart.
The biggest transition is accepting that being the most experienced engineer does not mean you should be the person with every answer. Your role is to set direction, remove obstacles, create guardrails, and help the team make good decisions. Delegate outcomes rather than prescribing implementation, and avoid becoming the bottleneck who fixes everything because it is faster. If someone makes a reasonable decision you would not have made, let them own it and use questions to understand or guide them.
Success starts to look different in management. Instead of your own technical output being the measure, it becomes the team’s growth, autonomy, reliability, and ability to succeed without you doing the work for them.
For the first month, focus on trust and context rather than dramatic changes. Learn the organization’s goals, banking and compliance constraints, decision-making boundaries, budgets, and expectations from your manager. Ask what success should look like after 30, 60, and 90 days. Build a clear picture of responsibilities and ownership, perhaps with a simple responsibility matrix. Then choose one visible, low-risk problem that the team already agrees is worth solving and help them deliver it. A small completed improvement will build more credibility than a large strategy presentation.
Give yourself time. Existing processes often look irrational until you understand the history, dependencies, or controls behind them. Learn why first, then improve things incrementally with the team.
Be an advocate and a firewall for the team. Push back on unreasonable deadlines, unnecessary overnight work, and requests that create avoidable risk, while being honest with leadership about trade-offs. At the same time, lead by example through candor, reliability, and willingness to help during genuinely difficult incidents. Create an environment where people can disagree, report mistakes early, and take ownership without fear. Your technical background is useful for earning credibility, but your long-term value will come from helping other people do their best work.
That gap between what leadership thinks is wrong and what the engineers experience can be surprisingly large. Treat management’s assumptions as hypotheses and verify them yourself.