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 ...
For further actions, you may consider blocking this person and/or reporting abuse
When engineers are boxed into corporate scut-work, that's when innovation starts dying. We create, because we can!
Same as Martin, couldn't have said it better. ❤️
Couldn't have said it any better Eshaan! To be an engineer is to be wild with ideas.
Hi Jayant, thanks for the article. I totally get your disgust with vanity metrics (#PRs and #LOC), but a bit surprised that you use these metrics to rank contributors to your own project: github.com/middlewarehq/middleware... . How about dogfooding DORA instead?
Amazing catch, @sashaov. That's indeed an oversight.
We should change our widgets to show Dora relevant stats instead!
Great article. The issue with corporates is whenever they implement new process is super difficult to change it.
Side question: Did you manage to sell your SaaS to Uber?
PS. I read your article on my YT channel - youtu.be/CVsWUwchabU
We've not tried yet.
Someday perhaps, but right now we're making sure it works for relatively smaller companies, and it seems like it does! 😄
It's not for everyone. Every engineering team works in a different way.
But engineering work itself is fairly similar, and that's what the goal is, to enable every dev to do what they love without being bottlenecked by the processes of their orgs.
When I was younger, I was always drawn to the allure of working in a large firm like Uber. But I’d heard loads of people say that they didn’t like this and even heard of people quitting cushy jobs not unlike yourself. I was never able to understand why, and this piece really helped bridge this gap to some extent. Thank you and all the best!
Epic & an interesting read Jayant, as always!
@jayantbh Should I join Uber?
🤣 well, now is a good time to introduce them to Middleware.
awesome content, : this is very true "not every metric matters; only show what's useful and actionable."
Absolutely! We've seen many people and alternative products show everything they possibly could, just because they could. We have been tempted to do the same because some of the data can be presented in such a fancy/pretty way. Isn't easy to hold back, but we try. 😄
Yeah... I completely understand the feeling. Good luck.
Thank you. :)
Wow, reading this post bring me so much calm. I've recently started working on a “big” company. I was expecting to learn how to write better code and a more polish way to track devs performance (compare to the previous places where I worked). And I'm living a really similar experience to you. I guess this is a pattern that repeats all across the industry. Thanks for sharing your experience
Yeah, I've heard similar stories in terms of getting things done from almost all my peers in the larger companies. Glad it resonated with you. :)
I remember one of my first meetings with you, asking if Uber was the best place to work at (because thats how I saw it back then). This article sums of the issues we discussed in that meeting along with why Middleware exists in the first place. If you use nonsensical metrics to track devs, they will always be gamed :")
I understand your point, but once your new company grows as large as Uber, you’ll likely see why they operated the way they did.
It often comes down to personal preference for engineers—they can either accept the challenges and focus on improving themselves, or keep switching jobs every few years, often staying with smaller or mid-sized teams. These kinds of issues will always exist in larger companies.
I’m not saying they were completely right. There’s always room for improvement in any company, and they should at least take steps to address these issues, even if they can't fully resolve them.
Oh yeah I don't disagree. I do think they could have handled things better, but again, a HUGE ship is super hard to steer quickly enough.
That just taught me that BigTech might not be for me, at least not in positions where up not in the upper half of the org hierarchy.
I completley agree with your counting code lines to judge top contributor is most way of doing this mark.
If possible for you to answer would you please share from your experience that what are the methods you think would be better to rank/mark employee. Specially in large org where It's to do this manually.
The mentality on devs to be glorified code labour is to blame. The management thinks of them as labours to churn out code that does what they want, and then use them to keep it going profitably, while trying to cut labour costs... go figure
That mindset is a bit more common than many people realize.
Though, I'd like to think that's not what a large portion of the engineering leadership at Uber thinks, but they did have a lot of process issues that made it difficult to incorporate feedback to their process changes.