From Junior Dev to Team Lead: Lessons from a Global Project

The first software company I worked with was working on a CMS for used car dealerships. There are many first-world companies who have their technical bases in third-world countries. One of the major problems they face is not having technical support during their working hours because of the time difference between two countries. And that was the most important issue the company I worked with had as well.

Their Challenge

Someone had to work at nights in Iran in order to support clients in Canada during Canada’s mornings. Not resolving technical issues on our clients’ websites or panels could lead to them losing their clients and consequently to us losing them. This is how serious it was.

Now what was the issue? Working with Canada’s hours for someone living in Iran meant working from 8PM to 4AM, 6 days a week, without any holidays. Developers would accept that position at first because it had twice the usual salary for a dev in Iran. But then they would quit within a few months because of the high pressure.

It was a demanding role. While working twice the usual workload a developer had, you had to be able to switch between tasks very fast in order to manage the priorities. And just imagine handling all of that at night!

My Approach

When they asked me to accept that position I was hesitant for 2 major reasons. My first concern was that I was always an early bird. I was 20 years old and I had rarely stayed awake after 12AM. My second concern was regarding my experience and skills. I was a frontend developer who had just 2 months of official work experience. While they needed a senior fullstack engineer for that role, to handle supporting the software end to end.

All of that said, they decided to trust me because they had seen my performance doing frontend tasks and were happy with the results. I appreciated their trust and decided to put my best into that position. Before accepting, I even did research on how to handle night shifts. But I learned the rest on the job. Things like:

• Time management
• Task coordination with remote team members
• Setting up systems for repetitive tasks
• Handling workloads based on priorities
• And even backend development

Results

Before I knew it, I’d handled that position for more than a year. Besides, our clients’ satisfaction rate improved by 70% during that time. Because of that, I was offered another contract with 4x the salary I had started with. These results weren’t just because I worked so hard. My main goal was to work smart and build something that others could continue even after me. So I established some guidelines for the development process that improved both the quality and speed of our work.

Why Quit?

I eventually quit that position to start a more challenging and fulfilling journey by being a technical partner for non-technical founders who wish to build their own software business. I figured out that many brilliant software ideas that could make the world a better place die just because founders aren’t sure how to build them. That’s the gap I’m trying to fill.

That means I’ll explain the why behind each technical decision in plain English and guide them to make the best decisions. This way they can avoid expensive mistakes and build what actually moves their product forward.

Want a cleaner reading experience ? Read this post on my website

Next up: “Most No-Code SaaS Apps Fail | Not for the Reason You Think” Subscribe to get it in your inbox next week.