Scaling is not just about adding more servers or moving to Kubernetes. The real transition is from “it works” to “it works at scale, reliably, for everyone.” That shift is where many Series-B startups struggle because what was once a product engineering problem becomes a platform engineering problem. It requires multi-tenant architecture, disciplined reliability engineering, mature observability, and security built-in from day one.
Srikanta Datta Tumkur has seen this transition across both startup and enterprise environments, working at a Series-B company (Symphony) and now leading AI infrastructure in a public-company setting. He has served as a judge at startup and technology forums and is an inventor on several filed or pending patents spanning GPU scheduling, multi-tenancy, secrets management, and reliability engineering patterns. In this interview, he shares what breaks at scale, what investors should look for in technical due diligence, and how founders should think about intellectual property and business alignment.
The hardest technical transition for startups
“The hardest transition is from ‘it works’ to ‘it works at scale, reliably, for everyone,’” Srikanta says.
At Symphony, the evolution looked familiar on paper: a shift from a monolithic application to microservices and from VM-based deployments to Kubernetes and ECS. But the real complexity was not the tooling change. It was multitenancy.
“When you’re serving SMBs and SMEs on a shared platform, every layer infrastructure, application, data needs namespace isolation,” he explains. “I designed the multitenant architecture that made this possible. Every layer was namespace-aware.”
That requirement changes everything: how you isolate tenants, how you prevent noisy-neighbor impact, how you manage configuration drift, and how you enforce security boundaries. It also forces a serious rethink of disaster recovery.
“We had to rethink disaster recovery too, cross-cloud, cross-region replication using Google PubSub as a global message bus,” he says.
For founders, the lesson is direct: Series-B architecture decisions determine whether a company can scale to Series-C without becoming operationally fragile. Technical debt compounds, and platform shortcuts become bottlenecks at precisely the moment growth accelerates.
What he looks for when judging startups
Srikanta has judged at startup conferences, and he says technical due diligence often fails on basics that later become existential risks. He calls out three red flags.
The first is single points of failure. “If the CTO says they run one Kubernetes cluster in one region, they have not designed for reliability,” he says. “Multi-AZ and multi-region are table stakes.”
The second is lack of observability. “If they can’t show dashboards latency percentiles, error rates, and resource utilization they’re operating blind,” he says. At Cisco, he helped build a platform that automated deployment and upgrades of a Kubernetes-based environment, delivered managed observability engineering, and provided several managed platform services used across internal teams. “That’s the standard for how you run a serious platform,” he adds.
The third is security as an afterthought. “Compliance isn’t something you bolt on before an IPO,” he says. “At Oracle, I built a security hardening tool that automated DISA STIG compliance. If a startup isn’t thinking about security from day one, they’ll pay for it later.”
Together, these red flags fragile architecture, invisible operations, and delayed security usually show up as outages, slow incident response, rising cloud spend, and slowed engineering velocity.
How startups should think about patents and IP
Srikanta is an inventor on several filed or pending patents, and he frames patents less as paperwork and more as a discipline.
“Patents are a forcing function for innovation,” he says. “Writing a patent application makes you articulate what’s novel about your approach.”
His patents span GPU scheduling, multi-tenancy, secrets management, and reliability patterns, focused on solving real production problems in cloud-scale AI infrastructure.
“These aren’t theoretical. They’re solutions to real problems we encountered building infrastructure at scale,” he says.
For startups, his guidance is pragmatic: validate your approach first, but do not ignore IP. “File patents on your core differentiators later in the process, once you’ve validated the approach. But do file them,” he says. “IP becomes crucial at acquisition or IPO.”
What investors should ask in technical due diligence
From an investor perspective, Srikanta recommends due diligence questions that reveal how a team actually operates, not just how they pitch.
First, ask to see incident postmortems. “Show me your incident postmortems,” he says. “How a team responds to failure tells you more than architecture diagrams. If a startup can’t show you postmortems, they’re not learning.”
Second, ask about the path to 10x scale. “What’s your path to 10x scale,” he asks. “If the answer requires rewriting the core platform, that’s a red flag. Good architectures scale incrementally.”
Third, identify internal customers and adoption. “Who are your platform’s internal customers,” he asks. Internal adoption is a proxy for quality. If the company’s own engineers don’t want to use the platform, external customers will not either.
These questions expose maturity in reliability, operational learning, platform usability, and architectural flexibility, predictors of whether a company can scale without becoming brittle.
Why business education matters for technical leaders
Srikanta credits his education across three institutions with shaping how he communicates impact. “Carnegie Mellon gave me the systems foundation. IIT Kanpur keeps me current on cybersecurity research. HEC Paris gave me vocabulary to talk to business stakeholders,” he says.
He argues that technical leadership is incomplete without translation. “Reducing p99 latency by 40% means little to a CFO,” he says. “Serving twice the customers with the same infrastructure cost does.”
Being fluent in both engineering and business helps leaders influence company-level decisions roadmaps, risk tradeoffs, and investment priorities rather than staying confined to implementation-level discussions.
The platform engineering takeaway for founders
Series-B is the phase when platform decisions become hard to reverse. If you delay multi-tenancy, you will rebuild later. If you skip observability, you will operate blind during growth. If you treat security as a last-minute checklist, you will pay for it in delays, incidents, and credibility loss.
The startups that successfully scale into Series-C adopt platform engineering early: reliability by design, observability as a default, and security as a built-in guardrail. The goal is not merely to build a product that works. It is to build a platform that keeps working under load, under failure, and under scrutiny.
No VCCircle journalist was involved in the creation/production of this content.
