The Builder

Twenty years of making delivery boring — on purpose.

I lead engineering the way I wish someone had led it for me: steady over spectacular, calm over loud. My job is to build the systems — delivery governance, reliability posture, a leadership bench — that let good people do their best work without burning out. AI sharpens that discipline. It doesn’t make the call.

Start a conversation Résumé ← Back home

The throughline

One thread, the whole way down.

Twenty years in, it’s mostly been the same move, just higher up each time. At first the job was to make the thing work. Ship it, survive the audit, keep the night quiet. Then it stopped being about the thing and started being about the system that makes the thing — I couldn’t be in every cutover anymore, so I built the machine instead of running it. Now it’s the people. That’s the part that took me longest to admit: the only thing that scales past me is judgment I helped shape and then got out of the way of. I used to call that three different careers. It was one question, asked a level higher every few years.

What’s the smallest thing I can build that makes the next thing hold without me? Still working on the answer.

The migration rehearsal mattered more than the migration.

The evolution of a builder

Twenty years, three chapters.

  1. 2003 — 2013 01

    A £5M rollout that could not fail, and a decade learning why steady wins.

    I started in enterprise IT — operations and software delivery across IBM and NIIT SmartServe, running banking and financial-services programs to 98%+ compliance. Then Clifford Chance in London: a global document-management migration across 10 international offices with zero operational downtime, programs up to £5M, a 100% audit and governance record. The decade taught me that unremarkable engineering is expensive to build and cheap to operate.

    • IBM
    • NIIT SmartServe
    • Clifford Chance
    What I learned
    I learned what it costs when something breaks that wasn’t supposed to. In banking and at a law firm, a failure isn’t a bug ticket; it’s a deal that didn’t close, an audit finding, a client who now reads every email from you twice. That environment taught me to respect the work nobody claps for — the rehearsal, the rollback, the boring checklist that means the night stays quiet.
    What changed
    I stopped thinking my job was to be clever and started thinking it was to be trusted. Early on I wanted the elegant solution. The regulated years rewired that: the question was never “is this impressive,” it was “can this survive a bad day with someone else holding it.” Reliability stopped being a feature I added and became the thing I was actually being paid for.
    What I carry forward
    The instinct that anything important should be able to fail safely, and that the unglamorous preparation is the deliverable, not the overhead. I still build for the bad Tuesday first. The calm I look for in an organization started here, in rooms where there was no room to be wrong.
  2. 2013 — 2024 02

    The wild years: multi-region delivery and AI-powered products before the hype.

    As COO at Lall & Sethi I ran the turnaround of a 50-person org — 18% cost reduction, 20% retention lift, 25% revenue growth, no proportional headcount. Then Apptology in Dubai: 15+ concurrent programs across Dubai, India, and Eastern Europe, $200K–$2M+ budgets, 12 transformations on time, 95%+ client satisfaction. Then Builder.ai’s Studio Store — 40+ concurrent enterprise engagements across the US, UK, and APAC, 85%+ renewals, recovering accounts others had written off.

    • Lall & Sethi
    • Apptology
    • Builder.ai
    What I learned
    A system you can fully reason about is a luxury you lose the moment people, regions, and currencies enter the picture. As a COO I stopped owning a deliverable and started owning an outcome I couldn’t personally produce. Across time zones and a studio full of concurrent builds, the hard part was rarely the engineering. It was the ambiguity between people about who owned what.
    What changed
    My definition of control inverted. I used to believe more oversight meant more safety; this stretch taught me the opposite — the tighter I gripped, the slower everything got and the less the team grew. The accounts that went quiet scared me more than the ones that shouted, and learning to hear that silence changed how I read a whole organization. I started leading from fewer rooms on purpose.
    What I carry forward
    That you scale people by giving them a clear edge to own, not a longer leash to manage. I carry the habit of watching for what’s gone unsaid, because the signal that matters usually goes quiet before it gets loud. And I stopped separating “the business problem” from “the engineering problem” — after enough turnarounds, they were obviously the same conversation in two accents.
  3. 2024 — Present 03

    Building the engineering organization I always wished I had.

    I joined Sequifi in March 2024 to lead an AI-first transformation. As Director of Product Engineering I own a 60+ engineer organization across 6 teams, a layer of 5 EMs and tech leads, the budget, the hiring plan, and the reliability behind $50M+ ARR. The systems show up in the numbers: 40% fewer customer-impacting incidents, 99.9%+ uptime, on-time delivery from ~60% to 95%+, ~25% velocity gain from AI without trading away quality.

    • Sequifi
    • AI-First
    • Platform Engineering
    • DevOps/SRE
    What I learned
    Past a certain size, my output isn’t the decisions I make; it’s the quality of decisions made when I’m nowhere in the room. The work moved up a layer — from execution to judgment, from doing the thing to shaping who decides and how. AI sharpened that rather than softening it: speed is cheap now, so the scarce thing is the discipline to point it somewhere worth going.
    What changed
    I stopped measuring myself by what I touched and started measuring by what holds without me. I used to feel useful in the thick of delivery; now I feel useful when a team I’ve built makes a call I’d have made, faster than I would have, and I only hear about it afterward. Anything you can automate is a quiet admission of what you actually valued — I’d rather decide that on purpose than by default.
    What I carry forward
    That leverage is people, then systems, then tools, in that order, never the reverse. A suspicion of speed that isn’t attached to judgment. And the belief that the leaders I leave behind are the real artifact. The further I get, the more the job looks like building the conditions for good decisions, and the less it looks like making them.

