Over a decade as a backend engineer taught Riddhi Shah a lot about building systems that scale. Leading Cloud Infrastructure at Abnormal taught her something else: the fastest way to lead well is to stay close to the work.
Getting Into The Work
Riddhi joined Abnormal from a background that spans HashiCorp, Rackspace, and SAP, where she built deep exposure to what it takes to run cloud platforms reliably at scale. When she started talking to Abnormal, the draw wasn't just the role. It was the moment in time.
"AI tooling is reshaping not just how we work, but business strategy, product direction, and roles themselves," she said. Abnormal sat right at that intersection: an AI-driven platform for cybersecurity that was also genuinely embracing AI-first ways of working internally.
She joined to contribute and stretch. And within weeks, she was doing exactly that.
The Migration That Changed How She Leads
When Riddhi joined, one of the most consequential infrastructure projects on the table was the Gyre Migration. Gyre was a hybrid Azure-based EU datacenter Abnormal had stood up in 2021 to expand quickly into the European market. By 2024, it had served its purpose. StratOS-EU, a fully EU-resident AWS environment, was live, and Gyre needed to go.
The stakes were real. Every customer still running on Gyre was blocked from new products and detection improvements. Moving them wrong meant missed attacks, service outages during cutover, or loss of historical data. All of it a serious risk to customer trust.
High-priority escalations were landing. The migration runbook existed, but running it was semi-manual and time-intensive. The team had a clear priority: improve the automation so future migrations would move faster. But that work required focus, and active migrations kept landing.
Riddhi made a call: she would run migrations herself.
"My engineers didn't have the slack to run active migrations and improve the automation — asking them to do both meant we'd never fix the actual bottleneck."
This wasn't a symbolic gesture. She had more than 100 customer migrations ahead of varying complexities, internal hiring timelines that wouldn't close the gap fast enough for that quarter, and engineers who needed room to build. Taking migrations off their plate gave the team room to do exactly what she'd hired them to do: build something better.
What she got in return was context she couldn't have acquired any other way. She saw exactly which steps were manual, where time actually got lost, and what "semi-automated" meant in practice rather than on paper. That made her a more accurate prioritizer, a more credible backup during staffing gaps, and a manager whose team could see she understood what they were dealing with.
"It also changed a few things concretely," she said. "I could set more accurate timeline expectations since I'd run the process end-to-end myself, and build genuine empathy for the operator experience — which helped team morale."
From 75 Tickets to 25
While the migration work was unfolding, Riddhi was also looking at a different kind of operational problem.
In October 2025, her on-call engineer was fielding around 75 tickets a week. Cloud infrastructure help requests of all kinds, all landing in the same queue. For the engineers rotating through on-call, this meant constant context-switching, a backlog that kept internal teams waiting, and enough noise that things occasionally slipped through into escalations.
"Even during business hours, that volume meant constant context-switching causing operator toil, a backlog that kept customer teams waiting, and things occasionally slipping through the cracks turning into escalations."
The fix wasn't a headcount addition. It was categorization and routing. Riddhi mapped the incoming request types, pulled out what didn't belong in on-call, and built new intake flows. PR review requests moved to an auto-assigned shared rotation. Design reviews, general questions, and feedback got routed to dedicated channels. On-call became reserved for urgent blockers.
By the time the changes took hold, ticket volume had dropped 66%. On-call engineers could focus on what actually needed their attention. And the noise reduction had a side effect no one had fully anticipated: with less volume flooding the queue, the team could finally see where self-serve tooling was missing and which customer pain points deserved to feed into roadmap decisions. Signal that had been getting lost in volume started surfacing.
Building What Didn't Exist Yet
Reducing operational noise freed Riddhi up to look at where else her team's time was going. One of those places was the daily standup.
Her larger team had been running daily standups that had run their course. She switched the team to an async standup bot, a Claude Cowork skill that runs on a schedule, pre-populates each engineer's update automatically, and prompts them to flag blockers or risks to weekly goals before posting to a Slack channel.
The result: engineers review their pre-populated update, add anything missing, and flag blockers on their own time instead of context-switching into a meeting first thing. Conversations that actually need synchronous attention get them. Everything else stays async. The estimate across a team of roughly 10 engineers is about 2 hours saved per week per engineer.
This is how Riddhi thinks about AI as a leadership tool: not just as something her team builds, but as something she builds with.
"AI lets me stay a contributor, not just a manager," she said. "I use it to assist on PR reviews, improve documentation to be more agent-friendly, synthesize debrief notes, surface themes from on-call load — it does the first pass so I can focus on what the data actually means."
"That time back is the real unlock. It's given me room to take on additional scope and spend more time looking ahead — on strategy, architecture direction, and where the team needs to be in six or twelve months — instead of staying fully consumed by the day-to-day."
What Abnormal Actually Asks Of You
Across the migrations, the ticket reduction, the automation, there's a pattern in how Riddhi talks about her work. She doesn't assume that what fixed last quarter's bottleneck is still the right fix now.
"Moving this fast means the bottleneck never sits still," she said. "What slowed the team down last quarter — a process gap, a program that wasn't resourced right, a skills gap, technical design bottlenecks — usually isn't what's slowing us down now. Abnormal asks me to keep re-diagnosing rather than assume the fix I made once is still the right fix."
That's the version of velocity she keeps coming back to. Not moving fast as an end in itself, but staying close enough to the actual work that you can tell where it's stuck and move to unstick it.
For engineers and engineering leaders considering a role here, she's direct about the trade: "This is the right place if you want ownership over ambiguity, not just execution against a clear brief. If you want to keep re-learning what 'good' looks like as things evolve, the trade is worth it."
That instinct, to stay close to the work and keep questioning what "good" looks like, is what she's carried through everything in her first year. It's also what she expects to carry into the next one.
