What Leading Coachy Taught Me About Leadership, Code, and People

I didn’t set out to become a Tech Lead. Like many developers, I started out focused on solving technical problems, improving my skills in Ruby on Rails, shipping features, and keeping the CI pipeline green. But over time — especially while building and scaling the Coachy platform — I found myself stepping into roles I was never formally trained for: leading meetings, mentoring juniors, pushing back on unrealistic deadlines, and aligning business, product, and tech.

It started with small things: answering more questions, reviewing more code, and helping the team prioritize. Then came the bigger challenges — hiring, defining processes, and building trust across a distributed team working between Morocco, Saudi Arabia, and Worldwide. Eventually, I realized this wasn’t just about writing clean code anymore. I was responsible for building a team, a product, and a culture.

No one gave me a manual for this shift. The skills that made me a strong developer weren’t enough. And while I learned a lot through trial and error, I also made mistakes I could’ve avoided if someone had simply told me: "Tech leadership is not just the next level of coding — it’s a completely different game."

In this article, I want to share five key lessons from that transition. Whether you're an individual contributor eyeing the next step, or you’ve recently found yourself leading others without feeling entirely ready, I hope these insights will help you navigate the journey with a little more clarity than I had.

🔑 Lesson 1: Code Is Only Half the Job

Before becoming a tech lead, I used to think success was about writing clean, efficient code and pushing features quickly. And while those things still matter, they’re no longer the center of the job. As a tech lead, you start realizing that your biggest contributions often happen outside the codebase.

Now, I spend more time answering questions than committing code. I review others’ work, unblock team members, write planning documents, and align with product and business. There are days when I don’t write a single line of code — and yet, I go to bed knowing I moved the product forward.

One moment that made this shift clear to me was during a sprint on the Coachy platform. We were under pressure to release a new feature that coaches had been asking for — dynamic pricing for sessions. I had a clean, elegant solution in mind, but it would take extra time. Instead, I opted for a quick and reliable MVP that got the job done with minimal risk. Was it pretty? No. Did it work for the user? Absolutely.

That’s when I realized: being a good developer is about solving problems elegantly. But being a good tech lead is about solving the right problems at the right time.

It’s not about how clever your code is — it’s about how clearly you can think, communicate, and enable your team to execute.

🧭 Lesson 2: Your Job Is to Build the Right Team, Not Just the Right Architecture

When I was a developer, I took pride in being the go-to person for complex problems. If something was urgent or sensitive, I wanted to handle it myself. But as a tech lead, that mindset quickly became a bottleneck.

One of the most important lessons I’ve learned is this: you don’t scale by being the smartest person in the room — you scale by growing others. Your job is to build a strong, self-sufficient team, not to hoard the knowledge or be the only one who can “fix it.”

At Coachy, we started with a lean team. In the early days, I was setting up the backend logic, shaping the front-end structure, handling third-party integrations, and making key product decisions. I wore many hats, because there was simply no one else to hand them to.

But I knew we couldn’t scale that way. So I gradually started handing off responsibilities — first the simpler, repetitive tasks, then the more critical areas. I spent time pairing with junior developers, improving our documentation, and creating an environment where ownership was expected, not requested.

Was it more efficient? Not immediately. In fact, there were moments when I knew I could do a task faster myself. But I stuck with it. Over time, I watched those same engineers grow — they started anticipating problems, suggesting better solutions, and taking real initiative. Some of their ideas even reshaped parts of the product roadmap.

That’s when I realized: the best tech leads make themselves less essential to daily operations, not more. You move from being the engine to building the engine room.

And the best part? You don’t just build better software — you build a team that believes in itself.

🤝 Lesson 3: You’re the Bridge Between Business and Engineering

As a developer, I used to see product requirements as tickets. Clear or vague, I just had to make them work. But as a tech lead, I learned that translating business needs into technical reality is a huge part of the job — and it’s rarely straightforward.

