I failed 3 times as an engineer and built my own startup

Hrishikesh Pardeshi

Co-founder, Product & Dev at Flexiple ($700,000 revenue) & Remote Tools.

Last updated on19 Feb 2024

I am a CS grad and worked as a software engineer for 3+ yrs at Adobe & Amazon before I went on to build my own startup, Flexiple. This is my story about what motivated me to do so.

#1: As engineers in large firms, we aren’t decision makers

Fresh out of college, I joined the research lab at Adobe. My very first project was to evaluate the performance of all video codecs and suggest the best encoding software for our e-learning suite of products.

Problem statement: Improve video quality possibly reducing processing power & memory.

If that sounds like Hebrew to you, so it did to me back then. Forget evaluating performance, I didn’t even know terms like codecs, containers, extensions and what was what. For reference, mp4 is a file extension while MPEG4 is a container and x264 is an implementation of the H264 standard for codecs.

I hadn’t taken a single class in signal or video processing and yet I was tasked to figure & recommend the best encoding practices. But that’s what an engineer is supposed to do, right? You don’t get additional time to learn or take a course, you’ve to figure things as you work your way towards the final output.

So did I. I implemented small POCs, did a codec showdown and presented my results. x264 emerged as the clear winner and I ended up making a small wrapper on top of it as a demo on how to use the x264 API.

It was fun till this point and I was looking forward to seeing my work impact our products. But I learnt one of the most important lessons in my life. As engineers in large firms, we aren’t decision makers. We’re often tasked with doing things that may never end up anywhere.

When I consulted our licensing team, they weren’t happy with the price. And in just a single day, my work spanning months turned into a failed experiment.

#2: What eventually happens of your engineering work shouldn’t concern you.

Back in 2013, Apple was very restrictive about what apps could do. Screen recording was prohibited in any manner possible. And screen recording, as it turns out, was a key feature of our product for which we wanted a native iOS app.

So my next assignment was to hack iOS private frameworks, build a POC and show that it’s possible to record everything on Apple devices. Why? So that we could then make a proposal to Apple (on behalf of Adobe) asking to open up these private frameworks exclusively for our app.

Now, you might rubbish this approach saying Apple won’t make exceptions for anyone. Well, it actually does (or did back then, as I was told) for popular Adobe products like Photoshop, Premiere etc.

But forget hacking iOS, I didn’t even know basics of iOS or mobile apps or what Jailbreak means. I learnt all that and built an iOS app figuring out the right methods in the private frameworks & how to use them.

My manager & our director were delighted to see the app in action. I was then introduced to our product manager who would work with me to prepare the proposal for Apple.

Now all of that sounds important or fancy, or at least it did to me back then when I was told this. But in reality, this is what happened. I was asked to share an apk and file a request on a portal which would be attended by someone from Apple. No one knew who that someone will be.

So I did file that request and immediately after, I was given my next assignment. I never got an update on that request, and I had no way to follow up on this. Neither did anyone from our org follow up or take further action about this. My job as an engineer was done and whether that request gets approved shouldn’t be concerning me.

#3: If you’re part of a star product in your company, you are less likely to face resistance.

So by now, all of my research had been failed attempts. And there was no way to evaluate my performance objectively or in corporate language, I had no KPIs. So I was given KPIs and had to deliver on either of the following to be deemed successful for my future projects –

1. Solve a problem in one of the existing products such that a feature actually gets shipped. We had a year long shipping cycle then which means a major release happened only once a year.
2. File a patent for your research.
3. Publish a research paper.

All while considering that final decisions on what happens with my work mostly don’t rest with me.

My next assignment was rather open ended. I was tasked with researching on gesture recognition from the physical world, much like what Microsoft Kinnect does, and translating these gestures into actions on mobile devices.

I spent a good amount of time researching about gestures and coming up with a system to recognise these aerial gestures. While the setup itself was a little clumsy, we realised that it was something of value and should be protected.

So we filed for a patent. The usual process is – you have an internal portal where you submit your application/ research, if it gets approved, what remains is mere paperwork on part of the company.

We were positive this would go through but by now you would have guessed it didn’t. The reason isn’t usually revealed but a score out of 5 is. We had filed for 2 patents and got scores of 2.25 & 2.75 whereas the success cut-off was 3.

Now here’s what I was told. The tough part is to get your business group to agree to file an application. Most times, your superiors won’t let you file an application in the first place. But if an application is filed (and it needs team approvals), it represents an application on behalf of your team/business group. So I was surprised when both the applications got rejected, especially when my manager was also one of the authors.

That’s when I realised the concept of company priority. Not all products or business groups are equal. If you’re fortunate to be part of a cash cow or a star product of your company, you are less likely to face resistance.

Nonetheless, there’s some happy ending to my story. I did publish a paper based on this research and a second paper for another project. My work on the latter project also became part of our product’s official release – here’s the demo video. I was the one who built the research POC & also implemented the feature in the final product.

However, these experiences taught me something invaluable. You never get to be the boss of what you do when you’re part of a large organisation. And while this may be fine for some, I decided I won’t take it and I quit to build my own startup.

I document my journey regularly on Twitter. You can follow me there to know more about what I do now.

Also, if you would like to read how fast I am able to make decisions and execute things, check out this thread about how I built a community website from scratch in 7 days.

I always recommend working on your startup on the side, while continuing your full-time job. Take the leap only when after you see initial traction. One of my friends did the same with her website, Writer Alpha.