Inflection points

Five moments that rewired how I lead.

  • 01

    The first time the system was the team.

    I couldn’t engineer my way out of this one. The bottleneck wasn’t a process or a tool; it was people waiting to learn whose call things were — and only I could remove that ambiguity.

    The deeper version
    Situation
    I moved from running delivery to running a company, in the COO seat of a fifty-person firm where the outcome was finally, fully mine.
    Lasting impact
    I started treating clarity of ownership as the primary system I build, before any tooling or ritual. It’s still the first thing I look for when I walk into a struggling org.
  • 02

    The migration that wasn’t allowed to pause.

    The plan wasn’t the deliverable; the rehearsal and the rollback were. The confidence to commit came entirely from being able to undo any step.

    The deeper version
    Situation
    A document-system move across a global firm’s offices, where there was no maintenance window, because the business genuinely never stops.
    Lasting impact
    I make safety a precondition now, not a hope, and I find the calm in being over-prepared. I build every high-stakes change backwards from “what happens when this goes wrong.”
  • 03

    The accounts that stopped complaining.

    The dangerous accounts weren’t the ones escalating; they were the ones who’d stopped expecting us to fix anything. Recovery was a communication problem long before it was a delivery one.

    The deeper version
    Situation
    A portfolio of enterprise engagements across three regions, several quietly slipping, where the loud clients were easy to see and the silent ones weren’t.
    Lasting impact
    I treat silence as the loudest signal in the room, and call the account that’s gone quiet first. It changed how I read teams, not just clients.
  • 04

    The 3 a.m. reckoning with key-person risk.

    A team admired for its heroic saves usually has a design flaw nobody named. The fragility wasn’t bad luck; we’d built it in by leaving knowledge in individuals.

    The deeper version
    Situation
    The same few engineers kept getting paged because the critical paths lived in their heads, and the late-night calls were climbing. I remember noticing the same names in the alert threads week after week — at some point it stopped feeling heroic and started feeling irresponsible.
    Lasting impact
    I stopped admiring heroics and started designing them out, on purpose. Resilience became something I architect into how a team holds knowledge.
  • 05

    Going AI-first before it was tidy.

    AI doesn’t add discipline; it multiplies whatever discipline it finds, including none. The teams that won weren’t writing the most code — their judgment was already strong enough to absorb the speed.

    The deeper version
    Situation
    Leading an organization through adopting AI deep in the workflow, while the tooling, the norms, and the failure modes were all still forming.
    Lasting impact
    I treat AI as leverage on judgment, not a substitute, and keep the human calls — review, security, architecture — first, so the speed compounds instead of curdling.

Decisions I Get Paid To Make

The calls that don’t have a clean answer.

