Skip to main content
Leading Through Uncertainty — Anselm Fowel
Leadership

Leading Through Uncertainty

11 min read
682 views
Share:

Every leader claims to thrive under pressure, but uncertainty is a different beast than pressure. Pressure has a shape: a deadline, a launch, an audit you can prepare for. Uncertainty is the absence of shape. It is the regulatory consultation that might land in six weeks or might land in eighteen months, the funding round that is verbally committed but not signed, the key engineer who has gone quiet, the competitor who might be building the same thing you are. In fintech, where the cost of being wrong is measured in fines, frozen accounts, and lost trust, learning to lead through that fog is not a soft skill. It is the job.

Leading Through Uncertainty
Leading Through Uncertainty

I have spent most of my career as a CTO in regulated payments and lending, and the lessons that have served me best are not the ones about technology. They are about how to keep a team moving, deciding, and shipping when nobody, including me, knows what is coming next. What follows is not a framework I invented in a strategy offsite. It is a set of habits I have arrived at the hard way, usually after getting them wrong first.

Naming the Fog Honestly

The first instinct of most leaders facing uncertainty is to project confidence they do not have. I understand the impulse. You believe the team needs to feel steady, so you smooth over the unknowns and present a clean narrative. The problem is that engineers are pattern-matchers by trade. They notice when the story is too clean, when the roadmap assumes a regulatory outcome that has not been decided, when the timeline depends on a partnership that is still a handshake. False confidence does not reassure them; it teaches them not to trust your read on the situation.

I have found it far more durable to name the fog out loud. In a recent quarter we were waiting on a national regulator to clarify how a new open banking rule would apply to our payment initiation flow. The honest position was that we did not know, and that the answer could meaningfully change our architecture. So I said exactly that to the engineering org, telling them which parts of the plan were solid ground and which were provisional. Nobody panicked. If anything, the candor bought me credibility I drew on later when I did need them to trust a call.

Naming uncertainty is not the same as wallowing in it. The skill is to be precise about what you do not know, because precision converts a vague dread into a finite list of open questions. A finite list can be worked.

Treating Decisions as Reversible Bets

When the future is unknowable, the worst thing you can do is wait for certainty before deciding. Certainty rarely arrives on your schedule, and the cost of paralysis compounds quietly. The reframe that changed how I lead was to stop thinking of decisions as final pronouncements and start thinking of them as bets with different reversibility profiles.

Some decisions are cheap to reverse: which feature flag controls a rollout, which queue technology we trial in a non-critical path, which vendor we pilot with a small slice of traffic. For those, speed beats deliberation, and I push the team to decide fast and learn faster. Other decisions are expensive or impossible to walk back: the core ledger data model, the choice of regulated entity through which we passport into a new market, the cryptographic approach to storing card data. For those, I slow down, demand more evidence, and accept the cost of moving carefully.

The discipline is not deciding everything quickly or everything slowly. It is correctly judging which kind of decision is in front of you, and refusing to apply the wrong speed to it.

What this does for a team under uncertainty is profound. It gives them permission to act on the reversible majority of decisions without escalating, while reserving the organization's caution for the few choices that genuinely warrant it. It replaces a culture of waiting for the boss with a culture of calibrated motion.

Building Information Velocity

Uncertainty is partly an information problem. The faster accurate information moves through your organization, the smaller the fog gets. I have come to treat information velocity as an engineering target in its own right, something to be measured and improved like latency or uptime.

Concretely, this means investing in the unglamorous plumbing that lets the truth surface quickly. We instrument our systems so that when something degrades, the relevant engineer knows within minutes, not when a customer complains. We run incident reviews that are genuinely blameless, because a team that fears punishment will hide the very signals you need most when things are unclear. And we keep the distance between the people closest to the data and the people making decisions as short as possible.

The leaders who struggle most in uncertain periods are usually the ones who have, often unintentionally, built systems that filter bad news on its way up. By the time the problem reaches them, it has been softened three times. Early and accurate beats late and comfortable every single time in this industry.

Holding a Stable Core

