Dhruv is the Co-Founder & CEO @ Middleware. Founded in 2022, Middleware is building the productivity OS for engineering leaders to eliminate the obstacles that hinder tech teams, maximize developer potential and foster a more fulfilling work environment.
In this episode, we delve into the evolution of customer education in the AI era.
- How Dhruv turned a VP of Eng interview into middleware’s first paying customer in 15 days.
- The mission: an OS for engineering teams so builders build and leaders lead.
- Why bottlenecks form: rapid headcount growth without process maturity.
- Defining developer productivity: commitments met and friction removed, not lines of code.
Dhruv started coding at 5, studied CS at Delhi College of Engineering (DTU), and interned at HackerEarth, Mozilla, and OWASP. He scaled systems at Kayako and Shuttle, then led at Maersk in Copenhagen. After 50+ leader interviews, he founded middleware in 2022 with co-founder Jayant (ex-Uber). Angel round and first hires closed in Oct 2022; first revenue hit on Dec 26, 2022.
Listen On
Episode Timestamps
- 00:00:00 Intro
- 00:00:46 On Middleware
- 00:02:06 Engineering Culture
- 00:03:57 Customers
- 00:05:04 Dhruv
- 00:08:05 The Joy of Building
- 00:11:58 Before Middleware
- 00:18:44 Friends and Family
- 00:20:55 Beginning of Middleware
- 00:23:55 Managing Seniors
- 00:27:04 Developer Productivity
- 00:29:43 DORA Metrics
- 00:33:30 Middleware Product
- 00:38:57 Internal buy-in
- 00:42:58 Should metrics play a role in appraisal?
- 00:44:56 Thoughts on AGILE
- 00:47:34 10 Year Vision
- 00:48:08 Insights
- 00:51:25 Developer Tools
- 00:52:54 FOSS Middleware
- 00:55:58 FOSS vs B2B SaaS
- 00:57:35 Addressable Market
- 00:59:27 Tech behind Middleware
- 01:01:05 Customer stories
- 01:02:34 Work-Life Balance
- 01:03:36 Impact of Gen-AI
- 01:05:04 Use cases of AI
- 01:06:45 AI tools
- 01:07:47 Advice for students
- 01:10:58 Mindset
- 01:19:13 Detecting culture fit
- 01:21:54 What’s next for Middleware
About Dhruv
Dhruv is the Co-founder of middleware, founded in 2022. middleware is building an OS for engineering teams, unifying Jira, GitHub, calendars, and CI/CD to remove delivery bottlenecks.
Full Transcript
Dhruv:
Someone called me for a VP of Engineering interview, and I thought it might be a good opportunity. I went for the interview and told them I wasn’t there for a job. I showed them the wireframes of what I’m building and asked if it could be useful. They said, if you build this in fifteen days, we’ll take a look.
Aditya Anand:
Thanks so much for doing this. I’m excited to learn more about you, Middleware, and your journey so far.
Dhruv:
Thank you, Adi, for having me. It’s a privilege and an honor to speak with you.
Aditya Anand:
Tell us about Middleware. What is the mission of the company?
Dhruv:
At Middleware, our mission is to become the OS for engineering teams. We want builders to build, and leaders to spend more time on strategic and technical work, instead of the constant firefighting we see today that leads to delays and dissatisfaction.
To answer why, I’ll go a step back. As engineering students, we dreamt of building something that would change the world. Many of us join large companies to do impactful work, but soon get stuck in bureaucracy and process, spending more time talking and reporting than building. We started Middleware to fix that. As a product company, we help teams reduce time to market by removing process bottlenecks, leveraging their existing tools like GitHub, Jira, and Calendar.
Aditya Anand:
In my experience as an engineer and engineering manager, builders constantly say, let us build. Can you describe the current engineering culture across startups? Where does Middleware come in?
Dhruv:
In a decently sized company, there’s a hierarchy: CTO, director of engineering, managers, then engineers. Ideas percolate down from product and leadership. Once ideas are ready, we plan a sprint. The steps are finite: plan, program, review, deploy, release, and monitor-rinse and repeat. Apart from coding, every step is collaborative, which means aligning people and timing, and that’s where bottlenecks form.
Many teams grew rapidly during the last decade of abundant funding. Growth wasn’t always organic, so there wasn’t time to set up the right processes. That turmoil creates bottlenecks, delays, and missed goals.
Aditya Anand:
What kind of customers are a good fit for Middleware?
Dhruv:
We’re fortunate to be industry- and size-agnostic. We’re best suited when a company has a middle layer-CTO or director, engineering managers, then engineers-because that’s where visibility problems start. Smaller startups are short on people, money, or time-often all three. As you grow to around 50 people, you have capacity, but not a smooth delivery process. That’s where Middleware helps. We become your co-pilots when you’re the agent of change, transforming the team into a smooth delivery machine.
Aditya Anand:
I’d love to learn more about you. Tell us about your beginnings and your childhood. Any formative experiences that shaped who you are today?
Dhruv:
Of course. Before I dive into my journey, I heard Zakir Khan say that everyone’s life is like Slumdog Millionaire-you don’t know what shaped you until you’re on the hot seat answering questions. I feel fortunate about my journey.
I was brought up in a middle-class family. We didn’t have many limitations on what to wear or eat, and I grew up in an educated household, but we didn’t have surplus. My mom is a computer teacher, so I got access to a computer very early and started programming when I was five. Through school I was the nerdy kid who couldn’t play any sport, but I was very good with computers. I still cherish the all-nighters before school.
Early access to the internet and programming made me fall in love with building. I dabbled in programming, animation, security, and more. Back in the Yahoo Messenger days, chat rooms gave me exposure to what people around the world were doing. I participated in online hackathons in class eight or nine with people worldwide.
I once told my father I wanted to get into Harvard, just because a geography chapter said it had an 8,800-acre campus and was the best university. He said, we can’t afford it-don’t think about it. I went back to prepping for IIT. I attended Delhi College of Engineering (now Delhi Technological University) and studied computer science. The rest of the journey you can cover with your questions.
Aditya Anand:
You mentioned you’re happiest when you’re building. Can you share examples of things you’ve built that brought you joy?
Dhruv:
Many. Chronologically: in class four, we went to Jaipur. We’d just bought a digital camera, and I was on duty to click the right arrow to show photos to guests. I disliked the job, so I created a website with an auto-scroll gallery for our trip photos. That was my first purposeful build.
In college, platforms like CodeChef ran long contests. I noticed people mostly cared about the ranks of friends, not global leaders like tourist. I built a Chrome extension called Stockcoder that created personalized league-style rank lists. It became popular in our hostel.
When prepping for interviews with GeeksforGeeks, the site experience was poor, and my Core i3 laptop would crash after opening several tabs. I built a Chrome extension overnight called Geekometer to mark questions as done, color-code difficulty, and maintain revision lists. The site then appeared personalized wherever you saw it.
For traction, I anticipated people would check GeeksforGeeks during interviews. I went two hours early to our computer center and installed the extension on 250 machines. Whenever someone looked up a question, they’d see the extension, get curious, and install it later in the hostel. That grew to about 2,500 weekly active users across India. Now, of course, I’m building Middleware.
Aditya Anand:
Tell us about your roles before Middleware.
Dhruv:
At Delhi College of Engineering, I always thought about starting up but didn’t know how, so I chose to work with founders until then. I did internships across company sizes: a tiny team with one founder collecting people from hackathons, HackerEarth, Mozilla, OWASP, and then joined Kayako full-time in 2016.
I chose Kayako to stay close to startups rather than join a large company. It wasn’t a typical software engineer role. As a fresher, I was given a team and asked to revamp a poor, manual system into an automated one. I also worked across growth, sales, and call shadowing, which taught me a lot. Kayako was acquired, and my plan was to stick with the company if I wasn’t starting up.
I then moved to Shuttle as an engineer. The company was doing about 20,000 rides a day when I joined, and as it grew, the system wasn’t scaling. I was part of the scale-up team, became a manager at 24, and started with a team of three that grew to 13. I set up the Bangalore office in Embassy Golf Links.
Being 24, I realized managing by command wouldn’t work for me. My boss had a commanding presence; I didn’t. I had to learn the craft of managing: reading, talking to managers, understanding team dynamics. When COVID hit, chaos provided an opportunity to set up processes. Shuttle grew rapidly to about 100,000 rides a day before COVID. During lockdown we experimented with processes. I set a KPI to reduce meeting hours so no one on my team had more than 10 meeting hours a week. We achieved smooth processes, on-time deliveries, very high-quality software, and no attrition during COVID.
Shuttle was acquired in 2021. I moved to Maersk in Copenhagen as a senior engineering manager. I expected Europe to be more calm and process-driven, but I saw the same engineering challenges. Startups there also hired rapidly, yet output wasn’t even linear. I did 50 long-form interviews with engineering leaders worldwide, saw common patterns, and that’s when Middleware was born. I returned to India in March 2022 to start it.
Aditya Anand:
What was your friends’ and family’s reaction when you decided to start up?
Dhruv:
At first, it was a no. There were tears and a lot of persuasion from my side. I was adamant because I’d talked about starting up for years. When I came back to India, my parents were shocked. My dad finally said, do it, or you’ll keep cribbing. That got me a buy-in from him. My mom and grandmother weren’t on board for a long time. Even last year they said I had a good salary and life, so why struggle? After they saw results and my happiness, they became supportive. Friends were supportive from day one; a couple even became our first angel investors.
Aditya Anand:
Tell us about the beginnings of Middleware. What’s the team setup like now?
Dhruv:
I came back to India in March 2022 and called my friend Jayant-now my cofounder-whom I’d worked with at Shuttle. He was a tech lead at Uber. He started contributing part-time while we figured out fundraising. We followed the best practice of selling before building.
Someone called me for a VP of Engineering interview. I went and said, I’m not here for a job; here’s what I’m building. I showed wireframes and asked if it would be useful. They said, build it in fifteen days and we’ll see. I came back, asked Jayant to help build the wireframes, and that’s how we got our first customer.
We iterated a lot. We made our first full-time hire on October 10 and closed our angel round in October. Coming from a middle-class upbringing, we were afraid to spend our own savings, but the ball started rolling. We made our first revenue on December 26. The Stripe notification was pure joy. Jayant later moved from Hyderabad to Gurgaon when we set up our office. Early on, without a team, I worked from wherever: Jayant’s home in Hyderabad or Bangalore for investor meetings. That’s how we started.
Aditya Anand:
Many high performers find themselves managing or leading people much more experienced than they are. Any advice for someone in that situation?
Dhruv:
It’s a blessing in disguise because it forces you to learn how to lead properly. Many cultures see management as authority-people will follow your commands-but today it’s not like that. People work at a company to become successful. It’s crucial to understand each person’s definition of success and make them successful while also making the company successful. Your job is to align both interests. That’s close to servant leadership: enable people and strengthen the relationship.
There are a couple of tips. I once bumped into Vineet Nayar, former CEO of HCL Technologies. I had just become a manager and asked for advice. He said: whenever someone reports to you, ask for the top three things that make their work life meaningful. People often don’t say money. Understand those top three things and take care of them. In return, make a pact: if you come to me with a problem, always bring a proposed solution too, and then we’ll collaborate. Following this has led to great relationships long after parting ways.
Aditya Anand:
Let’s get back to developer productivity. It’s a heated topic and means different things to different people. What does it mean to you?
Dhruv:
Productivity is achieving what you commit to. If you planned a morning jog and did it, you’re productive. For developers, it’s the ability to achieve what they intend for the day, week, sprint, or quarter. At an organizational level, you should look at the whole team, not individuals. Many conflate productivity with output, like lines of code, which doesn’t correlate to business outcomes. What matters is whether developers get blocked or wait unnecessarily. Remove those waits and blocks, and they’ll achieve more. As a manager, help increase capacity and efficiency. In short, developer productivity is when ideas smoothly become products without unnecessary blockers.
Aditya Anand:
Can you explain DORA metrics? Are there other metrics organizations should track to improve developer productivity?
Dhruv:
DORA metrics, developed by Google, are a popular framework for measuring software delivery performance. They’re best applied at the team level to help a team get better at getting better-not for stack ranking. DORA balances speed and quality with four key metrics:
Speed: 1) Lead time for changes-time from first commit to production. 2) Deployment frequency-how often you deploy to customers. Frequent deployments mean you can deploy on demand, fix issues fast, and iterate quickly.
Quality: 3) Change failure rate-how often deployments fail, reflecting quality processes. 4) Mean time to recovery (MTTR)-how quickly you recover when failures occur. Some teams start with great speed and poor quality or vice versa; DORA helps balance both.
Aditya Anand:
Tell us more about the Middleware product. How does it work, what do you need to set it up, and what insights can leaders get?
Dhruv:
We sit on top of your existing tools-from ideation to delivery-connecting Jira, Google Calendar, GitHub, GitLab, Bitbucket, PagerDuty, and more. We provide an end-to-end view of your workflow so you can see where flow gets blocked and where your team needs attention. Instead of leaders jumping from meeting to meeting and firefighting, they can open Middleware, see the signals, and focus on the right problems.
We solve two problems: saving time on reporting and meetings, and driving change. Many teams build metrics in-house and think that’s enough. Metrics are easy; driving behavioral change is hard. People won’t accept commands today. Even with metrics, managers may not improve them without buy-in, and developers won’t be motivated to change. We excel at helping teams take action on signals.
DORA is a signal framework. Middleware provides actions to improve those signals. For example, if PRs take too long because of reviewer bottlenecks, we identify contributors with similar codebase familiarity and suggest adding them as reviewers. That reduces PR review wait time-pure waste-without compromising quality. Managers and teams can self-organize, reduce delays, and move the core metrics.
Example: You’re a CTO of a 50-person engineering team facing delivery delays every quarter. One path: create spreadsheets, firefight, and miss strategic/technical work. Or: log into Middleware, see which teams struggle with spillage, drill down to causes in minutes, try targeted actions with managers and engineers, and use feedback loops to scale what works across similar teams.
Aditya Anand:
How do you drive adoption and get buy-in-for example, for focusing on DORA metrics or adopting Middleware-from team members and the business?
Dhruv:
Two common challenges: not everyone is data-driven, and engineering hasn’t historically worked with metrics like sales or marketing. Business buy-in is easier now because CTOs are asked for metrics in boardrooms. The tougher part is changing how management uses data to act. The key is choosing the right metrics, which depends on leadership clarity.
The most successful implementations have a leader with a clear end state for the next months or years. That clarity guides metric selection. For example, if you’re scaling from 200 to 400 engineers, you need a delivery playbook. If speed is the current issue, focus processes and metrics on speed, then move to quality. Problems occur when leaders seek answers from a metric framework without clear goals. Metrics are guiding lights, not directions. There are many metrics and it can be overwhelming. In Middleware, we isolate paths so you see only the relevant signals. We first understand a leader’s goals, then suggest the right metric system and help implement it. With a clear leader-EM, senior EM, director, or CTO-it’s much easier to drive change and get team buy-in.
Aditya Anand:
Should metrics like DORA or what Middleware provides play a role in appraisals or performance reviews?
Dhruv:
I don’t think so. Appraisals should focus on commitments versus outcomes, quality, scope of responsibility, peak performance, and behaviors like collaboration, leadership, and mentoring. Metrics are guides, not the game. Goodhart’s Law says if you make a metric a target, it ceases to be a good metric. People will game it, and you’ll lose direction. So I advise against using such metrics directly in appraisals.
Aditya Anand:
Agile methodologies, sprints, and tools like Jira are nearly universal. Necessary evil or is there another way?
Dhruv:
We need a method to the madness. Agile and DORA are great first steps in an org’s journey. Agile is one method, Jira is one tool for implementing it-just as Middleware implements DORA. It’s a necessary direction, but don’t follow it by the book. Every team has different context: size, industry, challenges, goals. Make processes bespoke.
I like that Agile creates consensus on what needs to be done (sprint planning) and a chance to revisit (retrospectives). Retros are the best tool I’ve found-promoting a blameless culture and continuous improvement. If a team follows nothing else, I’d still recommend sprints and retros, tailored to their context.
Aditya Anand:
What’s the ten-year vision for Middleware?
Dhruv:
To become the OS of engineering teams. The way we talk about Jira today-we want Middleware to be indispensable. We integrate with Jira and are on their marketplace, but our goal is to be the leader you can’t run an engineering team without.
Aditya Anand:
The founder journey takes you to the edges of a domain. You’ve gone deeper into developer productivity than most. What do you know now that you didn’t before starting Middleware?
Dhruv:
From a product background, I was always solving problems and didn’t fully grasp distribution. I’d build distribution before product-I learned that the hard way. I’d also advise founders to be more cash-rich. There are many playbooks, but every journey is bespoke.
On developer productivity, when I started there was mainly DORA and the SPACE framework emerging. I later explored the Flow Framework and value stream mapping. The space is still evolving toward better answers. I initially thought a novel approach would be quickly adopted, but driving change is one of the hardest things in organizations. Even within the same company, directors may resist exposing metrics if they’re comfortable with a black box. Learning to navigate that came later.
Aditya Anand:
Advice for a founder ideating or starting in the developer tools space?
Dhruv:
Don’t follow a rigid playbook. Focus on building the top of the funnel first. A common first-time mistake is selling to a handful of companies for quick wins. After ten logos, the eleventh is just as hard, and you still don’t know where the next customer comes from. If your ticket sizes aren’t huge, understand how to build a scalable top of funnel and then solve conversion step by step. Your GTM, pitch, focus, and even product design will sharpen around that.
Aditya Anand:
Middleware recently moved to an open-source model. What prompted the switch?
Dhruv:
Most engineering managers are promoted overnight and expected to perform flawlessly without training on people, project, or process management. Power dynamics prevent them from appearing weak, so they learn by making mistakes. We saw three key gaps: education, tooling, and access to community. We address education with content, tooling with Middleware, and we wanted to strengthen community.
Closed source involves accessing confidential data-even if we don’t touch code-which makes permissions slow and trials difficult. We decided to open our core to make the first step easier. DORA, as we discussed, is a great first step toward engineering productivity. We open-sourced the core around DORA metrics to help teams understand signals, and we’re building a community so new managers have both tooling and community for free.
Aditya Anand:
Pros and cons of the FOSS model versus a regular B2B SaaS model?
Dhruv:
Pros: Enterprises can try the product locally without friction. Trust increases because the source is visible. You get broad feedback from the community, and sometimes contributions. Pros for the business: teams can do a POC themselves, often compare us with closed-source competitors, and come to us with strong intent, shortening sales cycles.
Cons: You expose your code and must hold a higher bar for code quality. Maintenance overhead is higher, and you’re more responsible than with closed source.
Aditya Anand:
How do you think about the total addressable market for dev tools or developer productivity?
Dhruv:
TAM is always a gray area. Roughly, there were about 26 million developers last year, growing around 10–11% annually, so 40–45 million in five years. We aim to be the OS for that market from the management side of productivity and tooling like CI/CD. Even focusing on just these two, the market is large.
A Stripe study suggested about 30% of developer productivity is lost to inefficiencies. If you take 30% of an engineer’s salary times tens of millions of developers, it’s huge. Depending on region and assumptions, reports estimate developer productivity and tooling at roughly $25 billion today.
Aditya Anand:
There’s a lot to build. Tell us about the tech that powers Middleware.
Dhruv:
We’re a web app with three layers: the client, a backend-for-frontend (BFF), and an analytics server. We’re fully on AWS. The frontend is React with TypeScript. The backend is Python; we’re moving to FastAPI. Early on, as a solo developer, I used AWS Chalice, which lets you write Flask-like code and deploy with one command. It wires API Gateway to Lambda, adds S3 and SQS listeners-so you can stand up infra without writing IaC or having a DevOps engineer. We use RDS and Redis as well.
Aditya Anand:
Any memorable customer journeys?
Dhruv:
Our first onboarding at CyberHub stands out. I showed up in a suit, everyone started logging in, and logins failed. The night before, my cofounder had committed something and I hadn’t checked that morning. I asked for ten minutes, took off my blazer, got on a call with my cofounder, and we debugged it on the spot. We got the system up, onboarded the company, and that became our first check.
Aditya Anand:
How’s your work-life balance?
Dhruv:
I don’t seek balance. I don’t think anything great is built with perfect balance. For me, it’s sinusoidal. Right now, the startup wave is high. I do take breaks-thanks to my wife for insisting-but I love what I’m doing. Sleep is my main break. I could improve, but I believe in going deep in one direction, then recovering, and returning.
Aditya Anand:
With GenAI, LLMs, and tools like GitHub Copilot, the industry is re-examining developer productivity. What’s your view on the impact?
Dhruv:
It’s fantastic. Code generation and answers from models are impressive, and the ecosystem-LangFlow, LlamaIndex-is great. Technological shifts change hierarchies and org structures more than they eliminate jobs. The same teams will build more complex things in the same time. At 10,000 feet, employment remains similar, but output quality and complexity rise. I’m excited about GenAI.
Aditya Anand:
Any notable use cases you’ve seen make a real impact?
Dhruv:
Integrations. They used to take about a week; now we get a 70–80% head start. We feed documentation links to GPT or Gemini, get a solid scaffold, and developers integrate it into our codebase without exposing business logic. Personally, I use GenAI for documentation, social posts, and grammar. I still add my voice for authenticity, but company-wide, communication quality has improved significantly.
Aditya Anand:
What about GitHub Copilot-real value or just better autocomplete?
Dhruv:
It certainly adds value, especially removing boilerplate, which aligns with our mission to remove friction from building. One caveat: it’s easy to generate more code than needed, which shifts load to reviewers-but AI code review agents are improving. We’ll find balance. Copilot adds immense value.
Aditya Anand:
Career advice for a late-stage student or early professional in tech: I think software salaries will normalize closer to other engineering fields. How should they think about their future?
Dhruv:
I agree. As skills commoditize, compensation equalizes. My advice: seek special knowledge. If you start in software but go deep in a domain-biotech, space, chemical-you’ll have rare, nuanced expertise. If all you bring is “I know Python,” that’s easily replaceable, and GPT has the basics. Go deep in a vertical and let software be the means.
If you want to build core technology itself, focus on new technologies, model quality, and the math behind them. If you enjoy building products, go deep in a domain. Either way, depth creates durable advantage.
Aditya Anand:
Mindset advice for a developer in an early-stage startup that’s now growing-more processes, planning, structure. How should they approach the change?
Dhruv:
Two scenarios. As an individual developer, give visibility. Tools like Jira aren’t for micromanagement; they’re for teammates who don’t know you yet to understand your progress and help you, and vice versa. Be a team player: review PRs so others review yours, unblock others, welcome and mentor new members.
As a new tech lead or manager, remember the business cares about delivery, not process. Processes should serve delivery. Remove anything that hinders you; adopt what helps. Do retrospectives every two weeks: what went well, what didn’t, where time was chewed, how to improve. Listen, spot patterns, and make changes.
Example: your delivery gets stuck at QA because there’s one manual QA while use cases are still evolving. Shift left: involve QA in planning to prepare test plans, let developers follow checklists, and smooth the path. Another example: ad hoc work keeps arriving and spillage rises. Set expectations: if ad hoc dominates, you can’t commit to the roadmap too. Ask product to prioritize: what should the team commit to? Commit within capacity, then improve estimation adherence and capacity over time.
Aditya Anand:
For a new joinee or someone interviewing: what probing questions reveal a high-quality engineering culture versus a dysfunctional one?
Dhruv:
Ask leaders: how do you imagine a developer’s day? Developers don’t code all day. Some days it’s an hour or two of coding and more planning; other days it’s deep focus. On average, I expect about four hours of coding, with the rest on planning, testing, interviews, and more. This shows alignment on expectations.
Ask how they think about flow and decision-making. Talk to developers about how they feel. Ask how the organization knows when it fails: do they have APM, alerts, and a culture to detect issues early? If there’s no way to know when things fail, the org will be reactive and prone to burnout. Depending on your goals, join a reactive org if you want to drive transformation, or a more planned, less reactive org if you want a better building experience.
Aditya Anand:
What’s next for Middleware in the next six to twelve months?
Dhruv:
Exciting things. As agents of change, we’re building more nuanced features for CTOs, managers, and-newly-for developers. Through the open-source community, we’ve gathered great developer pain points and are working on them. We’re also building GenAI integrations to answer leaders’ questions more directly. I’d love to share more as they launch.
Aditya Anand:
Excited to try it out.
Dhruv:
Thank you.
Aditya Anand:
Thanks so much for doing this. It’s always an educational experience for me as a technical leader. I’m excited to follow the rest of your journey.
Dhruv:
The pleasure is all mine. Thank you. It’s a lovely setup, and these were incredible questions. Thanks so much for having me.