Past a certain scale, the job is judgment under tradeoffs nobody can fully resolve — most solve one bottleneck by creating another. The work is choosing which constraint the organization is healthiest carrying next.

  • Build vs Buy

    Buy the undifferentiated, build what’s genuinely ours to be good at. The test isn’t cost today — it’s which call I’ll still own in two years.

  • Speed vs Stability

    I set the posture that lets velocity rise without spending the reliability we sell. When they truly collide, stability wins — and the team knows that going in.

  • Platform vs Features

    I fund platform deliberately, tie it to an outcome leadership can feel, and never let it become a project with no customer.

  • AI Governance vs Velocity

    Speed without controls erodes what made us trustworthy. Review, security, and architectural ownership stay non-negotiable — which is why the velocity is real.

  • Centralization vs Autonomy

    Centralize what protects the whole system — reliability, security, the standards everyone builds against. Everything else goes to the teams closest to the context. Autonomy inside guardrails, not instead of them.

  • Tech Debt vs Market

    Debt is a loan, not a sin. I’ll take it on knowingly for a real window, name it, and schedule the repayment — I just won’t pretend the interest isn’t accruing.

  • Hiring vs Automation

    Before adding headcount, I ask what made the work expensive. Automate the friction, then hire into the room that opens up. Growth should buy capacity, not cost.

AI, in practice

How I actually use AI to run engineering.

I run an AI-first org, so none of this is theoretical. It’s less magic than the pitch and more discipline than people expect.

  • Augmentation, not autopilot

    The model is the fastest junior on the team — quick, occasionally brilliant, never the one who signs off. It drafts; people decide.

  • It buys decision speed, not typing speed

    The real gain wasn’t faster code. It was cheaper iterations on the thinking — more options on the table before anyone committed to one.

  • The gates are the whole point

    Human review, security and dependency scanning, the architectural calls kept with the seniors. We took ~25% more velocity with no drop in quality because the gates got stronger, not weaker.

  • Where I keep it out

    Anything where being confidently wrong is expensive — the architecture, the incident call, the people decisions. Those stay slow on purpose.

  • It changes the team, quietly

    The skill that matters now is reviewing well and knowing which question is worth asking. I hire and coach for that, not for typing speed.

What I keep an eye on: judgment thinning out when the machine drafts everything and the human just approves. Easy to ship more and understand less.

The room got quieter after that.

Selected Problems

The problems I’m brought in to own.

The ones that live above any single team, ticket, or roadmap — where the failure mode is organizational, not technical.

  • Delivery loses visibility once the org outgrows a single team. Work spreads across enough surfaces that no one can see where execution is slipping until a date is already missed. I build the reporting and ownership structure that makes commitments legible before they break.

    If it’s not solved: forecasting breaks, leadership plans on fiction, and trust erodes one missed date at a time.

    proof At Sequifi, this turned delivery from guesswork into a number leadership could plan around.

  • Speed and stability pull against each other, and most orgs pick one by accident. I set the operating posture that lets velocity rise without quietly trading away the reliability the business is sold on.

    If it’s not solved: you either stall the business or ship the outage that costs an enterprise contract.

    proof The discipline that held a £5M Clifford Chance migration across 10 offices to zero downtime.

  • Strategy arrives as ambiguity — a direction, a constraint, a board expectation — and someone has to convert it into a plan teams can execute against. I translate that into sequenced, ownable work, with the architectural calls made up front, not discovered mid-flight.

    If it’s not solved: strategy stays a slogan and teams build confidently in the wrong direction.

    proof Twelve transformations delivered on time across three regions at Apptology — each one started as a one-line brief.

  • Engineering, product, support and the business each optimize for their own view, and execution stalls at the seams. I build the alignment that makes ownership obvious — because clear ownership beats any amount of coordination overhead.

    If it’s not solved: the seams become where delivery quietly dies and no single team owns the failure.

    proof Recovering 40+ at-risk enterprise engagements at Builder.ai was a communication problem before a delivery one.

  • AI gets adopted as a shortcut and quietly erodes the discipline that kept quality high. I make it an accelerant instead — human-in-the-loop review, governance before velocity, architectural and security oversight — so the gain is real and the standard holds.

    If it’s not solved: AI buys this quarter’s speed with next year’s reliability and security debt.

    proof Velocity rose at Sequifi only because the review and security gates got stronger, not weaker.

  • Cost creeps as orgs grow, and the lazy fix is always more headcount. I’d rather remove the friction that made the work expensive in the first place, then grow deliberately into the room that opens up.

    If it’s not solved: the org gets more expensive and slower at once, and headcount stops being the answer.

    proof An 18% cost reduction and 25% revenue growth as COO at Lall & Sethi — without proportional headcount.