If everything is in flux, a team burns out. People can tolerate a great deal of ambiguity at the edges as long as something at the center holds still. Part of leading through uncertainty is deliberately deciding what will not change, and then protecting it.

For my teams, the stable core is rarely the roadmap, because the roadmap is exactly the thing that uncertainty forces us to revise. Instead, the stable core is our operating principles and our standards. We do not ship anything that touches customer money without a tested rollback path. We do not compromise on the audit trail. We treat security review as a gate, not a suggestion. These commitments do not move when the market does, and that constancy is a source of calm.

There is a paradox worth sitting with here. The more volatile the external environment, the more rigorously I defend the internal constants. When a partner relationship collapsed mid-integration and we had to rebuild a settlement flow on short notice, the thing that kept the team from spiraling was that our engineering standards did not flex under the pressure. We moved fast, but we moved fast inside a set of rules everyone already trusted.

Enjoying this article?

Get more like it in your inbox — practical engineering leadership, fintech, and AI. No spam, unsubscribe anytime.

Finding the Smallest Honest Next Step

When the path forward is genuinely unclear, I have learned to stop asking for the plan and start asking for the next honest step. A full plan requires assumptions about a future you cannot see. A next step requires only that you know enough to move one increment and learn something real.

This is where uncertainty and good engineering practice converge beautifully. The same instincts that make us build in thin vertical slices, ship behind flags, and validate with small cohorts are exactly the instincts that serve a team in fog. You do not need to know the whole route. You need to know the next defensible move and what it will teach you.

  • What is the smallest thing we can build that proves or disproves our riskiest assumption?
  • If this turns out to be wrong, how much have we spent, and can we undo it?
  • What will we know after this step that we do not know now?
  • Who needs to be told what we learned, and how fast can they hear it?

Asking these questions habitually turns an intimidating, foggy quarter into a sequence of legible moves. The team stops staring at the horizon they cannot see and starts walking the ground in front of them, which is the only ground anyone can ever walk.

Managing the Emotional Weather

I used to think emotional steadiness was a personality trait some leaders had and others did not. I now think it is a discipline, and a load-bearing one. In uncertain times, a team unconsciously reads its leader's affect for signal. If I walk into a standup visibly rattled, that anxiety propagates faster than any memo I could write. People will spend the day managing their unease instead of solving the problem.

This does not mean performing a false calm. I described earlier why false confidence corrodes trust, and the same applies to manufactured serenity. What it means is doing my own processing off the main stage. I have a small circle of peers and a coach with whom I can be genuinely uncertain, frustrated, or afraid. I bring the unresolved version of myself to them, and I bring the composed, honest version of myself to the team. That is not deception. It is the same separation a surgeon maintains between their private nerves and the steadiness their hands require.

The payoff is that when I do show concern in front of the team, it carries weight precisely because it is rare and proportionate. Steadiness is a reservoir. You draw it down in a crisis, and you have to refill it deliberately, because no one else is going to do that for you.

Distributing Judgment, Not Just Tasks

A single leader cannot personally navigate every uncertain decision in a growing organization, and trying to is a guarantee of becoming the bottleneck. The deeper work of leading through uncertainty is distributing the capacity for good judgment so that the people closest to each problem can make sound calls without you.

This is harder than delegating tasks. Delegating a task means handing off something with a known answer. Distributing judgment means equipping people to decide well when the answer is not known, which requires them to understand not just what you would decide but why. I spend a disproportionate amount of my time explaining the reasoning behind decisions, the tradeoffs I weighed, the constraints that mattered, the principles that broke the tie. I am, in effect, trying to install my decision-making in other people so the organization can think under uncertainty in parallel.

When it works, you can feel it. A regulatory question lands, and instead of a queue forming at my door, a senior engineer and a compliance partner have already framed the options, weighed the reversibility, and brought me a recommendation rather than a problem. That is not luck. It is the compounding return on having explained myself patiently for a long time.

Separating Signal from Noise

Uncertain periods generate an enormous volume of noise: rumors, hot takes, half-confirmed news, the competitor announcement that may or may not mean anything. A leader who reacts to every tremor will whipsaw the team into exhaustion and teach them to distrust every directive, because half of them get reversed within a week.