You sit between two worlds. On one side, stakeholders are talking about growth, urgency, and customer expectations. On the other, your engineers are focused on scalability, edge cases, and clean architecture. And your job? Make sure those two worlds actually understand each other.

At Coachy, this became especially real when we started expanding into new markets and adapting features for coaches across Saudi Arabia and Morocco. Product wanted speed. Engineers needed stability. I had to explain to non-technical decision-makers why rushing a release could cost us more in the long run — and also help developers understand which compromises were acceptable, and why.

One moment that stuck with me: we were planning a calendar and session flow redesign. The team wanted to rebuild the logic from scratch (with good reason — the old code was messy). But product needed results fast. Instead of picking a side, I facilitated a solution that involved refactoring just enough to improve maintainability, while still delivering what users needed on time.

That’s the real job: negotiating trade-offs, aligning priorities, and making the invisible visible.

You don't just write code anymore — you shape conversations. And often, that’s where the real impact is made.

🌍 Lesson 4: Remote Leadership Requires Intentional Communication

Leading a remote team isn’t just about sending Slack messages and scheduling Zoom calls — it’s about creating clarity, trust, and rhythm across time zones, cultures, and working styles.

At Coachy, our team was spread across Morocco, Saudi Arabia, and sometimes Belgium. That meant we couldn’t rely on spontaneous desk conversations or quick syncs. Everything had to be more deliberate: priorities, deadlines, and expectations needed to be written, not assumed.

I quickly learned that silence in a remote team doesn’t mean everything is fine — it might mean someone is stuck, confused, or unsure who to ask for help. So we set up lightweight rituals: clear weekly planning, async updates, and documented decisions in Notion. I also made time for regular 1:1s, not just to talk about tasks, but to check in on morale and unblock quietly growing frustrations.

It wasn’t always perfect. Sometimes, messages got lost in translation — literally and figuratively. But over time, we built a shared language and culture. We started trusting each other more. Team members felt safer asking questions, pushing back, or taking initiative.

Leading remotely taught me this: you’re not just managing tasks — you’re designing the environment in which people work. And the way you communicate shapes that environment more than any tool or process.

🧠 Lesson 5: You’ll Doubt Yourself — Lead Anyway

Impostor syndrome doesn’t magically disappear when you become a tech lead. In fact, it can feel even stronger — you’re suddenly responsible for decisions that affect people, products, and business outcomes. The stakes feel higher, and the questions multiply: Am I the right person for this? Am I making the right calls?

I’ve faced those doubts many times during my journey with Coachy. Sometimes I’d second-guess a technical direction. Other times I worried about whether I was supporting my team enough. But what kept me going was remembering that leadership isn’t about being perfect — it’s about showing up and owning the process.

You don’t have to have all the answers. You just have to be willing to listen, learn, and course-correct when needed. Being transparent about your uncertainties can actually build trust — your team will appreciate your honesty and openness.

If you’re feeling unsure, know that’s normal. The best leaders I’ve seen are those who embrace their doubts and use them as fuel to grow.

What I’d Tell My Past Self

Looking back at my time leading the Coachy platform and building a team across Morocco, Saudi Arabia, and Asia, I realize that becoming a tech lead was less about titles and more about growing into a role I never expected. It’s messy, challenging, and often uncomfortable — but it’s also one of the most rewarding journeys I’ve taken.

If I could go back, I’d tell myself to embrace the discomfort, be patient with the learning curve, and remember that leadership is about serving others, not just showing off skills. If you’re on a similar path, know this: it’s okay to feel uncertain. You’ll make mistakes, face tough decisions, and learn as you go. Each step is shaping you into the leader your team needs. Leadership isn’t about perfection — it’s about showing up, learning, and growing alongside your team.

If you’re on this path or about to step into it, know that you’re not alone. The road will test you, but it will also shape you into a stronger developer, teammate, and person.

Feel free to reach out if you want to share your own experiences or chat about tech leadership — I’m always happy to connect.