What changed that was not a new language or a faster framework. It was learning how to work: with people, with process, with care. And it took a few specific people to show me the door.
I studied Telecommunications engineering, and somewhere along the way I ended up writing software. Mostly C, whatever the job needed. This was before coding got its glamour. Nobody said “best practices” out loud. Testing was barely a habit. “Agile” was a word you might have skimmed once in the business pages of a magazine. Scrum, Kanban, linters: none of it existed in my world. Life happened in Bash, in scattered text notes, and in the Eclipse editor.
I wrote code that worked, and I went home. If it ran, it was done. I was not unhappy. I just did not feel much of anything.
The first crack of light came in Germany, where I joined a research company affiliated with a university. The team took Agile seriously, back when it was a trend there and had barely reached Spain. I turned up expecting to write code. Instead, I found people who wanted to talk about how we wrote it.
At first it felt like a detour. Long conversations about process. My first real sprints. People asking not just “does it work?” but “will this be easy to change in six months?” and “how do we estimate this properly?” The question was always how, before the doing.
Most of that I learnt from Imanol, the tech lead on my team. We would run a planning session, but first we would talk about how to run a planning session. We took estimation seriously, and moved to story points; it changed how we planned around the team’s real capacity. “Forget time relation, give me your points,” Imanol used to say. “Eventually you will start thinking in points when estimating.” It sounded slow at first. Then, little by little, it stopped feeling slow and started feeling like a different universe.
We started thinking about sustainability too. How do we keep this alive and working over the long term? Coding was not about stringing instructions together to get a behaviour. It was about writing something another human could read, months later, without cursing my name. Thinking about the future, and about other people, quietly changes what you do today. I stopped building things to work for now. I started building them to survive change.
Step by step, I moved into Scrum. I brought quality into the conversation. I slowed the rhythm down on purpose, which felt wrong and turned out to be right. We even helped the company make the full move to Scrum. It was not easy, and it is still one of the things I am most proud of. That work carried me back to Spain with a job in hand, in the middle of the crisis, when everyone else was heading for the door.
Without noticing, I had stopped learning what to build and started learning how.
Back home, I was still learning to code in Ruby properly. Junior in the code itself, but carrying everything I had learnt about Agile into the project.
I was working on a feature with one of the main developers on the team. The code review was brutal: ten or fifteen comments on a pull request of barely fifty lines. Abstractions, dependencies, refactors. Comment after comment, and each one landed. I took it a little personally, the way you do when you are tired and a little proud. Then, instead of stewing, I asked him to jump into a pair session together.
We opened the code and refactored together. He walked me through it one change at a time, thinking out loud, and something shifted. For the first time, I saw code as something close to living art. Not a wall of instructions, but a thing you shape. We were focused on the code, on how to make it better, finding beauty in the process.
At one point I asked a question, half expecting to look stupid. He stopped and said: “Right. That is what makes you grow fast. You are asking good questions.”
He did not just fix my code. He showed me how to think about it, and how to sit with a hard review instead of hiding from it. Another person, opening the same door.
I had walked in with the sting of a nasty review. I walked out wanting to be better at this. Same afternoon, same code, a completely different feeling.
That was when it happened. The work I had not cared about started to feel good. Not because the tasks changed, but because I did. It was no longer just writing code. It was making something properly. Something I was a little proud of. Something, honestly, beautiful.
The how had opened a whole dimension I did not know was there. And most of all, it came from people: how we talked, how we disagreed, how we carried each other along. It was about process, how the work flowed and how a team held together. And it was about quality, how you build something today so it survives tomorrow.
None of that came from a book. Every piece of it came from a person. Imanol and the team in Germany, who cared about the way we worked. The developer who turned a harsh review into an afternoon I still remember. Take those people away, and I am still writing code that runs, going home, feeling nothing.
That is the part I most want you to hear. You do not always have to start with passion. Sometimes you back into it, through the how, guided by the right people. Passion can be built.
You do not get to choose every teammate or every process. But when you can, choose them on purpose. They are what decide whether the work is a grind or a craft.
I started out as a developer with no real love for the job. The how, and the people who taught it to me, are the whole reason that changed.
]]>The this was not writing code. It was the other stuff. Unblocking people, smoothing over an argument, defending my team from a manager who did not get it. I had been doing it on the side for years without really noticing. And that night I said it out loud: why could I not just be a manager?
Nobody I knew grew up wanting this. As a kid I never heard a friend say “I want to be a manager”. I heard “I want to be the boss”, which is not the same thing; a boss is not a manager, and a leader is neither. But that is another post.
In my case I never thought about any of it. I was not clear on what I wanted to be. I just walked step by step, focused on whatever was in front of me. A decent job, fingers crossed that I enjoyed it, and a good life around it. That was the whole plan.
So when does the transition really start? Not with a title. It starts the day you notice that working with people, and making their work a little better, satisfies you more than the code does.
I have watched a lot of developers make this move. Almost all of them came from one of three places. Let me lay them out honestly first; I will tell you what I think later.
The first is the natural. You genuinely like the tech. Shipping good code to production still feels great. But you also have a way with people, and it was always there. Sooner or later you feel the pull, and you start figuring out how to follow it.
The second is the accidental. You never planned this. You covered for someone who left, or a project pushed you into coordinating the team for a while. Management tasks landed on your desk by accident, and to your surprise, you liked them. That is usually good news: if it felt comfortable, you can probably grow the skills.
The third is the money. You do not really enjoy the management part. You are there, or thinking about going there, because it looks like the only door to a better salary. And of course we want more money; there is nothing wrong with that.
Here is where I want to slow down, because the third reason is not really about you. It is about how our industry has worked for years.
For a long time the only ladder went up through management. Want a raise? Become a lead. Want the lead title to mean something? Manage more people. Growth and management were treated as the same road, so the “natural” next step for a good developer was to stop developing. Not because anyone needed another manager, but because that was the only box the salary lived in.
I have watched what that costs, more than once. A brilliant engineer gets promoted into a role that needs a completely different set of skills; skills they never asked to build and are not interested in building. The promotion looks like a reward. It slowly turns into a quiet frustration, for them and for the team they now lead. That is how you manufacture a bad manager out of a great engineer.
So be honest with yourself. Do you actually want that job, and do you know how to do it? If the answer is “I just want to earn more”, then say exactly that, and ask for more money. You can go deep and grow for years in a technical role without ever managing a single person. Seniority is not the same thing as authority over people.
So what does make the move worth it? For me it comes down to one thing, and it is not the title or the pay. It is a genuine interest in the human, not just the engineer.
We are technical people. We are pushed to deliver, all the time. But underneath the results we are still people, with the same fears and feelings as everyone else, and most of the time nobody at work treats us that way. Traditional leadership tends to ask for results while ignoring the technical realities beneath them. When leaders don’t understand the work, they struggle to grant the autonomy and trust engineers need to perform. Ultimately, I think this applies everywhere: a lack of understanding leads directly to a lack of trust.
For years I lived in hybrid roles: writing code with one hand and, with the other, doing the thing nobody had asked me to do. I ended up in the conversations more than in the commits. Finding the agreement that unblocked two people who had stopped talking to each other. Sitting between the team and a manager who was “challenging” our work, and quietly defending it. Turning a tense room into one where people could get on with their job.
I was good at it before I had a word for it. I built the kind of atmosphere where relationships got better and blockers melted, and people simply worked better.
“Manager” was not a word that made me feel good. It brought up mediocrity, bureaucracy, politics, and authority for its own sake. Then I realized how unfair that was. There are good managers out there. I could be one; the kind I would have wanted above me.
That was the moment. Engineers are humans dealing with technology, and it turned out I cared more about the human than the technology. I wanted to work with the person behind the engineer.
So here is the one thing I would tell you; make this move if you care about people, and make it for them, not for the raise or the badge. And if you do not, stay technical, and stay proud of it. Both are real growth. Only one of them should be called management.
]]>