In enterprise software delivery, speed has long been treated as a tradeoff, something to be sacrificed in favor of reliability, security, and stability. Releases were expected to take time; weeks or even months.
Well, the folks at Acceldata, who handle data observability for giants like global telecoms and major banks (yeah, high stakes!), decided that wasn't good enough anymore. They looked around at modern blitzscaled enterprise products like Snowflake and Databricks and realized that enterprise expectations have changed over the last decade. They expect to receive continuous innovative features.
In fact, Speed is the only moat to build a successful modern enterprise software company.
So they asked the hard question: “Are our developers productive or can we ship faster?”
That’s where Acceldata’s journey began.
Setting the Stage
Acceldata had been around for 6 years. Their R&D team is 90 people – devs, QA, ops, project managers. And their tech stack? A bit of everything: Scala, Kotlin, Java, Go, Python and TypeScript running on Kubernetes across AWS and GCP. We're talking over 3 million lines of code; Complex stuff.
Despite all that, they managed to ship 30 major releases in just 6 months.
That kind of pace is unusual for an enterprise software company. But it wasn’t just brute force or hiring more engineers, rather, it was the result of a deliberate focus on removing friction from the developer experience.
In a recent webinar hosted by Acceldata CTO, Ashwin Rajeeva and Facets Co-founder and CEO, Pravanjan Choudhury, shared the thinking behind their approach to developer productivity. His message was clear:
“It's not about tracking more metrics, it's about solving real, day-to-day bottlenecks that waste engineers’ time.”
Framing the Right Questions
Like many teams, Acceldata evaluated industry benchmarks; DORA metrics, SPACE framework as well as Engineering KPIs. There’s no shortage of frameworks out there – each promising to quantify developer productivity.
But here’s the problem: these models often assume a mature, stable process and baseline that doesn’t reflect the chaos or ambition of a growth-stage company. And with hundreds of metrics to choose from, it quickly becomes overwhelming.
Worse, they don’t reflect how work actually happens.
So the team went back to basics.
What does developer productivity actually mean?
Because let’s be honest- developer productivity is hard to measure. How do you measure productivity of knowledge workers? A developer may be more productive in 4 focused hours than working 12 distracted hours. So coding hours, lines of code and many such metrics are just report cards rather than giving any practical direction to improve velocity.
The real question was: Where is developer time being wasted?
And from there, they started asking the kind of questions that anyone running a software team should be asking:
- Can any developer create a build on their own—and how long does it take?
- Can they test code locally, without waiting?
- Is quality assurance automated and accessible?
- Are developers waiting for shared QA environments to get free?
- And how many manual steps still stand between a commit and production?
Ashwin's view was that answering “yes” to these questions is a better proxy for productivity than any single metric. These questions formed the blueprint for how Acceldata approached improvement.
Once they started answering these, the conversation shifted from improving metrics to eliminating waste.
They also noticed another pattern: things were piling up at the tail end of the SDLC. Builds, tests, approvals, all clustered toward release time, requiring re-work and dragging down velocity.
Acceldata then laid down the principles and designed systems and processes to improve developer productivity.
Building the right systems with right principles
Acceldata’s principles revolved around close observations of developer friction and wastage -
- Availability of compute cannot be a bottleneck to velocity
- Automate everything
- Everyone can, should and must be able to deploy - Dev, QE and even PMs and Documentation team
- No manual intervention from commit to production
With these principles in mind, Acceldata built internal platforms; namely KAASMOS and Sentinel to provide developer autonomy and reduce friction.
With KAASMOS, any engineer could spin up a full-stack Kubernetes environment on demand—no Ops ticket, no waiting. This required engineering efforts for e.g., to boot up an environment < 5mins. Many companies shy away from developer environments assuming it is cost prohibitive. However, with right engineering investments, Acceldata could run 80 environments at a given time with monthly cost < $5000.
“CPU is cheap, context switching is not!”
With Sentinel, everything from builds and tests to security scans and releases moved into a single, self-serve platform. Everyone can see what is happening and what is blocked. Many failures that used to get detected later in the SDLC stage and caused the teams to scramble, now get captured early.
Achieving Developer Flow State
This is where things really changed.
With the internal platforms in place, developers moved with purpose. They were no longer dependent on Ops or waiting on approvals. They had the autonomy to build, test, and ship on their own terms.
They could control their own workflow—from the moment they wrote code to the moment it went live.
Automation took over the manual, repetitive tasks, things that used to steal hours of focus. Developers weren’t stuck doing Ops work anymore. They were doing their work.
And security? It wasn’t an afterthought anymore. It was just part of the flow. Every build came with integrated scans and checks, so issues were caught early when they were easier (and cheaper) to fix.
Over time, something even bigger started to shift: the culture.
Because the tools were built around how developers actually work. The workflows made sense.
And because everything from tests to releases to sign-offs lived in one place, collaboration became way easier. Everyone could see what was happening.
Lessons for Engineering Leaders
Acceldata’s story is a blueprint for any team looking to increase velocity in a demanding, enterprise-grade environment. A few core takeaways:
- Start with common sense. Focus on eliminating obvious bottlenecks before layering in complex metrics.
- Invest in foundational infrastructure. Reliable, on-demand environments are table stakes for speed. Often, compute is cheaper than the developer wastage.
- Build for your process. Tools should reflect how your teams actually work,not how a vendor thinks they should.
- Reduce developer waste. TicketOps, manual testing, and waiting for environments are all forms of productivity debt.
- Keep communication tight. When introducing new systems, clear rationale and visibility are key to adoption.
Final Word
Acceldata didn’t achieve enterprise-grade delivery velocity by cutting corners. They did it by investing in the right foundations, platforms, processes, and principles, that empowered their teams to do great work at speed.
Their experience shows that even in highly regulated, high-stakes domains, it’s possible to move fast and maintain quality, if you remove the friction and build for your developers.
Watch the full conversation with Acceldata’s CTO, where he breaks down the exact tools, decisions, and mindset shifts that made this transformation possible.
👉 [Access the on-demand webinar now] and see what it really takes to build for speed and scale.
