The challenge was deceptively simple on paper: take a 20-year-old core banking platform that processed millions of transactions daily and modernize it without a single minute of downtime. In practice, it was the kind of problem that keeps engineering leaders awake at 3 AM.
The Starting Point
Our legacy platform was a monolithic Java application — millions of lines of code, tightly coupled modules, and a deployment process that required a 4-hour maintenance window every quarter. The business was growing, regulatory requirements were tightening, and the platform simply couldn't keep up.
The team was frustrated. Every feature request felt like performing surgery on a running engine. Developers spent more time managing dependencies than writing code.
The Strategy: Strangle, Don't Replace
We adopted the Strangler Fig pattern — gradually routing new functionality to microservices while keeping the monolith running. The key insight was identifying the seams: transaction processing, account management, reporting, and compliance checks each had natural boundaries.
We started with the lowest-risk domain: reporting. A new microservice subscribed to events from the monolith and served read queries independently. No writes, no transactions — just reads. It gave the team confidence in the event-driven architecture without putting critical paths at risk.
Lessons Learned
1. Start with reads, not writes. Read-side decomposition is lower risk and builds team confidence.
2. Invest in contract testing before you need it. Consumer-driven contracts saved us from countless integration failures.
3. Event schema versioning is non-negotiable. We learned this the hard way when a backward-incompatible change took down a downstream service.
4. Celebrate small wins publicly. Each successful migration built organizational momentum for the next one.
The transformation took 18 months. We decomposed 12 bounded contexts, deployed over 40 microservices, and achieved zero-downtime deployments — all while the platform served millions of customers daily.
After two decades of leading engineering teams across Manila, Singapore, and Chicago, I've noticed that the health of any team can be measured by three conversations. Not the technical ones — the human ones.
Conversation 1: "Where Are You Going?"
This is the career growth conversation, and it's the one most managers skip or rush. I'm not talking about the annual review formality. I mean sitting down and genuinely understanding what each engineer wants from their career — not what you think they should want.
Some engineers want to become architects. Others want to lead teams. Some are perfectly happy being deep individual contributors. The conversation matters because you can't help someone reach a destination they haven't defined.
I schedule this conversation within the first 30 days of working with a new team member, and I revisit it every quarter. The goal isn't to have all the answers — it's to ensure no one is drifting.
Conversation 2: "What's Blocking You?"
This is the unblocking conversation, and it requires something many leaders struggle with: humility. You have to be willing to hear that your process is the problem, that the architecture review board you created is now a bottleneck, or that the tech debt you've been deprioritizing is slowing the team to a crawl.
I ask this question in every 1:1, and I've learned to listen without defending. When an engineer tells me something is broken, my job is to fix it — not to explain why it can't be fixed right now.
Conversation 3: "How Are You, Really?"
This is the wellbeing conversation, and it's the most important one. Burnout in engineering is real, and it doesn't announce itself with a dramatic collapse. It shows up as quiet disengagement, declining code review participation, and the slow disappearance of the person who used to light up during technical discussions.
I've made the mistake of ignoring the signs. I won't make it again.
These three conversations aren't a framework or a methodology. They're simply the practice of treating engineers as whole people — not just resources to be allocated.
Leading a team spread across Manila, Singapore, and Chicago means your workday never really ends — but it also means your team never stops moving forward. Here's what I've learned about making distributed engineering work.
The Time Zone Reality
With a 14-hour spread between Manila and Chicago, there's a 2-hour overlap window where everyone is awake. That's it. Two hours. So every synchronous meeting has to earn its place.
Our rule: if it can be an async message, it must be an async message. We reserve synchronous time for three things only: decision-making that requires real-time debate, pair programming sessions, and team bonding.
The Async Playbook
1. Written proposals over slide decks. Every technical decision starts as a written proposal in our shared workspace. The author presents the context, the options, and their recommendation. Team members comment asynchronously over 48 hours.
2. Video updates, not status meetings. Instead of daily standups, team members record 2-minute video updates. You watch them on your own time, at your own speed.
3. Decision logs, not meeting notes. Every decision gets logged with the context, the options considered, the decision made, and the rationale. Future team members can understand *why*, not just *what*.
Cultural Nuance Matters
This is the part most distributed team playbooks miss. Working across the Philippines, Singapore, and the US isn't just about time zones — it's about fundamentally different communication cultures.
In Filipino work culture, there's often a reluctance to disagree openly with a leader. In Singapore, precision and process are deeply valued. In the US, directness and speed are prized. As a leader, I had to create explicit space for disagreement and make it safe for everyone to push back.
The Ritual That Changed Everything
Every Friday, we have a 30-minute "Global Coffee" — no agenda, no work talk, just humans connecting. It's the most important meeting on our calendar.
It's the question that haunts every engineering leader staring at a legacy system: do we refactor our way out, or do we start over? After making this call multiple times in banking environments where getting it wrong means regulatory penalties and lost revenue, here's the framework I use.
The Refactor Path
Refactor when:
- The existing architecture can support the desired end state with reasonable modifications
- The team has deep domain knowledge embedded in the codebase that would be lost in a rewrite
- The system has complex, undocumented business rules that are discovered through production behavior
- You can deliver incremental value while refactoring
The refactor path is slower but safer. You preserve institutional knowledge, maintain production stability, and deliver value continuously.
The Rewrite Path
Rewrite when:
- The fundamental architecture is incompatible with your target state (e.g., synchronous monolith to event-driven microservices)
- The technology stack is end-of-life and no longer supported
- The cost of understanding the existing system exceeds the cost of building a new one
- You have a clear, validated understanding of the domain and can specify requirements precisely
The rewrite path is faster in theory but riskier in practice. The biggest risk isn't technical — it's that you'll discover requirements you didn't know existed only after the old system is gone.
The Decision Matrix
I evaluate five dimensions on a 1-5 scale:
1. Architecture Gap — How far is the current architecture from the target?
2. Knowledge Concentration — How much critical knowledge lives only in the code?
3. Business Risk — What's the cost of getting it wrong?
4. Team Capability — Can the current team execute the chosen path?
5. Time Pressure — How urgently does the business need the outcome?
If Architecture Gap + Knowledge Concentration > 7, lean toward refactor. If Architecture Gap alone is 5, lean toward rewrite. If Business Risk is 5, lean toward refactor unless you can run both systems in parallel.
The Hybrid Approach
In most banking transformations, the answer isn't purely refactor or rewrite — it's both. We identify bounded contexts that can be extracted and rewritten independently while the core is refactored incrementally. It's more complex to manage, but it balances risk and speed.
In banking, compliance isn't optional — it's existential. But the traditional approach of bolting compliance reviews onto the end of the development lifecycle creates a painful choice: ship fast and accumulate risk, or slow down and lose competitive advantage. There's a third way.
The Problem With "Compliance as Gate"
Most banks treat compliance as a gate — a checkpoint that happens after development is "done." This creates several problems:
1. Compliance findings arrive late, when they're most expensive to fix
2. Developers learn to fear compliance reviews instead of integrating them
3. The compliance team becomes a bottleneck, not a partner
4. Risk accumulates silently between review cycles
The Shift-Left Compliance Model
We moved compliance from gate to guardrail. Instead of checking compliance at the end, we embedded it into every stage of the SDLC.
Planning Phase: Every feature proposal includes a compliance impact assessment. Not a separate form — a section of the proposal template. The question isn't "Is this compliant?" but "What compliance domains does this touch?"
Design Phase: Architecture reviews include a compliance architect. Not as an auditor, but as a collaborator. They help design compliance in, not audit it out.
Implementation Phase: Automated compliance checks run in CI/CD pipelines. Static analysis for data handling, dependency scanning for known vulnerabilities, and automated tests for access control rules.
Deployment Phase: Compliance evidence is generated automatically — who approved what, what tests passed, what controls are in place. No manual evidence collection.
The Results
After implementing this model:
- Compliance finding resolution time dropped from weeks to days
- Developer satisfaction with the compliance process increased significantly
- Audit preparation time decreased by 60%
- We shipped faster, not slower, because late-stage compliance surprises disappeared
The Key Insight
Compliance isn't the enemy of velocity — *surprise* compliance findings are. When engineers know the rules upfront and have tools to check compliance continuously, they build compliant systems naturally. The goal isn't to make compliance easier — it's to make compliance *automatic*.
Nobody warns you about the grief.
When I transitioned from individual contributor to engineering leader, I expected the obvious challenges: learning to delegate, managing stakeholders, running meetings. What I didn't expect was the profound identity crisis that came with no longer being the person who wrote the code that saved the day.
The Identity Shift
For 15 years, my professional identity was built on technical competence. I was the person who could debug the production issue nobody else could solve. I was the architect who designed the system that scaled. My value was tangible, measurable, and immediate.
Then I became a manager, and suddenly my output was... what? Meetings? Emails? Feedback? It felt like I was producing nothing.
The truth is, leadership output is real — it's just delayed and indirect. The system your team ships six months from now, the engineer you helped level up, the technical debt you prevented from accumulating — those are your deliverables. But they don't give you the same dopamine hit as merging a pull request.
The Impostor Syndrome
It hit hardest in the first three months. I'd sit in meetings with my former peers, acutely aware that I was no longer the deepest technical expert in the room. I'd second-guess every decision, wondering if I was adding value or just adding process.
Here's what I wish someone had told me: you're not supposed to be the best engineer in the room anymore. Your job is to create the conditions where other engineers do their best work. That's a fundamentally different skill, and you're allowed to be a beginner at it.
The First Real Test
About six months in, a critical production issue hit. My instinct was to jump in and debug it myself — that's what I'd always done. Instead, I called the on-call engineer, gave them context, and asked what they needed from me.
They solved it. Without me writing a single line of code.
That was the moment I understood what leadership actually means. It's not about being indispensable — it's about building a team that doesn't need you to be.
What I'd Tell My Younger Self
The transition from IC to leader isn't a promotion — it's a career change. You're not doing the same job at a higher level. You're doing a completely different job. Give yourself permission to be bad at it at first. The technical skills that got you here are still valuable — they just express themselves differently now.
Everyone wants to say their engineering organization has "adopted AI." But when I ask leaders how they measure that adoption, I get the same answer every time: "We have X developers using Copilot." That's not a metric. That's a license count.
The Vanity Metrics Problem
The most common AI adoption metrics I see are all vanity metrics: number of AI tool licenses, number of AI-related Jira tickets, percentage of teams that have "experimented" with AI. None of these tell you whether AI is actually making your engineering organization better.
I learned this the hard way. After rolling out AI-assisted coding tools across our organization, the license adoption rate hit 85% within three months. We celebrated. Then I looked at the actual data and realized that most engineers had activated the tool but were barely using it — or worse, using it to generate code they didn't understand and couldn't maintain.
The Three Pillars of Meaningful AI Metrics
I now measure AI adoption across three pillars, each with leading and lagging indicators.
Pillar 1: Productivity
Leading indicators:
- AI-assisted commit ratio — What percentage of merged PRs include AI-generated code? Not just AI suggestions accepted, but code that actually ships.
- Time-to-first-draft — How long does it take an engineer to produce an initial implementation with AI assistance versus without? Measure the same task type across similar complexity levels.
- Iteration velocity — After the first draft, how quickly do engineers iterate to production-ready code? AI can speed up the first draft but slow down iteration if the generated code needs heavy revision.
Lagging indicators:
- Cycle time per story point — Track this over quarters, not sprints. AI adoption often creates a temporary dip before improvement.
- Throughput stability — Are teams shipping more consistently, or just in bursts? Sustainable velocity matters more than peak velocity.
Pillar 2: Quality
Leading indicators:
- AI code revision rate — What percentage of AI-generated code is substantially modified before merge? A high revision rate suggests the AI output isn't well-calibrated to your codebase.
- Bug introduction rate in AI-assisted code — Track defect density separately for AI-assisted and non-AI-assisted changes. If AI-assisted code has higher defect rates, you have a training or review problem.
- Code review depth — Are reviewers treating AI-generated code with the same rigor? I've seen teams rubber-stamp AI output because "the tool probably got it right." That's dangerous.
Lagging indicators:
- Production incident correlation — Do incidents trace back to AI-generated code at a different rate than human-written code?
- Technical debt accumulation — Is AI accelerating feature delivery while quietly accumulating debt? Measure complexity metrics (cyclomatic complexity, coupling) over time.
Pillar 3: Team Growth
This is the pillar most organizations ignore — and it's the most important.
Leading indicators:
- Skill expansion rate — Are engineers using AI to tackle problems outside their comfort zone? The real power of AI isn't doing what you already do faster — it's enabling you to do things you couldn't do before.
- Knowledge sharing frequency — Are engineers sharing AI prompts, techniques, and learnings with teammates? Organic knowledge sharing is a stronger signal than mandated training.
- Junior engineer ramp-up time — Are new team members becoming productive faster with AI assistance? This is one of the clearest ROI indicators.
Lagging indicators:
- Engineer retention — Are engineers staying because AI tools make their work more interesting and less tedious?
- Internal mobility — Are engineers moving into new roles or domains they previously considered out of reach?
The Dashboard I Actually Use
I keep it simple. Four numbers on a quarterly dashboard:
1. AI-assisted PR merge rate (target: 40-60% — too low means underutilization, too high means over-reliance)
2. Defect density ratio (AI-assisted vs. non-AI-assisted, target: ≤ 1.0)
3. Cycle time improvement (quarter-over-quarter, target: 10-15% sustained)
4. Team growth score (composite of skill expansion + knowledge sharing, target: improving trend)
The Most Important Metric
The single most important metric isn't quantitative. It's this: when you take the AI tools away, do your engineers complain? If they do, you've achieved real adoption. If they don't, you have licenses — not adoption.
When we announced our AI adoption initiative, I expected excitement. What I got was silence. Not the respectful kind — the kind that fills a room when everyone knows something is wrong but nobody wants to be the first to say it.
It took me three weeks and several uncomfortable 1:1s before the real concerns surfaced. They weren't what I expected, and they weren't what the AI vendor case studies prepared me for.
The Concerns Nobody Puts in Surveys
"Will I still have a job in two years?"
This is the fear underneath every other concern, and it's the one leaders are most reluctant to address directly. We hide behind phrases like "AI augments, not replaces" and "we're upskilling, not downsizing." Engineers see right through that.
Here's what I say now: "AI will change this job. Some tasks you do today will be automated. Some skills you've spent years developing will become less central. But the engineers who learn to work with AI will be more valuable, not less. My commitment is that we'll invest in your growth through this transition — not just in the tools."
The key is specificity. Don't make vague promises about job security. Acknowledge the change honestly and commit to the investment.
"AI-generated code is a liability, not an asset"
This came from a senior architect who'd reviewed several AI-assisted PRs and found subtle bugs, unnecessary complexity, and patterns that didn't match our codebase conventions. He wasn't wrong.
I had to acknowledge the problem before I could address it. "You're right — AI-generated code can be a liability if we treat it as finished work. So here's what we're going to do: AI output is a first draft, not a final product. Every AI-assisted PR gets the same review rigor — actually, more. And we're creating AI code review guidelines that specifically address the failure patterns you've identified."
The architect became our biggest AI quality champion after that — because his concerns were heard, not dismissed.
"This is just another management fad"
Engineers with 15+ years of experience have seen agile transformations, microservices revolutions, and DevOps initiatives come and go. Some delivered real value. Others were just organizational theater. AI feels like the next item on that list.
I don't try to convince them with hype. I say: "I understand the skepticism. Here's what's different this time, and here's what's the same. What's different is that AI tools are already demonstrating measurable productivity gains in our own codebase — I can show you the data. What's the same is that the success of this initiative depends on you, not the tool. I'm not asking you to believe in AI. I'm asking you to try it on one real task and tell me honestly what you find."
"I don't want to become a prompt engineer"
This concern came from a principal engineer who feared that AI adoption meant reducing their craft to writing prompts instead of writing code. It's a legitimate fear — the "vibe coding" narrative in the industry doesn't help.
My response: "You will never just be a prompt engineer. You're an engineer who uses AI the way you use a debugger, a profiler, or a build system — as a tool that amplifies your expertise. The judgment, the system thinking, the ability to know what 'good' looks like — that's still you. In fact, senior engineers are the ones who get the most value from AI because they can evaluate and direct the output. A junior engineer can generate code. A senior engineer can generate the right code."
How to Structure the Conversation
Don't do this in a town hall. Don't do it in a Slack channel. Do it in small groups or 1:1s, and follow this structure:
1. Listen first. Ask "What concerns you most about our AI adoption?" and then shut up. Let the silence do the work. The real answer usually comes after the polite answer.
2. Validate the concern. Don't defend. Don't explain. Say "That's a real concern, and here's why it matters." Even if you disagree, start by showing you understand.
3. Be honest about what you don't know. AI is evolving fast. Pretending you have all the answers destroys credibility. "I don't know yet, but here's how we'll figure it out together" builds trust.
4. Commit to specifics. Not "we'll invest in training." Instead: "Every engineer gets 4 hours per week for AI skill development for the next quarter, and we're creating an internal AI practices guild where you can share what's working and what isn't."
5. Follow up. The conversation doesn't end when the meeting ends. Check in two weeks later. "You raised a concern about code quality — here's what we've done about it." Nothing builds trust faster than proving you listened.
The Uncomfortable Truth
Some engineers will never embrace AI. Not because they're resistant to change, but because the change conflicts with their professional identity in a way that's deeply personal. As a leader, you have to respect that while still moving the organization forward.
The answer isn't force. It's creating an environment where AI adoption is safe, supported, and honest — where concerns are treated as valuable feedback, not obstacles to overcome.
The hardest conversations about AI aren't technical. They're human. And they're the conversations that matter most.
Ask any banking engineering leader what keeps them up at night, and two answers surface almost immediately: the regulator just moved the goalposts again, and the roadmap committed to the board six months ago is already out of date. What they rarely say out loud is that these are the same problem wearing two different hats — and solving it takes an engineering organization built for genuine agility, not just a team that uses the word "Agile" in its ceremonies.
The Regulatory Treadmill Never Stops
In banking, regulatory change isn't an occasional event — it's a constant background process. Capital and liquidity rules get revised. Real-time payments mandates arrive with hard external cutover dates. Open banking and data-sharing rules expand. AML and KYC obligations tighten after every industry incident. And if you operate across multiple jurisdictions, each regulator moves on its own clock, with its own definition of "urgent."
The structural problem is timing. Budgets and roadmaps are typically locked months in advance, at the start of a fiscal year. Regulatory scope, by contrast, is often only fully understood mid-year, sometimes mid-quarter, sometimes with a final rule published six weeks before the compliance deadline. Engineering leaders are left reconciling a fixed budget against a moving target — and the business still expects the original commitments to hold.
Why Standard Agile Breaks Under Regulatory Pressure
Classic Scrum assumes scope is the flexible variable and the timebox is fixed — you negotiate what fits in the sprint, not when the sprint ends. Regulatory work inverts that assumption. The deadline is fixed by law, and a meaningful slice of the scope is non-negotiable; you cannot "de-scope" a mandatory disclosure requirement the way you'd cut a nice-to-have feature. That leaves capacity as the only variable actually available to flex.
Teams that don't recognize this shift fall into a familiar failure mode: regulatory work quietly displaces committed business features late in the cycle, engineers work unsustainable hours to hit the compliance date anyway, the budget blows past its ceiling to "make it happen," and business stakeholders lose trust in a roadmap that keeps sliding for reasons they were never told about in advance.
A Two-Lane Backlog, Not a Bigger Backlog
The fix isn't a bigger backlog or heroic sprints — it's separating delivery into two coordinated lanes with distinct planning rules: a regulatory lane and a business lane, both drawing from the same engineering capacity pool but planned against different constraints.
The regulatory lane carries a standing capacity reservation — typically 15-20% of total engineering capacity, sized from a rolling multi-year average of actual regulatory change volume, not from optimism. Critically, that reserved capacity is never idle. In any quarter where regulatory demand comes in under the reservation, the slack flows automatically to the highest-priority items in the business lane. That single mechanic changes how the reservation is perceived — it stops looking like a tax on the business roadmap and starts looking like a shared, self-balancing pool.
Building a Regulatory Radar
The two-lane model only works if regulatory demand is forecastable, which means engineering can no longer wait for legal and compliance to hand over a finished requirement. We assigned an engineering liaison to sit inside the compliance change-monitoring forum, translating draft and proposed rules into rough engineering impact assessments the same week they're published — not after they're finalized months later.
This turns regulatory change from an unpredictable shock into a known, trackable stream with lead times measured in quarters instead of weeks. It also means the two-lane backlog gets populated with a forecast, not a surprise, which is what makes capacity planning at the start of the fiscal year credible instead of fictional.
Designing for Jurisdictional Variance
When a bank operates across multiple regulatory regimes, the instinct is to build compliance logic as one-off conditionals scattered through the codebase — a fast way to ship the first jurisdiction and a guaranteed way to make every subsequent one more expensive than the last. Instead, we built a compliance kernel: a set of reusable, parameterized services covering the recurring shapes of regulatory work — reporting formats, disclosure thresholds, retention rules, approval workflows — configured per jurisdiction rather than rebuilt per jurisdiction.
The first jurisdiction is genuinely expensive to build this way. The second and third are where the investment pays for itself, because the marginal cost of the next regulatory change in a new market drops from a multi-month project to a configuration change and a focused test cycle.
Protecting the Budget: Vertical Slices Over Big-Bang Compliance
The single biggest source of budget overrun on regulatory work isn't the regulation itself — it's teams gold-plating the compliance deliverable under deadline pressure, adding polish and edge-case handling the regulator never asked for because "as long as we're in there." We slice every regulatory requirement into the narrowest vertical slice that is genuinely, defensibly compliant, ship that slice to the hard deadline, and treat anything beyond strict compliance — extended reporting views, UX refinement, additional automation — as ordinary business-lane backlog to be prioritized and funded on its own merits after the deadline pressure is gone.
What Changed When We Adopted This Model
1. Regulatory deadlines stopped being a source of budget overruns. They became a predictable, pre-funded line item instead of a recurring emergency reallocation.
2. Business roadmap commitments held. Because the capacity reservation absorbed regulatory volatility structurally, the business lane stopped being the shock absorber for compliance surprises.
3. Time-to-compliance on new jurisdictions dropped sharply. The compliance kernel meant most new-market regulatory work became configuration, not construction.
4. Stakeholder trust in the roadmap recovered. When business leaders could see regulatory capacity as a visible, bounded reservation rather than an invisible tax that ate their features without warning, roadmap conversations stopped being adversarial.
The Key Insight
Agility in a regulated industry doesn't mean moving fast and breaking things — banking cannot afford that trade. It means engineering deliberate slack into the right places in your architecture, your backlog, and your planning process, so that when the rules change — and in banking, they always will — the organization absorbs the change without breaking its promises to the business. The goal was never to predict every regulation. It was to build a delivery system that treats regulatory change as a known cost of doing business in banking, not an exception that justifies blowing the budget.
In March 2020, I was leading a team of over thirty engineers spread across multiple offices and time zones when the world simply stopped. Offices closed within days of each other. Government lockdown orders arrived faster than anyone could plan around them. And every leadership course I'd ever taken had absolutely nothing to say about how to run a team through a global pandemic while the systems we operated still had to process transactions for millions of customers every single day.
No Playbook, No Precedent
The first thing I had to accept was that I didn't have a plan, and pretending otherwise would have been the worst possible move. My team wasn't a single, uniform group facing a single, uniform problem. Some were single parents suddenly doing full-time childcare and full-time engineering from the same kitchen table. Some had elderly parents they could no longer safely visit. Some had family overseas in places hit hard and early, and spent their days refreshing the news instead of their IDE. A few got sick themselves. One by one, over thirty individual crises were unfolding inside what used to be one team's normal workday.
Standard leadership instincts — set clear expectations, hold the line on deadlines, keep the team focused — were exactly the wrong instincts for this moment. What the team needed wasn't more clarity on the roadmap. It was to know someone was actually paying attention to them as individual human beings under individual strain.
Leading Case by Case, Not Policy by Policy
The realization that changed how I led was simple: a single blanket policy cannot serve thirty different realities. So instead of issuing one remote-work policy and expecting it to fit everyone, I made it a priority to understand each person's actual situation, one on one, and to adapt around it. That meant flexible hours for the engineer managing a toddler through the workday. It meant temporarily redistributing workload away from the engineer whose parent had just been hospitalized, without making a public announcement about why. It meant knowing which of my thirty-plus people needed to hear from me daily, and which needed me to simply leave them alone and trust them.
This is slower and harder than writing one policy and applying it uniformly. It's also the only version of leadership that actually worked. The policy was the floor — the minimum the company guaranteed everyone. My job was everything above that floor, tailored to the person in front of me.
Becoming the Source of Truth Amid a Deluge of Uncertainty
Government guidance changed weekly. HR policy changed to keep pace, sometimes days behind the government. Return-to-office guidance, quarantine rules, travel restrictions — my team looked to me to translate all of it into a straight answer to the question they actually had: what does this mean for me, today?
I started holding a short, standing weekly session with the whole team, open floor, where I answered whatever question came up — even the ones I didn't have a good answer for. I made it a rule to never fake confidence I didn't have. If I didn't know whether an office would reopen in a month or a quarter, I said so, and I told them exactly how and when I'd find out. Uncertainty handled honestly builds trust. Uncertainty papered over with false confidence destroys it the moment reality catches up.
The Emotional Toll Nobody Puts on the Org Chart
I changed the way I started every 1:1 during that period. Before any status update, before any discussion of the sprint, I asked how someone was actually doing — and I waited for a real answer instead of the reflexive "fine." Some of the hardest conversations of my career happened in those minutes. One engineer on my team lost a parent in the middle of a critical release cycle. There was no version of leadership where the release mattered more than that. I pulled their work off their plate without being asked, redistributed it quietly, and told them to take whatever time they needed, full stop, no conditions attached.
Grief, fear, and burnout don't announce themselves on a status report. They show up as a camera that stays off, a Slack message that takes a day longer to answer, a normally sharp engineer who suddenly seems distracted in code review. Watching for those signals became as much a part of my job as watching sprint velocity.
What Kept the Team, and the Systems, Running
Practically, a few things mattered most. We built a buddy system so no one person was a single point of failure for critical on-call coverage, which meant someone dealing with a family emergency always had immediate backup without having to ask for it publicly. We rebalanced workload transparently across the team rather than quietly overloading the people who happened to be less visibly affected. We gave explicit, stated permission to log off, to keep cameras off, to take a walk in the middle of the day, because unstated permission doesn't actually give anyone confidence to use it. And we kept a recurring, no-agenda video call every week whose only purpose was for the team to see each other's faces and talk about anything other than work.
What I'd Tell Any Leader Facing the Next Crisis
1. Individualize, don't generalize. Company policy is the floor everyone stands on, not the ceiling of what you owe each person. Case-by-case flexibility is not favoritism — it's leadership matched to reality.
2. Be the calm, honest voice, even without all the answers. Your team can handle not knowing yet, as long as they know how you'll find out. What they can't handle is a leader who pretends certainty and turns out to be wrong.
3. Lead with the emotional check-in, not the status update. How someone is doing determines what they're capable of that day far more than the sprint plan does.
4. Absorb the ambiguity yourself so your team doesn't have to carry it alone. Translating chaotic, shifting external guidance into a clear, personal answer is one of the most valuable things a leader can do in a crisis.
5. Protect people before you protect deadlines. Every time I chose the person over the deadline, the team's trust in me deepened, and, not coincidentally, so did their commitment to hitting the deadlines that mattered.
The Outcome
Through nearly two years of a pandemic, that team of more than thirty kept every mission-critical system running and met our regulatory delivery commitments, without a single missed deadline traceable to the crisis itself. Attrition on the team stayed well below what peers elsewhere in the organization experienced. None of that was an accident, and none of it happened because I held the line on process. It happened because thirty-some people knew that when their world got hard, their leader would meet them exactly where they were.