Amit Sharma

I started my career as a Python developer working on HPC-cloud integration at Computational Research Laboratories — building frameworks that burst genomics workloads from on-prem clusters to AWS. That foundation in distributed systems and cloud automation became the thread that runs through everything I've done since.

Over a decade, I moved from automation scripts to infrastructure architecture to program leadership — leading migrations at platforms that couldn't afford downtime: Tokopedia, Bukalapak, Koo, a mobile advertising platform in India, and now a securities brokerage in Indonesia. Each engagement added a layer to how I think about cloud platforms: not just as technical systems, but as organizational ones.

Today I work as an Engineering Lead through Ollion, where I take on complex, high-stakes cloud transformation programs and own them from discovery through production handover.

I think most cloud migrations fail — or underdeliver — for the same reason: they're treated as technical projects when they're fundamentally organizational ones. The architecture is usually the easier part. The harder part is aligning teams, building trust with stakeholders, and making sure the humans who have to live with the new platform actually understand and own it.

On AI: I'm not a skeptic, and I'm not a true believer. I use AI tools in my work and they make me more effective. But I think the discourse around "AI replacing engineers" misses what makes engineering actually valuable — judgment, ownership, and the ability to work through ambiguity with other humans. Those aren't automatable, at least not yet.

What excites me is AI-augmented operations: using AI to reduce toil, improve observability intelligence, and surface patterns that humans would miss. That's the direction I'm building toward.

I lead from the ground up — which means I'm comfortable writing Terraform and presenting risk reports to executive sponsors in the same week. On complex programs, I've found that technical credibility is a prerequisite for leadership credibility. You can't ask teams to trust a direction you can't defend technically.

I believe strongly in explicit ownership. On every program I run, every service, every database, every external dependency has a named owner. "The platform team owns it" is how things get missed during cutovers.

I also believe in knowledge transfer as a first-class deliverable. A successful engagement ends with the client team operating the platform independently — not dependent on the consulting team for ongoing support.

I'm continuing technical consultation for a securities brokerage in Jakarta, where I previously led a full Kubernetes platform migration. The platform is in production; I'm now helping their engineering team extend and operate it independently.