Everyone tells you the same thing when you get promoted: "It's about people now." Read a leadership book, run better one-on-ones, learn to delegate. That advice isn't wrong, but it misses what actually breaks first.
What breaks first is your relationship with correctness.
As a senior developer working on insurance reserving pipelines or bank reconciliation jobs, you had a simple contract with reality: your code ran at 2 AM, you owned the output, and if something was wrong at 8 AM you fixed it. The feedback loop was tight. The blame surface was small. You could read the SQL and know.
As a manager, that contract dissolves. Your team's decisions run at night now — their joins, their assumptions about a policy_status field, their interpretation of what "active customer" means this quarter. You're still accountable, but you're accountable for judgments you didn't personally make.
That's the real transition. Not people skills. Trust architecture.
What actually changes
Your unit of work shifts from code to decisions. You used to ship pull requests. Now you ship decisions about scope, definitions, and trade-offs — and those decisions get executed by other people days or weeks later, often with mutations you didn't anticipate. A junior analyst hears "exclude cancelled policies" and quietly excludes lapsed ones too because in their previous team that was the convention.
Your debugging surface explodes. A bug is no longer in a function. It's in a handoff between a business stakeholder's verbal request, an analyst's interpretation, a data engineer's implementation, and a dashboard consumer's reading of the result. Four translation layers, each one lossy.
Time horizons stretch and compress at the same time. Strategic decisions you make now show up in incident reports six months later. Meanwhile you're expected to respond to a regulator's question about a specific reconciliation break by end of day. Developers live in sprint time. Managers live in two clocks simultaneously.
Your authority becomes negotiated. As a developer you had authority over the code. As a manager in a Turkish bank or insurer, you have authority over almost nothing unilaterally. Risk wants one definition of exposure. Finance wants another. Actuarial has a third. You don't get to pick — you get to broker.
What doesn't change (and why this matters)
The technical floor doesn't move. If anything, it gets more important.
In regulated financial data, a manager who can't read the pipeline is a manager who can't smell when something is wrong. I've watched managers nod along in incident reviews because they couldn't tell the difference between a legitimate explanation and a confident-sounding fabrication from someone trying to protect their work. The team learns fast who can be bluffed.
The things that stay the same:
- You still need to read the code. Not write it daily, but read it. Spot-check the logic on month-end jobs. Look at the actual SQL behind the regulatory report before you sign off.
- You still need to understand the data domain deeply. What an IBNR reserve actually is. Why FX revaluation timing matters. How a Solvency II or BDDK report ties back to source systems. No framework saves you from this.
- You still need to be the person who says "that number doesn't look right." Pattern recognition on data quality is half the job, and it doesn't transfer from your team to you. You have to keep it sharp yourself.
The reconciliation gap
Here's where new managers get burned: there's a gap between what your code used to guarantee and what your team's decisions actually produce, and you have to actively reconcile it.
A concrete example. You move into a role managing the data team for a mid-size insurer. Your predecessor left a clean-looking architecture: dbt models, documented sources, a decent test suite. Three months in, finance flags that the loss ratio in the monthly board pack has been off by roughly 1.5 points for two quarters. You dig in.
The pipeline runs. The tests pass. The code is fine.
The problem is that nine months ago, a product manager changed how cancellation refunds were booked in the policy admin system, an analyst on your team noticed and "adjusted" a CASE statement to handle it, nobody updated the documentation, and the actuarial team kept using the old definition in their reconciliation. Every layer was internally consistent. The system as a whole was lying.
This is what I mean by trust architecture. Your job is no longer to make the code correct. It's to make sure the assumptions baked into the code, the assumptions held by the people using the output, and the assumptions in the business reality stay in sync. When they drift — and they always drift — you need a way to find out before the regulator does.
What this looks like in practice
A few things I've found that work in the Turkish finance and insurance context, where the regulatory environment is unforgiving and the tooling is often less mature than people assume:
- Force definitions into writing, with owners. Not a wiki nobody reads. A short, versioned document where "active policy" has one definition, one business owner who signs off, and a date. When it changes, it changes visibly.
- Run a monthly "assumption drift" review. Pick three numbers that go to executives or regulators. Trace each one back to source. You'll find at least one surprise every quarter. Better you than the auditor.
- Keep one foot in the code. I still review the SQL on anything that touches statutory reporting. Not because my team can't do it — they can — but because the act of reading it keeps me honest about what we actually know versus what we assume.
- Treat handoffs as the actual product. The number on the dashboard is not the deliverable. The shared understanding between the analyst who built it and the executive reading it is the deliverable. Engineer for that.
The part nobody tells you
The quiet part of this transition is that you'll feel less competent for about a year. You used to close tickets. Now you close almost nothing visible. The work is upstream — preventing the incident that didn't happen, killing the bad project before it started, catching the definition drift before it hit the board pack.
None of that shows up in a commit history.
The developers who make this transition well are the ones who stop measuring themselves by output and start measuring themselves by what their team didn't get wrong. That's a harder metric to live with, but it's the only one that matches the job.