Prologue
It’s late, and the office lights are dimming around me. I’m supposed to be heading home, but I’m frozen in front of my monitor, thinking about how I got here the ups and downs. I’d been a leader in the past, high-level, strategic stuff, then took a detour, change the country, new world so I start at the begining, went down the latter into pure coding became a developer and tried to start building my way up again. after a while working there it happened, I became Tech Lead. I still remember my time as a Tech Lead at that company, with a team depending on me. The lessons I’m about to share weren’t handed to me in a proper manual; I learned them through messy, real-world experiences. At the time, I was just trying to survive and help others thrive.
These stories are the hidden chapters behind the advice I’d later put into that “Charting Your Path Beyond the Code” blog I suggest reading these two parallel works better like that.
Disclaimer: Names and Genders in these stories are changed in favor of hiding the real identities, and not all the stories are from one company, and they are a really, REALLY small part of the whole picture.
Act 1: New Challenger Enters the Ring
When I first stepped into the Tech Lead role, I still had that developer’s hunger for the latest frameworks and libraries. I remember one particular time when I introduced a slick new library, something I’d discovered over a weekend. I was excited, and I assumed the team would share my enthusiasm.well… Instead, I got blank stares and polite nods, “good enough” I said. A few weeks in, half the team struggled with the tool’s learning curve, and the other half silently reverted to the old way of doing things and skipping the library totally. We lost valuable time, and morale dipped, I was angry and frustrated.
That was my first big lesson: keeping pace with technology doesn’t mean hauling the entire team into a cutting-edge labyrinth. Our development speed suffered because I chased something shiny without measuring its impact. I learned that “staying updated” doesn’t mean “adopting every new trend.” It means understanding what truly benefits your team and product, not just what’s cool on Reddit.
Then there was my internal battle: I craved coding. Late at night, I’d sneak in and commit features myself. But one morning, Dave, one of our backend developers, pulled me aside. “Hey, I noticed you’ve been making a lot of PRs at odd hours. Are we missing something? We could help if you let us.” His words stuck in my head not because they were harsh, but because they exposed my fear of losing technical touch. I realized I was hogging the spotlight instead of enabling the team. From that point on, I let them take the lead on coding tasks, and I focused on what they needed to succeed and offered help when needed. I still coded occasionally to keep my skills sharp, but my main codebase became the team itself, their structure, their growth, their environment.
Act 2: Rules and Regulations of the Game
I soon learned that no two engineers are alike. Take Ryan, our junior front-end dev, who thrived on constant feedback and daily check-ins. Meanwhile, Priya, a senior backend engineer, hated frequent interruptions; she needed long stretches and quiet focus. Early on, I tried a one-size-fits-all approach, everyone got the same kind of feedback in the same style of meeting. The result? Ryan felt ignored when I gave too little direction, and Priya felt micromanaged when I checked in too often and in of the one-on-ones said she is thinking about what did she do that I am checking that much with her. It took time, lots of one-on-one chats, and a few missteps and failures before I learned how to calibrate my approach to each individual. Understanding their different work rhythms was like deciphering a puzzle: once I got it right, the team clicked and trust start to buildup.
I also had my lack of knowledge with the difference between telling and showing. Once, during a heated sprint review, some stakeholders were pushing for impossible deadlines. I felt the urge to just nod and accept, then later complain to the team (feels familiar, we all been there). Instead, I calmly explained why it wouldn’t work, pointing to data, past results, and the impact on code quality. By transparent communication, even when it was uncomfortable, I set an example. The team saw I wouldn’t throw them under the bus or silently accept poor conditions. Over time, that earned me their trust. They realized I wouldn’t just talk about good leadership, I would try to live it, even if it meant delivering tough news upward.
Well, Communication worked both ways, too. In one retro, I asked, “What did we mess up this sprint?” The silence was deafening. So I confessed, “I probably made a few assumptions that weren’t clear, I know them and we suffered, and I learned how to work with Bernard our PO, but Can someone point them out? Let’s see if you guys also felt them” That broke the ice. People felt safe to say, “I didn’t understand why we pivoted mid-sprint,” or “I was unsure about the requirements for feature X.” By consistently inviting and valuing their voices, we avoided a lot of confusion down the line. And no one ever left a meeting without clarity again, even if it meant scheduling a follow-up. Yes, more meetings can be tedious, but fewer misunderstandings saved us from countless headaches.
Perhaps the hardest pill to swallow was about micromanagement. I tried it briefly, thinking it would ensure quality. It did the opposite. By hovering over their shoulders, I smothered their creativity and signaled that I didn’t trust them, it almost cost losing team. When a critical feature got delayed because my interference slowed them down, I realized my mistake and also realized that my manager did the same to me at that time, you know? I gave it forward, you can name it the chain of micromanagers hahaha (crying inside). I learned that setting clear expectations and then stepping back let them work with confidence. I’d rather fix mistakes later than never let them develop their own problem-solving abilities.
Act 3: Don’t Forget to Breathe
As weeks turned into months, I saw patterns emerge. Every time we adapted to a new requirement or navigated a sudden shift in priorities, it felt we grow stronger. I had failures and successes, not all in one job, but you need to learn somehow. For example, when a client demanded a pivot that cut our timeline in half, I explained the situation honestly: “I don’t love this change either, but here’s why it’s happening.” Seeing the team’s frustration turn into proactive brainstorming because I was part of a team not a manager that cares about his paycheck (well I care, but I cared about theirs too, and honestly without them none of this were there soooo, anyway…), it proved that transparency and empathy could turn into teamwork.
I started investing in my own growth as a leader, reading books and talking to mentors and talking to monsters, you read it right!, maybe that dark side for later right? Right. When I encountered a tough personnel issue, like a senior dev who was brilliant but demotivated, I reached out to a people that I believed in or proven that they worth taking advice from. I tried to delegated tasks more wisely. Instead of fixing bugs myself, I’d say, “Hey, Diego, you’ve got a great eye for detail. Could you dig into this one?” I watched him light up at the trust. He solved the bug, learned from it(I hope).
Uncertainty…, I remember I was worried about this all the time about not having answers and A manager should have it right? Well in this situation you should not (each level of management begs some different level of being sure of some levels you need to answer base on some percentage of certainty, but that is a story for another time) Instead of pretending that I had all the answers, I’d say, “I’m not entirely sure, but let’s figure it out.” The team respected that honesty. Over time, we formed a culture of collective problem-solving. It was no longer about one hero coder or one leader, it was about all of us pulling together.
I remember noticing that Sasha, who was usually energetic and talkative, seemed withdrawn during a planning meeting and also some task were taking longer than usual. I asked in our one-on-one if everything was okay (IMPORTANT NOTE: keep in mind the line never pass the line it can go south really fast, been there done that, so if you are going to do this I expect you to have fair share of HR experience, if not really try to get some education about how to approach these problems if needed I can write about my experiences on another blog). Turns out, she’d been dealing with a tough personal situation we didn’t go deeper than that, but By giving her space and support rather than just demanding productivity, I earned her trust and I think her loyalty. She bounced back, and I learned that leading humans isn’t just about tasks; it’s about recognizing that life doesn’t stop at the office door.
Finale
In the end, these stories formed the backbone of the lessons I will eventually share in my blog. What you read here and will read later, about balancing hands-on work, understanding your team, leading by example, communicating clearly, avoiding micromanagement, embracing adaptability, investing in mentorship, and practicing empathy, didn’t come from theory at least not most of it. They were forged in late-night coding sessions, awkward silence in retrospectives, difficult conversations, and tough client calls that tested my limits.
When I finally wrote that blog “Charting Your Path Beyond the Code”, it felt like distilling a messy, living process into something coherent and helpful. But behind every bullet point was a real moment, my team staring at me, my pride challenged, my expectations realigned. This leadership journey taught me that guiding a team isn’t about perfection not even near that. It’s about learning from each messup, staying curious, staying humble, and building the trust that allows everyone to grow.
These stories are the untold chapters behind the these advices well not all of them I’ll not spill the beans NOW. They’re a reminder that every leadership principle comes with a backstory, a time when I failed, learned, and chose to do better the next time around.