{"id":463563,"date":"2025-06-16T15:02:02","date_gmt":"2025-06-16T15:02:02","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=463563"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=463563","title":{"rendered":"The Journey from Developer to Lead: Lessons Learned About Responsibility<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

Becoming a lead isn\u2019t just another line in your resume,\u00a0 it\u2019s a mental shift. It\u2019s the moment you go from being a developer to someone responsible for your code and the entire team. Next, you\u2019re also listening, mentoring, negotiating, motivating, and knowing how to find common ground even in challenging situations.<\/p>\n

Today, I\u2019m a Dev Lead at EXANTE. We develop internal services for a select group of internal stakeholders. But my journey started long before that \u2014 with informal leadership, a few mentorship flops, and plenty of lessons learned the hard way.<\/p>\n

Here\u2019s what that path looked like.<\/p>\n\n

\ud83d\udc65 First Among Equals<\/h3>\n

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.<\/p>\n

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.<\/p>\n

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\u2019re not around.<\/p>\n

\ud83d\udca1 Informal leadership is about action, not titles. You see problems, take ownership, and fix them before they escalate.<\/strong><\/p>\n

\ud83e\uddd1\u200d\ud83c\udfeb Padawans of a Padawan<\/h3>\n

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.<\/p>\n

Instead, I was assigned to mentor two juniors. It seemed like a fair deal.<\/p>\n

One didn\u2019t pass probation, the other switched teams. Neither was particularly motivated, with zero initiative and minimal curiosity. That\u2019s when I had my first mentoring revelation: you can\u2019t pull someone where they don\u2019t want to go. Sometimes the best thing you can do is help them understand where their strengths lie \u2014 and let go.<\/p>\n

\ud83d\udca1\u00a0 Mentorship isn\u2019t about transferring knowledge. It\u2019s about knowing when someone\u2019s ready to receive it, and when they\u2019re not.<\/strong><\/p>\n

\ud83d\udd04 Leading an Established Team<\/h3>\n

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.<\/p>\n

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.<\/p>\n

In an established team, you can\u2019t start with radical changes. People are used to their tools and routines \u2014 shake things up too fast, and you\u2019ll only annoy them. A better approach? Take it slow, involve the team, and show respect for what\u2019s already working.<\/p>\n

\ud83d\udca1A 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.<\/strong><\/p>\n

\ud83e\uddd1\u200d\ud83d\udcbb Between Coding and Management<\/h3>\n

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.<\/p>\n

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.<\/p>\n

Code reviews are a critical part of a lead\u2019s job. You\u2019re 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\u2019s trust in your technical skills.<\/p>\n

Also: I care about unit tests. They should cover not only happy paths but also edge cases. It\u2019s basic, but it\u2019s the team lead who must ensure their actual<\/em> 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.<\/p>\n

\ud83d\udca1 Leads who stop coding risk becoming PowerPoint architects. Stay sharp \u2014 your team will respect it.<\/strong><\/p>\n

\ud83e\udde0 12 Lessons in Leading Without Losing It<\/h3>\n
    \n
  1. \n

    Feedback is a gift. <\/strong><\/p>\n

    Good or bad \u2014 give it honestly, but tactfully. Sandwich the tough parts. And don\u2019t forget to ask for feedback on yourself as a lead \u2014 it helps you grow, even when it\u2019s unpleasant.<\/p>\n<\/li>\n

  2. \n

    You\u2019re the bridge between devs and business\u00a0<\/strong><\/p>\n

    A lead isn\u2019t 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.<\/p>\n<\/li>\n

  3. \n

    Not everyone can be motivated<\/strong><\/p>\n

    Some people just won\u2019t give 100%, and there\u2019s nothing you can do. Don\u2019t waste your energy forcing it.<\/p>\n<\/li>\n

  4. \n

    Own your decisions\u00a0<\/strong><\/p>\n

    Leadership starts with being willing to make decisions and own them. Sometimes it\u2019s better to make a call and be wrong than wait forever.<\/p>\n<\/li>\n

  5. \n

    Pull your team forward<\/strong><\/p>\n

    If someone\u2019s stuck, help them. That could mean giving advice or crossing departments to ask how others solved a similar issue. Together, you move faster.\u00a0<\/p>\n<\/li>\n

  6. \n

    Failures are part of the deal<\/strong><\/p>\n

    Mistakes are inevitable. The key is understanding why they happened, learning from them, and moving on. A year later, it\u2019s a funny story. Eventually.<\/p>\n<\/li>\n

  7. \n

    Delegate smartly<\/strong><\/p>\n

    Don\u2019t try to control everything. Let the team shine, but keep an eye on key checkpoints to spot issues early.<\/p>\n<\/li>\n

  8. \n

    Pitch ideas \u2014 and accept rejection<\/strong><\/p>\n

    Even great ideas may not work due to project specifics. Adapt. Improve. Try again.<\/p>\n<\/li>\n

  9. \n

    One-on-one matter<\/strong><\/p>\n

    These talks are vital not just for task feedback. They build trust and reveal what standups miss.<\/p>\n<\/li>\n

  10. \n

    Don\u2019t roast people in group meetings<\/strong><\/p>\n

    Praise publicly, critique privately.<\/p>\n<\/li>\n

  11. \n

    Document your processes<\/strong><\/p>\n

    Bad docs beat no docs. Record key decisions, commands, and workflows \u2014 you\u2019ll thank yourself later.<\/p>\n<\/li>\n

  12. \n

    Flexibility is key<\/strong><\/p>\n

    People are different. What works for one won\u2019t work for another. Adapt your style<\/p>\n\n<\/li>\n<\/ol>\n

    \ud83c\udfb2 Epilogue: DnD, Hackathons & Everything In Between<\/h3>\n

    Leadership isn\u2019t just about tasks, it\u2019s about understanding people. Sometimes it\u2019s about hearing what\u2019s said between the lines and realising that \u201cI\u2019m fine\u201d is just a familiar phrase.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    Being a lead isn\u2019t just managing tasks. It\u2019s about seeing opportunities where others see problems and helping your team do their best work.\u00a0<\/p>\n

    If that sounds like something you want, go for it. It’s one hell of a ride.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

    <\/div>\n


    \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 https:\/\/habr.com\/ru\/articles\/918828\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

    <\/div>\n
    \n
    \n
    \n
    \n

    Becoming a lead isn\u2019t just another line in your resume,\u00a0 it\u2019s a mental shift. It\u2019s the moment you go from being a developer to someone responsible for your code and the entire team. Next, you\u2019re also listening, mentoring, negotiating, motivating, and knowing how to find common ground even in challenging situations.<\/p>\n

    Today, I\u2019m a Dev Lead at EXANTE. We develop internal services for a select group of internal stakeholders. But my journey started long before that \u2014 with informal leadership, a few mentorship flops, and plenty of lessons learned the hard way.<\/p>\n

    Here\u2019s what that path looked like.<\/p>\n\n

    \ud83d\udc65 First Among Equals<\/h3>\n

    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.<\/p>\n

    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.<\/p>\n

    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\u2019re not around.<\/p>\n

    \ud83d\udca1 Informal leadership is about action, not titles. You see problems, take ownership, and fix them before they escalate.<\/strong><\/p>\n

    \ud83e\uddd1\u200d\ud83c\udfeb Padawans of a Padawan<\/h3>\n

    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.<\/p>\n

    Instead, I was assigned to mentor two juniors. It seemed like a fair deal.<\/p>\n

    One didn\u2019t pass probation, the other switched teams. Neither was particularly motivated, with zero initiative and minimal curiosity. That\u2019s when I had my first mentoring revelation: you can\u2019t pull someone where they don\u2019t want to go. Sometimes the best thing you can do is help them understand where their strengths lie \u2014 and let go.<\/p>\n

    \ud83d\udca1\u00a0 Mentorship isn\u2019t about transferring knowledge. It\u2019s about knowing when someone\u2019s ready to receive it, and when they\u2019re not.<\/strong><\/p>\n

    \ud83d\udd04 Leading an Established Team<\/h3>\n

    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.<\/p>\n

    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.<\/p>\n

    In an established team, you can\u2019t start with radical changes. People are used to their tools and routines \u2014 shake things up too fast, and you\u2019ll only annoy them. A better approach? Take it slow, involve the team, and show respect for what\u2019s already working.<\/p>\n

    \ud83d\udca1A 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.<\/strong><\/p>\n

    \ud83e\uddd1\u200d\ud83d\udcbb Between Coding and Management<\/h3>\n

    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.<\/p>\n

    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.<\/p>\n

    Code reviews are a critical part of a lead\u2019s job. You\u2019re 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\u2019s trust in your technical skills.<\/p>\n

    Also: I care about unit tests. They should cover not only happy paths but also edge cases. It\u2019s basic, but it\u2019s the team lead who must ensure their actual<\/em> 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.<\/p>\n

    \ud83d\udca1 Leads who stop coding risk becoming PowerPoint architects. Stay sharp \u2014 your team will respect it.<\/strong><\/p>\n

    \ud83e\udde0 12 Lessons in Leading Without Losing It<\/h3>\n
      \n
    1. \n

      Feedback is a gift. <\/strong><\/p>\n

      Good or bad \u2014 give it honestly, but tactfully. Sandwich the tough parts. And don\u2019t forget to ask for feedback on yourself as a lead \u2014 it helps you grow, even when it\u2019s unpleasant.<\/p>\n<\/li>\n

    2. \n

      You\u2019re the bridge between devs and business\u00a0<\/strong><\/p>\n

      A lead isn\u2019t 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.<\/p>\n<\/li>\n

    3. \n

      Not everyone can be motivated<\/strong><\/p>\n

      Some people just won\u2019t give 100%, and there\u2019s nothing you can do. Don\u2019t waste your energy forcing it.<\/p>\n<\/li>\n

    4. \n

      Own your decisions\u00a0<\/strong><\/p>\n

      Leadership starts with being willing to make decisions and own them. Sometimes it\u2019s better to make a call and be wrong than wait forever.<\/p>\n<\/li>\n

    5. \n

      Pull your team forward<\/strong><\/p>\n

      If someone\u2019s stuck, help them. That could mean giving advice or crossing departments to ask how others solved a similar issue. Together, you move faster.\u00a0<\/p>\n<\/li>\n

    6. \n

      Failures are part of the deal<\/strong><\/p>\n

      Mistakes are inevitable. The key is understanding why they happened, learning from them, and moving on. A year later, it\u2019s a funny story. Eventually.<\/p>\n<\/li>\n

    7. \n

      Delegate smartly<\/strong><\/p>\n

      Don\u2019t try to control everything. Let the team shine, but keep an eye on key checkpoints to spot issues early.<\/p>\n<\/li>\n

    8. \n

      Pitch ideas \u2014 and accept rejection<\/strong><\/p>\n

      Even great ideas may not work due to project specifics. Adapt. Improve. Try again.<\/p>\n<\/li>\n

    9. \n

      One-on-one matter<\/strong><\/p>\n

      These talks are vital not just for task feedback. They build trust and reveal what standups miss.<\/p>\n<\/li>\n

    10. \n

      Don\u2019t roast people in group meetings<\/strong><\/p>\n

      Praise publicly, critique privately.<\/p>\n<\/li>\n

    11. \n

      Document your processes<\/strong><\/p>\n

      Bad docs beat no docs. Record key decisions, commands, and workflows \u2014 you\u2019ll thank yourself later.<\/p>\n<\/li>\n

    12. \n

      Flexibility is key<\/strong><\/p>\n

      People are different. What works for one won\u2019t work for another. Adapt your style<\/p>\n\n<\/li>\n<\/ol>\n

      \ud83c\udfb2 Epilogue: DnD, Hackathons & Everything In Between<\/h3>\n

      Leadership isn\u2019t just about tasks, it\u2019s about understanding people. Sometimes it\u2019s about hearing what\u2019s said between the lines and realising that \u201cI\u2019m fine\u201d is just a familiar phrase.<\/p>\n

      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.<\/p>\n

      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.<\/p>\n

      Being a lead isn\u2019t just managing tasks. It\u2019s about seeing opportunities where others see problems and helping your team do their best work.\u00a0<\/p>\n

      If that sounds like something you want, go for it. It’s one hell of a ride.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

      <\/div>\n


      \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 https:\/\/habr.com\/ru\/articles\/918828\/<\/a>
      <\/br><\/br><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-463563","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/463563","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=463563"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/463563\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=463563"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=463563"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=463563"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}