Engineering Through a Business Lens

Engineering decisions are business decisions.

Engineering Business consequence
Reliability Customer trust and renewal protection
Delivery predictability Forecasting and planning confidence
Platform investment Faster long-term execution
Observability Lower support and escalation cost
AI acceleration Operational leverage and margin efficiency
Technical discipline Reduced enterprise risk

I don’t separate engineering outcomes from business outcomes. Reliability affects retention, predictability affects planning, platform quality affects sales velocity. A strong engineering org doesn’t just ship faster — it sharpens product judgment by making tradeoffs visible earlier. Engineering is one of the ways a company expresses its operational maturity.

How Teams Change When I Join

What the org looks like a few quarters in.

Not a personality change — a systems change. The same people, operating differently because the structure around them changed.

Before After
Hero culture Distributed ownership
Unclear ownership Clear accountability
Reactive operations Predictable execution
Escalation dependency Leadership leverage
Inconsistent delivery Reliability as culture
Experimental AI adoption Governed AI acceleration

The escalation stopped before the account recovered.

Building Teams People Don’t Leave

I’d rather create leaders than manage engineers.

The strongest signal of an engineering leader isn’t the system they ship — it’s the leaders they leave behind.

  • 01

    Hire for judgment, not keywords

    Skills you can teach; judgment under uncertainty you mostly can’t. I built repeatable hiring loops with calibrated leveling, so the bar holds whether we’re adding the fifth engineer or the sixtieth.

  • 02

    Build leaders of leaders

    A layer of engineering managers and tech leads who own outcomes, not tickets — a management bench that holds when the org doubles and means no critical decision waits on me.

  • 03

    Delegate the decision, not just the task

    Leverage comes from making the right call obvious to the person who has to make it at 2 a.m. Clear context, clear ownership, then I get out of the room.

  • 04

    Make truth cheap to say

    A team that surfaces bad news early is the single biggest reliability lever I have. Blameless post-mortems and psychological safety aren’t soft; they’re how problems get fixed before they become outages.

  • 05

    Accountability without theatre

    Named owners on releases and incidents, follow-through that actually closes — clarity, not blame, so good people stay and own the hard parts.

  • 06

    Keep knowledge out of heads

    Documented ownership, cross-training, and rotated handoffs turn fragile individual knowledge into durable team capability — and cut the regrettable attrition that comes from burning out your indispensable people.

I don’t optimize teams for short bursts of output — I optimize for the clarity and execution that hold over years.

Moments

Achievements blur. Moments stick.

In hard moments, teams rarely need louder leadership — they need calmer signal.

Scene 01

The quarter the commitments stopped landing.

Made delivery visible instead of piling on process — on-time delivery went ~60% → 95%+.

Read the full scene
Challenge
On-time delivery sat near 60%. Teams were confident Monday, slipping by Thursday; stakeholders had stopped believing the dates — not because engineers couldn’t build, but because no one could see where work stood until it was already late.
Decision
I refused to pile process onto teams already drowning in it. I made execution visible instead: hard scope boundaries, prioritization tied to business outcomes, one honest status cadence everyone read from.
Tradeoff
We committed to less, out loud, and held the line — trading optimistic dates for credible ones.
Outcome
Within six months, on-time delivery moved from ~60% to 95%+, and the dates became unremarkable.
Lesson
Predictability isn’t a reporting feature; it’s what lets the rest of the business plan.
Scene 02

The migration that couldn’t go down.

Ten international offices, £5M, zero operational downtime, a full audit trail.

Read the full scene
Challenge
A document-management migration across ten international offices at Clifford Chance. The constraint wasn’t the schedule or the £5M budget — a global law firm cannot pause; an hour offline in London is a deal team that doesn’t stop for our migration.
Decision
Zero operational downtime as a hard floor, not a target — sequence by office and time zone, rehearse every cutover, keep rollback ready at each step, hold governance in the room throughout.
Tradeoff
Slower and far less glamorous than a big-bang cutover; the unglamorous work was the work.
Outcome
All ten offices landed with no operational downtime, a full audit record, and a 100% compliance record across the program.
Lesson
In a regulated, business-critical environment, the rehearsal and the rollback plan are the deliverable.
Scene 03

