It’s 5am. I’m already at my desk, coding before the meetings start at 9. I haven’t been to the gym in weeks. I’ve lost 10kg. Teams notifications pop up every 5 minutes, each one triggering that instant stress response. Messages I need to answer. Questions I need to answer. Problems I need to solve. I have three meetings today that will decide nothing. I’m the tech lead, I’m supposed to know everything, fix everything, help everyone. And I’m doing all of it. But I’m doing all of it badly.
That’s when I realized I fucked up.
First Time: When “Tech Lead” Was Just a Title
Let me back up a bit. I started coding professionally at 19, working at a student-run software house inside my college. By my second year, I was doing three things at once: college classes, the software house, and a junior engineer role at a US startup (remotely).
Two years into the startup, at 21, they offered me a tech lead position. I was excited. New role, new challenges, leading the technical direction of the team. Sounds great, right?
It wasn’t.
Here’s what nobody tells you about being a tech lead: you can’t lead the technical direction of a product if you don’t have the authority to make technical decisions. And I’m not talking about spaces vs tabs or whether to use semicolons. I’m talking about the stuff that actually matters. How are we going to build this architecture? Why is this approach not going to scale? How do we organize the teams? Should we validate this idea with users before spending three months building something really complex? Can we please stop adding features for a month and pay down the technical debt that’s killing us?
I could go on for hours listing that.
The circumstances weren’t right. I was a tech lead in title, but when it came to making those decisions, well, let’s just say the title didn’t come with the power to actually lead. It was frustrating as hell.
Two weeks in, I was ready to quit the job entirely. But after some conversations, I stayed on, just not as tech lead. Back to working on technical problems, improving pipelines, handling the complex tasks, helping others, reviewing code. Let’s just say, I was acting as a senior engineer. The stuff I was actually good at. Lesson learned, or so I thought.
Dropping Out and Doubling Down
Around that time, I made another decision that people thought was stupid: I dropped out of college.
I’d been studying Software Engineering at a federal university for three years. People told me it was a terrible idea. That I’d regret it. That I was throwing away my future. But here’s the thing, after three years, I couldn’t see the actual value I was getting from it. Maybe it was the college I went to, I don’t know. That’s a conversation for another post.
What I do know is that dropping out with only 2 years of actual work experience, barely leaving junior territory, maybe mid-level at best, put a huge burden on me. I had to prove my point. I had to show that I didn’t need a degree to be an exceptional developer.
And that’s when it all started. I had more free time after dropping out, so I used it to work. All day, including weekends. I picked the harder tasks. I built what people didn’t want to build. I refactored the messy code nobody wanted to touch. All of that inside work, not a single personal project. Just pure, focused effort on getting better at my job.
Think about it. We’re in an era where we have literally all the knowledge in the world available in the palm of our hands. If you’re incapable of learning something new, that’s more on you, honestly.
Now, almost six years later since I wrote my first line of code that went to production and was actually used by real users, I have real work experience while some of my friends who finished their degrees are struggling to land their first junior role (AI and the market aren’t helping, but that’s also a topic for another post). I still think dropping out was a good decision.
The Second Time: When Everything Falls Apart
Fast forward a couple of years. I’m not a junior anymore. I’m acting as the technical reference for the team. Mentoring people, doing the hardest tasks, making architectural decisions, the whole deal. When the time came to officially become a tech lead again, I felt like I had to take that step. Nobody forced me, but it felt like the natural progression. The right move. That was my decision.
It was the worst decision I made in my career.
Those were the worst months of my life.
Here’s what my day looked like: wake up at 5am, code until 9am because that’s the only quiet time I have. Meetings from 9 to 12 (sometimes later). Answer messages during lunch. More meetings in the afternoon. Code reviews. Help people debug their issues. Answer more messages. Interview new people. Try to tackle the hardest tasks because I’m one of the oldest team members and I know the entire codebase. Work until 10pm, sometimes later. Weekends? Working.
I stopped going to the gym. Lost 10kg. My work-life balance wasn’t just bad, it didn’t exist. Hobbies? Personal life? Play video games? Read a book? That was not in my routine.
And here’s the thing: there’s no one to blame but myself. I let things get there. I decided to put work above everything else. I decided to work during weekends. I decided to “go the extra mile.” I made those choices.
Yeah, working 12, 14, 15 hours a day gave me experience faster. Simple math: if you work 8 hours a day for a year, you get one year of experience. But if you work 14 hours a day plus weekends? You do the math. That accelerated learning helped me grow as an engineer, no doubt about it.
But at what cost?
I was doing everything, but I was doing everything badly. The code reviews were rushed. The mentoring was superficial. The architectural decisions were made in between meetings. I wasn’t being a good tech lead. I wasn’t being a good engineer. I wasn’t being a good version of myself.
The Breaking Point
After 4.5 years at my first company, I quit.
My title progression was weird. Junior for two years, then… what? Tech lead? Senior? I don’t even know. Call it whatever you want. I solved problems through software. That’s it. And here’s something most people don’t understand: years of experience is not 100% proportional to the quality or amount of value you deliver.
When I left, some people probably thought I was making another mistake. Going from tech lead back to senior software engineer? Isn’t that a downgrade?
I don’t see it that way.
What I’m Doing Now (And Why It’s Better)
Today, I’m a senior software engineer at a different company. I work 8 hours a day. I have my weekends off. I go to the gym again. I have time to work on side projects (I actually spend my weekends playing mechanic, fixing my 1994 VW Gol). I play Stardew Valley, read books, watch TV shows, go out with friends. I have a life outside of work.
I’m closer to what I call the “company’s floor.” Writing code, fixing bugs, improving the performance of our tools, working on architecture. The stuff I actually enjoy doing. The stuff I’m good at.
Could I become a tech lead again in the future? Maybe. In a different environment, with the right circumstances, I might perform well in that role. But honestly? I’m not sure I want to. Maybe a Software Architect role would be a better fit for me. Or maybe I’ll stay as a Senior for several more years. And you know what? There’s no problem with any of that.
What I Actually Learned
Here’s what those two tech lead experiences taught me:
You don’t need to stick to a plan forever. When you’re at the beginning of your career, you can change your mind. You can discover new areas. You can switch directions. You’re allowed to try something, realize it’s not for you, and go back. That’s not failure. That’s learning.
Going from tech lead to senior engineer is not a downgrade. Life is not only about titles and salary. Work is just a part of your day, 8 hours (or it should be). It shouldn’t be your whole life.
Mental health and work-life balance matter more than everything else. Yeah, sometimes you need to sacrifice your health for things you believe are important. Sometimes you need to push hard for a deadline or a launch. But that should be the exception, not the rule.
Real leadership requires actual decision-making power. You can’t lead technical direction if your decisions, concerns, and suggestions are mostly ignored. If you’re in a tech lead role but can’t make the decisions that matter, you’re not really leading anything.
Know what you actually enjoy doing. I like coding. I like solving technical problems. I like improving systems and paying down technical debt. I don’t like endless meetings. I don’t like being pulled in 50 directions at once. And most important, I hate wasting time, resources and money. Throwing away hours of good work just kills me. Knowing this about myself saved me from years of misery.
Working more doesn’t mean working better. Those 14-hour days made me worse at my job, not better. I learned faster, sure, but I burned out harder too. It’s not worth it.
If You’re Considering a Tech Lead Role
If you’re a developer thinking about becoming a tech lead, here’s my advice: really think about what the role means at your specific company. Is it about writing less code and managing more people? Is it about making architectural decisions? Is it a mix of both?
More importantly, is that what you want to do?
Don’t take a role because it seems like the “next step” in your career. Don’t take it because someone offered it to you and you feel like you should say yes. Take it because you actually want to do that job.
And if you try it and hate it? You can go back. You can change your mind. You can pivot. Early in your career, this is the time to figure out what you like and what you don’t like. Don’t waste years being miserable because you think you have to stick to a plan.
Final Thoughts
I’m 24 now. I’ve been working as a software developer for almost six years. I’ve been a junior, a senior, a tech lead (twice), and back to senior again. My path wasn’t linear. It was messy. I made mistakes. I burned out. I quit. I changed my mind.
And I’m totally okay with that.
I don’t know what my career will look like in five years. Maybe I’ll be a tech lead again. Maybe I’ll be a software architect. Maybe I’ll still be a senior engineer writing code every day. Maybe AI will take my job and I’ll start raising geese, who knows?
What I do know is this: I’m going to prioritize my mental health. I’m going to work on things I enjoy. I’m going to maintain my work-life balance. And I’m not going to feel bad about choosing those things over a fancier title or a bigger salary.
Life’s too short to wake up at 5am every day, stressed out of your mind, doing work that makes you miserable.
Your career is not a ladder you have to climb. It’s a path you get to choose. And sometimes, the best choice is to take a step back, reassess, and find a better direction.
Here’s the thing: I’m an engineer by nature. I like learning how things work. I like breaking things apart to understand them. I like building and creating. But most importantly, I truly, truly love coding. I’m deeply fascinated by it. Since my first line of code compiled, I’ve been hooked. That passion for writing code is what drove me into this field, and losing touch with it while being a tech lead felt wrong. Going back to senior engineer wasn’t a step down. It was a step back to what I love.
Hope this helps someone out there who’s feeling stuck or wondering if they made the wrong choice. You probably didn’t. You’re just figuring it out, like the rest of us.