Stepping into a CTO role at a fintech company is not like any other engineering job I have held, and I have held a few. The stakes are simply different. A bug in a content site is an inconvenience that someone refreshes away. A bug in a payment rail is a salary that did not arrive on the 25th, a supplier in another country who is now questioning the relationship, a regulator who suddenly wants a conversation you are not ready to have. The first 90 days in this seat set the tone for everything that follows, so I treat them with a deliberateness that has sometimes frustrated people who wanted me to move faster.
This is the field guide I wish someone had handed me the first time. It is not a checklist of features to ship. It is a sequence of postures to adopt, in order, so that by the end of the first quarter you have earned the right to lead the system rather than merely the title that says you do.
Weeks 1 to 2: listen before you touch anything
The temptation when you arrive is to start fixing. You were hired because you are capable, you can already see three things that look wrong, and every instinct says prove it. Resist that instinct. In my first two weeks I do almost no shipping. Instead I sit with every team, read the entire incident history going back at least a year, and trace a single real payment end to end through the system with an engineer narrating each hop.
I want to understand how money actually moves before I have any opinion about how it should move. The gap between the architecture diagram on the wall and the path a real transaction takes is where most of the truth of an organization lives. In every conversation I ask the same three questions and write down the answers verbatim:
- What breaks most often, and who gets the 2am call when it does?
- What are we afraid to change because nobody fully understands it anymore?
- If you had two extra engineers for a month, where would you point them and why?
The patterns in those answers tell you more about the real state of the system than any documentation. The thing everyone is quietly afraid of is almost always your biggest risk, and the place everyone wants to point two engineers is almost always where the organization already knows it is bleeding.
Weeks 3 to 6: find the load-bearing walls
Every system has load-bearing walls, the services that, if they fall, take the business down with them. In a payments company that is usually the ledger, the reconciliation pipeline, and whatever sits between you and your banking partners. I map these explicitly and grade each one on a brutally simple scale: do we understand it, do we monitor it, and can we recover it if it fails right now.
If you cannot answer "what happens to in-flight money when this service crashes mid-transaction?" you do not yet understand your own system, no matter how confident the diagram looks.
Most teams discover during this exercise that at least one load-bearing wall scores poorly on all three questions. That service becomes your north star for the rest of the quarter. Not a rewrite, just relentless attention until it is understood, observable, and recoverable.
This is also the stretch where I deliberately invest in relationships outside engineering, particularly with compliance and finance. In fintech, engineering does not get to operate in a vacuum, and the leaders who treat compliance as an obstacle rather than a partner pay for that attitude in audits and fines. The earlier those relationships form, the fewer surprises arrive later disguised as emergencies.
Weeks 7 to 12: ship one visible, low-risk win
By the second half of the quarter the team needs to see that the new CTO can deliver, not just diagnose. Diagnosis without delivery curdles into the impression of a critic who arrived to grade everyone's homework. So I look for a change that is genuinely useful, low in blast radius, and visible to the whole company.
Improved transaction monitoring is a favorite. A faster, more trustworthy reconciliation report is another. Taking a service that pages people every week and making it boring is the kind of win that engineers feel in their sleep schedule and remember. The point is never the feature itself. The point is to prove, with a real artifact, that we can change this system safely and that the path I have been laying out actually works in practice.
What I deliberately do not do
The first 90 days are defined as much by restraint as by action. I do not announce a grand rewrite, because I do not yet understand the system well enough to know what should survive it. I do not reorganize the team in month one, because I have not yet seen who quietly holds the place together. And I do not promise the board a roadmap I cannot defend, because the fastest way to lose credibility in this role is to be wrong in writing to the people who hired you.
Credibility here is earned in small, reliable increments. The regulated nature of fintech punishes the leader who moves fast for the sake of looking decisive, and it rewards, slowly but durably, the one who builds a reputation for being right.
Reading the people system, not just the tech system
Underneath the technical system there is a human one, and it has its own load-bearing walls. There is usually one engineer who is the unofficial historian, one who is burning out quietly while holding a critical service together, and one whose influence far exceeds their title. In the first quarter I am mapping this just as carefully as I map the architecture, because the org chart almost never tells the truth about how decisions really get made.
I do not act on this map early. I just build it, accurately, so that when the time comes to reorganize or to delegate real authority, I am working from reality rather than from the boxes someone drew before I arrived.
Conclusion: earn the right to lead it
Ninety days is enough time to understand the terrain and to earn the right to lead it. It is not enough time to remake it, and pretending otherwise is the single most common way new technical leaders fail. They mistake the mandate for the understanding, swing hard in month one, and spend the next year recovering trust they spent before they had earned it.
Go slow at the start so you can go fast for years. Listen until you have heard the same truth from three different people. Find the walls holding the building up. Ship one thing that proves you can. And keep the grand plans in your notebook until the quarter has taught you which of them were actually right.