Forty accounts — and the quiet ones worried me most.

Recovered at-risk enterprise accounts across three regions; renewals held above 85%.

Read the full scene
Challenge
40+ concurrent enterprise engagements across the US, UK and APAC at Builder.ai’s Studio Store, several already at risk. The quiet accounts — clients who’d stopped escalating because they’d stopped expecting a fix — were the real exposure.
Decision
Treat recovery as a communication problem before a delivery one: go back to the silent accounts, name the gap honestly, rebuild a cadence they could trust.
Tradeoff
Leading with uncomfortable honesty about where we’d fallen short, before every fix was in hand.
Outcome
The at-risk accounts came back; renewals held above 85% across the portfolio.
Lesson
Enterprise trust is won back with predictability and candor, not heroics. Call the account that’s gone quiet first.
Scene 04

The 3 a.m. war room nobody should have needed.

Built reliability in — incidents fell and on-call stopped depending on who was awake.

Read the full scene
Challenge
Incidents were climbing, and the same few engineers kept getting paged because the critical paths lived in their heads. The real risk wasn’t any single outage — it was the key-person dependency underneath it.
Decision
Slow merge velocity while we built reliability in — observability that surfaced problems early, blameless post-mortems with real follow-through, rotated on-call, cross-training, documented ownership.
Tradeoff
Much of it looked invisible against shipping pressure; I had to hold leadership’s confidence while it compounded.
Outcome
Production incidents fell ~40%, reliability stopped depending on who was awake, and the late-night calls went quiet.
Lesson
A team admired for its midnight saves usually has a systems problem nobody fixed. Design the heroics out.

The dashboard stayed green longer than the trust did.

What I keep building

Three things I build in every org I touch.

01

Engineering Leadership

Calm organizations, built deliberately — not assembled in a panic.

Organizational design, delivery governance, and hiring loops that scale with the company. A leadership-of-leaders layer — engineering managers and tech leads who own outcomes — that holds when the org doubles. At Sequifi that meant scaling ~15 to 60+ engineers across 6 teams as the company grew.

02

AI-Native Execution

AI as leverage, with the guardrails intact.

GitHub Copilot, Cursor, and Claude adopted with mandatory human review — no unreviewed AI output reaches production. Stronger test and CI gates, dependency and secrets scanning, staff and lead design authority retained, accountable owners on every release. The result was ~25% velocity gain with no drop in quality.

03

Platform Reliability & DevOps

Reliability is a leadership responsibility, not an afterthought.

I ran the on-call rotation, sat through the call no one should have had to take, and signed the runbook the next morning. The work — observability, incident discipline, reduced reliance on any single engineer through cross-training and rotated ownership — drove a 40% incident reduction and sustained 99.9%+ uptime.

Leadership overview

The scope, at a glance.

Director of Product Engineering · executive team

Org scope & team scale
60+ engineers · six teams · a layer of EMs + tech leads · owns budget & hiring plan
Delivery responsibility
Platform behind $50M+ ARR · enterprise SaaS
Operational outcomes
~40% fewer incidents · 99.9% uptime · on-time delivery ~60% → 95%+
AI transformation
Led an AI-first org; ~25% velocity gain with the quality bar held
Domain complexity
Regulated / enterprise delivery; global (US · UK · APAC)
Cross-functional influence
Partners with CEO / CTO / CPO on org design, planning, and the board-facing view
Track record
Scaled ~15 → 60+ engineers · turned around a 50-person org · recovered 40+ at-risk enterprise accounts · £5M zero-downtime migration across 10 offices

LinkedIn Résumé (PDF)

Selected case studies

Three transformations, in detail.

Why a novelist’s instincts keep showing up in how I run a team.

Your turn

Building something that has to hold?

If it needs a leader who’s scaled the org, owned the 3 a.m. outages, and shipped under real stakes — let’s talk.

Start a conversation How I lead

LinkedIn Résumé