tl;dr 📖
I had a cushy job at Uber—decent work, great people. But the red tape was overwhelming. Too many approvals and permissions made it hard to get things done. I wanted to build and deliver great stuff, not wait for basic approvals from a dozen people every time something needed to get done. And Uber’s dev productivity measures at the time didn’t make sense either.
When talking to managers didn’t help and I couldn’t make an impact soon enough, I decided to leave and tackle it from the outside.
“Free of the shackles!” They say…
Now, the longer version…
The Comfort of Uber 🛌
Once upon a time… as a tech lead, I had everything: Good income, interesting work, and recognition. But something was missing. The work, while important, wasn’t fulfilling enough. It often took too long to deliver most things. And the metrics used to measure developer productivity felt gameable and inadequate, and didn’t always reflect true impact.
Leaving that cushy, high-paying job at Uber was one of the toughest decisions I’ve ever made (I took months to decide).
The Uber Office S01E01 🏢
My first project at Uber was kickass, and all my managers at Uber were great. In fact, in my personal experience I loved all the people that I got to work with. Friendly. Skilled. Considerate.
And the project was something that I had to build with my small team almost from scratch. It had a great focus on accessibility, a lot of design effort behind it, just the kind of project I would love to be a part of.
And because it was something being built from scratch, there wasn’t a lot of past baggage to carry along. Not many “approvals” were needed from outside the core team. The planning, design, execution was contained within the “inner circle”. That meant collaboration was super fast, and so was the execution.
But it wasn’t meant to last.
And then the honeymoon period ended…
Not everyone’s experience was similar, and my subsequent projects were not that interesting either. For most people it was minor features or maintenance work. Even if they were mid-sized features, I was one among thousands of other devs and the initial awe wore off pretty quickly. It felt like if I was missing for a couple of says, or on leave for a week nothing would really be affected significantly. I didn’t like that.
It’s not like I was underperforming either. I must be performing great because it reflected uniformly in my feedback cycles, appraisals, and the fact that I was given an “impact award”.
It just felt like despite all that, I wasn’t doing the kind of thing I wanted to do.
The Red Tape 🔴
A large company is like a large heavy ship. It’ll go where it needs to but it’ll take time, and it’ll definitely change course super slowly.
At Uber, they had THOUSANDS of codebases. Over time the internal “reviewer” configuration would be updated to add new reviewers to the list, often without removing the older ones or those that aren’t relevant or involved in that codebase anymore only being handled on a case-by-case basis.
Uber also has the amazing concept of ERDs (not unique to them of course). Which are basically PRDs but very engineering and implementation specific. But this idea too was slowed down by the bureaucratic processes and the number of people that needed to be involved eventually.
Things would spend WEEKS in this phase! Sure, this allowed for some very solid and thought through implementations, and a company like Uber could suffer the delay for a more robust implementation. Except…
There was no one to verify if the implementation actually matched the documentation.
Good intention, but not well adhered to.
“One day, I want to be the kind of dev who goes through 5 steps of red-tape before delivering code!” — Said no one ever.
Everything changed when the Metrics Nation attacked 🔥
In the first half of my time there, annual reviews took a while to happen. Managers and other team leads would form a panel and manually try to gather data to evaluate devs by the numbers.
I did not know at this point what the metrics were, or how much they were weighted. What I know is that there wasn’t much in the way of automations involved, it was a fairly manual process (this changed later).
Interpersonal feedback and direct evaluation by the manager held a significant weight, and the whole process in general felt fairly transparent. I was okay with that. But then, efforts were made to automate this process…
Dashboards were created to track the stats of individuals across various teams.
And… One of the things being measured was line count and number of PRs per month. 😱
Yeah… it’ll take you 0.01234 microseconds to realize how this is a bad idea. Within days devs were artificially inflating PR count, splitting PRs when they didn’t need to be to inflate this count.
I don’t blame them. 🤷
So, I tried to sort it out 💪
I’ve always liked solving problems. I do puzzles in my free time, often play strategy games on my PC (when I’m not shooting Nazis in Wolfenstein, or save my cabbage patch in Stardew Valley).
I often solved problems that affected me or my team in terms or developer experience, productivity, documentation, etc. usually by going out of my way. I found it fun. 🤷
And I’ve always been a pretty passionate dev. I care about what I build, and I care about my fellow devs. Naturally that extended into caring about the evaluation process.
When automated dashboards came into play for evaluating us devs, naturally we started talking about it, increasingly frequently over time because the metrics used for that matter felt so flawed. And talking to leadership about it changed nothing in the time I remained at Uber.
Gameable Metrics
🗓️ At this point, we’re in the 2nd half of 2021 🗓️
The metrics used to measure developer productivity often felt more like a game than a true reflection of work quality. Promotions were sometimes based on these flawed indicators, leading to frustration. I felt super tempted to make smaller related changes in separate PRs when normally I may have not. It felt fake.
Some specific things measured were:
Number of PRs per month
Devs started making smaller than needed or more frivolous PRs
Devs started making PRs for older low priority things if their PR count was running low
Some PRs started to be approved by friendly devs in the same team to inflate PR count
Line count per PR
Devs started writing more verbose code
Extra newlines
Unnecessary refactors
Of course, not all devs were okay with doing this. But some were, especially those that had low numbers on these stats. Often the numbers might be low because they are working on something that involves more planning, design, or documentation involvement. But that wasn’t captured on these dashboards.
We talked to leadership about it, specifically about how this is possibly more harmful and the previous way of doing things seemed better and while it seemed like they agreed, nothing really changed.
And this was a time when I was already increasingly dissatisfied with my time at Uber…
That brings us to 2022 🗓️
The Idea of Middleware
Around this time, Dhruv pitched me the idea for Middleware. The concept was intriguing: a platform designed to enable developers to ACTUALLY do their work, highlight what prevents them from doing what they love, bottlenecks, process blockers, etc.
The first thing that jumped to my mind was…
“If I had something like this to show insights to my manager, it would be so much more helpful than whatever they are doing right now.”
After several months of discussions and consideration, in August 2022 I finally decided decided to take the leap and join the man on this journey. The decision wasn’t easy, but it felt right. 🚀
This was just 2 days after my birthday too! 🎂
The Startup Hustle
Building a product from scratch is tough. We had to sift through tons of data and present it clearly. We understood that not every metric matters; only show what’s useful and actionable.
Our goal was straight-forward?
Build something our past engineer-selves would find sensible.
Building the right team was crucial, and a continuous effort. Big lessons in leadership, team dynamics, and company culture were learnt. Turns out, NERF was the answer to almost everything. 😂 jk, jk.
Growing a company meant dealing with finances, marketing, compliances, and of course customers. It was a huge learning curve beyond my Uber days.
Reflecting on this journey, I can confidently say it was tough but gratifying. Building something meaningful outweighs the comfort I left at Uber, yet it would have been a LOT MORE DIFFICULT without the support from my wife, Mehak.
And yes, I’d do it again in a heartbeat. 💗
Psst.
If you want to check out what we’ve been building, here you go. It’ll mean a LOT to me if you could leave a star on the repo. 😄
✨ Open-source DORA metrics platform for engineering teams ✨
Open-source engineering management that unlocks developer potential
Introduction
Middleware is an open-source tool designed to help engineering leaders measure and analyze the effectiveness of their teams using the DORA metrics. The DORA metrics are a set of four key values that provide insights into software delivery performance and operational efficiency.
They are:
Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.
Table of Contents
Installing Middleware
Troubleshooting
Using Gitpod
Using Docker
Manual Setup