I try to maintain a deliberately slow loop for strategy and a fast loop for operations, and to keep them separate. Operationally, we respond quickly to real, verified signals: a degraded dependency, a spike in failed settlements, a genuine security disclosure. Strategically, I resist changing direction on anything that has not been confirmed through more than one credible channel. A single headline does not move our roadmap. A confirmed regulatory ruling does. The art is in the filtering, and the cost of getting it wrong is a team that no longer believes today's priorities will survive until tomorrow.

One practical habit: when a new piece of alarming information arrives, I ask whether it changes a decision I am actually about to make. Surprisingly often, the honest answer is no. It is interesting, even worrying, but it does not alter the next step. Naming that explicitly keeps the team from spending energy on developments that feel urgent but are not actionable.

Anselm Fowel, CTO and fintech architect
Anselm Fowel — CTO & fintech architect

Conclusion

Leading through uncertainty is not about predicting the future or pretending you can. It is about building an organization that can keep deciding, learning, and shipping while the future stays stubbornly unclear. That means naming what you do not know, treating decisions as bets calibrated to their reversibility, moving information fast, holding a stable core of standards, taking honest next steps, managing your own emotional weather, distributing judgment widely, and filtering signal from noise. None of it is glamorous, and none of it makes the fog go away. What it does is let your team walk through the fog with their footing intact. In regulated fintech, where the stakes are real and the consequences of panic are severe, that steadiness under genuine uncertainty is, in the end, the most valuable thing a technology leader can offer.

Enjoyed this article? Share it with others!

Share:

Get new posts in your inbox

Occasional, practical notes on engineering leadership, fintech, and building with AI. No spam, unsubscribe anytime.

Comments (9)

Leave a Comment

Comments are moderated and will appear after review.

Adwoa Amankwah

September 13, 2026

Small addition: this only holds when the manager themselves has been coached this way. Copy-pasting the technique without the underlying model tends to fall flat.

Ebere Nwoke

August 30, 2026

Refreshing to read this framed for our market rather than lifted from a Silicon Valley playbook. Specifically the "Naming the Fog Honestly" piece — CBN write it into the audit questions, and that changes the design constraints in ways the US-centric literature never touches.

Ademola Ogunleye

August 28, 2026

Does the "Managing the Emotional Weather" still hold on a 351-service estate? We're at the smaller end of that and some of these patterns feel like they need a dedicated ops person to run properly.

Emeka Okonkwo

August 24, 2026

Broadly agree, but the "Holding a Stable Core" advice assumes a level of psychological safety most teams do not have yet. In a first-time manager situation the sequencing has to change.

Kwabena Agyeman

August 19, 2026

Would add: this stops working the moment the promotion committee stops trusting the manager. That trust has to be earned upstream first.

Kojo Darko

August 2, 2026

Does the "Managing the Emotional Weather" still hold on a 315-service estate? We're at the awkward middle and some of these patterns feel like they need a dedicated ops person to run properly.

Zainab Ibrahim

August 2, 2026

Question on "Finding the Smallest Honest Next Step" — how do you actually apply this when calibration season is two weeks away? Struggling with that specific case on my codebase right now.

Chidi Nwoke

August 2, 2026

Refreshing to read this framed for our market rather than lifted from a Silicon Valley playbook. Specifically the "Holding a Stable Core" piece — the licence guys have opinions, and that changes the design constraints in ways the US-centric literature never touches.

Charlotte Sinclair

August 1, 2026

Independent consultant, 4 due-diligence engagements a year across UK/EU fintechs. Reading this after a rough sprint — the "Holding a Stable Core" bit lands, because I spent this week navigating monolith-to-services trap on my engagements. Honestly the framing would have saved me at least a promo conversation.

About the author

Anselm Fowel

Anselm Fowel

Chief Technology Officer & fintech architect. 16+ years leading engineering across AlliancePay, Mondu, Transalliance, Global Accelerex, and Fidelity Bank — writing here about engineering leadership, fintech architecture, and AI in production.

Read next