From risk analyst to delivery lead — what actually changed

The question

In January 2026 I stopped being a Senior Risk Analyst at Santander Consumer Bank Nordics and started as Delivery Lead on the technology side. Colleagues asked, almost immediately, whether I was "leaving data behind." I wasn't. The job changed who I write for, and what counts as a finished piece of work.

Same bank, different unit of work

For a few years the unit of work was a model, a scorecard, a forecast, or a dashboard someone could argue with in a steering meeting. As Senior Risk Analyst (Sep 2023–Jan 2026) that meant PD models, scorecards, ECL-style forecasts, portfolio steering, and a lot of Python, SQL, and Power BI / Fabric. Before that I had already spent time as a Risk Analyst in the same bank, and earlier as a Credit Analyst at Resurs Bank on scorecards, cut-offs, and credit-engine changes in Provenir.

Delivery Lead flips the artifact. The unit of work is now a sequenced change across Azure application operations and middleware: who owns which dependency, and what "done" means when platform, security, and business calendars disagree. After it ships you still need a way to tell whether it held. I still open metrics, only now they sit next to incident patterns and dependency maps instead of a model monitoring pack.

Evidence stayed; the room changed

I still refuse decisions that rest on vibes. Operational metrics plus a written view of what could break in production are the same instinct that made me distrust a pretty chart with a soft grain. Risk work trained that distrust on portfolios and engines. Application operations spends it on services that other teams touch while you sleep.

What changed is the vocabulary of the room. Engineers and operators do not share a glossary with every stakeholder, and pretending otherwise just slows the handoff. My job is less "run the SQL" and more "make sure the right change is specified and reviewed before it ships," including the boring parts: status that names blockers, plus a rollback story before anyone calls the change green.

Some days I still itch to disappear into a notebook. That itch is useful as a warning. If I'm the only person who understands the numbers behind a delivery call, I haven't finished the work; I've just moved the opacity from a model into a meeting.

What risk actually prepared me for

People treat "analyst to delivery" as a soft-skills story. Mine wasn't. Credit risk is decisions under incomplete information on a clock, with regulators and Nordic stakeholders in the loop, plus a need to measure whether the call aged well. You rarely get a clean dataset and a quiet week. You get a cut you can defend and an honest list of what the model is not.

Azure application operations rewards the same muscle. You rarely have a perfect picture of every dependency, yet you still need a call with a rollback path and a way to check whether the change worked. Mentoring junior analysts taught me something adjacent: capability compounds when the system is legible enough that someone else can run the next cycle without you narrating it.

I'm not claiming the domains are identical. A PD monitoring pack and a middleware incident pattern are different objects. The transferable part is narrower and more useful: treat uncertainty as a design input, not as a reason to stall.

What I'm still figuring out in public

Orbit is part of the shift. It is a public record of what I build and learn on the engineering and automation side while delivery is the day job. I keep the CV and Hub honest about both lanes: quantitative roots in credit risk, and current work leading IT application operations on Azure.

I don't have a tidy conversion story where every old habit mapped cleanly onto the new role. Some habits translated on day one. Some still fight me: wanting to build the analysis myself when the team needs a sequenced plan more than another chart; wanting perfect information when the safer move is a reversible call with owners named.

Takeaway

If you're weighing a similar move from analytics into operations leadership, don't start by asking whether you'll "still do data." Ask whether you can make the system legible enough that someone else can run the next cycle: evidence before the call, and a definition of done that survives without you narrating it. That through-line survived the title change. The notebook didn't have to.