Becoming a lead isn’t just another line in your resume, it’s a mental shift. It’s the moment you go from being a developer to someone responsible for your code and the entire team. Next, you’re also listening, mentoring, negotiating, motivating, and knowing how to find common ground even in challenging situations.

Today, I’m a Dev Lead at EXANTE. We develop internal services for a select group of internal stakeholders. But my journey started long before that — with informal leadership, a few mentorship flops, and plenty of lessons learned the hard way.

Here’s what that path looked like.

👥 First Among Equals

My first step into leadership began with an informal leadership role in a team that was just launching a new project. I handled the backend, and two colleagues took care of the frontend and mobile parts. We had weekly demos with stakeholders, and somehow, I ended up answering most of the technical questions about architecture, design decisions, and trade-offs.

Officially, I was no different from the others. Unofficially, I became the entry point for most team questions, maybe because the backend often ends up being the backbone of the system.

That project brought my first failure: I left a bug unresolved before leaving, and my teammates had to fix it later. But that was the moment it clicked: leadership means creating systems that work even when you’re not around.

💡 Informal leadership is about action, not titles. You see problems, take ownership, and fix them before they escalate.

🧑‍🏫 Padawans of a Padawan

At another company, I offered to take on a lead role and proposed a trial: mentor two newcomers, show them the processes, assist with their first tasks, teach them code reviews, and conduct one-to-one sessions. I agreed because I needed the experience.

Instead, I was assigned to mentor two juniors. It seemed like a fair deal.

One didn’t pass probation, the other switched teams. Neither was particularly motivated, with zero initiative and minimal curiosity. That’s when I had my first mentoring revelation: you can’t pull someone where they don’t want to go. Sometimes the best thing you can do is help them understand where their strengths lie — and let go.

💡 Mentorship isn’t about transferring knowledge. It’s about knowing when someone’s ready to receive it, and when they’re not.

🔄 Leading an Established Team

At my next company, I began as a developer again. However, after their previous leader left, I was soon promoted to lead an already-established team. Approvals went quickly, and I started digging into the processes. The first few weeks were tough: the team had its routines and unspoken rules, which I still had to learn.

I immediately spotted areas for improvement. Instead of pushing sudden changes, I started with small tweaks, such as improving the code review process. One success story was revamping the review process, which cut down discussion time and improved the quality of released features.

In an established team, you can’t start with radical changes. People are used to their tools and routines — shake things up too fast, and you’ll only annoy them. A better approach? Take it slow, involve the team, and show respect for what’s already working.

💡A lead in a mature team must spot opportunities for improvement where others have accepted the status quo and guide the team forward while respecting their familiar workflows. Think renovation, not demolition.

🧑‍💻 Between Coding and Management

Even though the lead role adds a ton of meetings, I never stopped coding. Management took no more than 50% of my work time, and I tried to spend the rest developing, to stay grounded.

But even if you keep coding, you still start falling behind on the latest trends. Once, I had to jump into a complex code review, and the team was already using newer technologies. I had to catch up quickly to avoid feeling like a guest in my repo. Since then, I have regularly synced with the "tech explorers" on the team. It helps me stay relevant and avoid becoming a retired architect.

Code reviews are a critical part of a lead’s job. You’re not just checking correctness, but also readability and conciseness. A fresh, unbiased perspective often catches corner cases and non-obvious scenarios that slip by in the task flow. These catches save QA time, reduce rework, and build the team’s trust in your technical skills.

Also: I care about unit tests. They should cover not only happy paths but also edge cases. It’s basic, but it’s the team lead who must ensure their actual usefulness, not just presence. After we made unit and integration tests mandatory, guess what? QA started sending fewer tasks back. Fewer revisions and less frustration for everyone.

💡 Leads who stop coding risk becoming PowerPoint architects. Stay sharp — your team will respect it.

🧠 12 Lessons in Leading Without Losing It

Feedback is a gift.
Good or bad — give it honestly, but tactfully. Sandwich the tough parts. And don’t forget to ask for feedback on yourself as a lead — it helps you grow, even when it’s unpleasant.
You’re the bridge between devs and business
A lead isn’t just a task coordinator but a conduit. Your job is to spot problems early, find compromises, and maintain a balance between team and company interests. Learn to translate both ways.
Not everyone can be motivated
Some people just won’t give 100%, and there’s nothing you can do. Don’t waste your energy forcing it.
Own your decisions
Leadership starts with being willing to make decisions and own them. Sometimes it’s better to make a call and be wrong than wait forever.
Pull your team forward
If someone’s stuck, help them. That could mean giving advice or crossing departments to ask how others solved a similar issue. Together, you move faster.
Failures are part of the deal
Mistakes are inevitable. The key is understanding why they happened, learning from them, and moving on. A year later, it’s a funny story. Eventually.
Delegate smartly
Don’t try to control everything. Let the team shine, but keep an eye on key checkpoints to spot issues early.
Pitch ideas — and accept rejection
Even great ideas may not work due to project specifics. Adapt. Improve. Try again.
One-on-one matter
These talks are vital not just for task feedback. They build trust and reveal what standups miss.
Don’t roast people in group meetings
Praise publicly, critique privately.
Document your processes
Bad docs beat no docs. Record key decisions, commands, and workflows — you’ll thank yourself later.
Flexibility is key
People are different. What works for one won’t work for another. Adapt your style

🎲 Epilogue: DnD, Hackathons & Everything In Between

Leadership isn’t just about tasks, it’s about understanding people. Sometimes it’s about hearing what’s said between the lines and realising that “I’m fine” is just a familiar phrase.

To better understand people, I started looking outside traditional tech tools. Tabletop RPGs like DnD turned out surprisingly relevant: you collaborate under pressure, make decisions on the fly, and learn what motivates your party.

Hackathons were also a great leadership school. Under tight deadlines and limited resources, people behave differently. You learn to prioritise, stay calm, and support the team on the verge of burnout.

Being a lead isn’t just managing tasks. It’s about seeing opportunities where others see problems and helping your team do their best work.

If that sounds like something you want, go for it. It's one hell of a ride.

The Journey from Developer to Lead: Lessons Learned About Responsibility