I’ve realized that the hardest things to learn are almost never technical.
They’re the things you have to unlearn.
And the weird part is that, while you’re unlearning them, it feels like you’re losing something. Status, control, identity. Then, if things go well, you realize you were just letting go of a habit that was keeping you stuck.
These are scattered notes on a few things I’ve stopped doing. It took me fifteen years, more or less. And on some of them, if I’m being honest, I’m not done yet.
I stopped writing code to prove I’m still technical #
There was a period, right after a big career transition, when my way of legitimizing myself in front of the team was always the same: I’d open the IDE and go grab the ugliest bug of the week.
I often did it in the evening, alone. The next morning the commit was there, with my name on it. In my head I called it leadership. In reality it was insecurity.
Because the implicit message was devastating, even if I never said it out loud. The message was: I don’t trust you. And there was another one, even more toxic: problems get solved at night, solo, without asking for help.
Without meaning to, I was teaching that the heroic gesture matters more than the process. That skill is an individual performance. That effort is a medal.
Then I took another spin on the carousel. I replaced code with specs. Documents so precise that the team, or an ai agent, could implement them with minimal supervision. For a while it felt like the “adult” solution. But that phase passed too.
Today my job, when I do it well, is something else. It’s deciding what we build, for whom, and why now. It’s portfolio architecture, not code architecture. It’s partnerships, hiring, positioning. It’s figuring out where the company needs to aim eighteen months from now, and which choices today make that direction more likely.
This distance from code sometimes hurts. Not because I want to go back to programming every day. It’s subtler than that. It’s the feeling that the legitimacy of a technical person who no longer touches code daily is fragile—something you have to rebuild on different foundations.
No longer on the quality of what you write, but on the quality of the decisions you make and the people you choose.
And then there’s a sentence that comes back to me often, and helps me not fall back into the old reflex: every line I write is a line someone else doesn’t write. Every hour I spend in the IDE is an hour when nobody is looking at where we’re going.
I stopped chasing the right stack #
For years I had that Pavlovian developer reflex. A new framework comes out, you have to evaluate it. A new language comes out, you at least have to try it.
Deep down, I think the subtext was this: there is a “right” technology choice that puts you on the winners’ side. The cool kids. The right conferences. The articles on Hacker News.
Then I did something unpopular, at least for how I’d gotten used to thinking: I picked a framework. One. And I stuck with it.
Not because it’s the absolute best. But because it lets me deliver value with a small number of people across multiple projects, without losing my mind. Because it has a philosophy that holds up under the real constraints of an Italian company. Convention over configuration, batteries included, obsessive documentation. Not the imaginary constraints of a Bay Area startup that lives on slides and runway.
The uncomfortable truth is that a lot of “bold” technology choices, in SMBs, aren’t bold. They’re vanity. Choosing Rust for an internal management system that forty people will use isn’t engineering. It’s narcissism with a compiler.
At some point I stopped looking for the right stack and started looking for the honest stack. The one that doesn’t lie about the complexity it introduces. The one you can maintain when the seniors leave, when the budget tightens, when the client changes their mind three times.
I stopped shielding the team from the business #
This was the hardest transition.
For years I acted as a shield. The client asks for a crazy change? I filter it. Sales sells something that doesn’t exist? I handle it. An incomprehensible document arrives? I translate it and pass only the technical part to the team—clean, digestible.
I thought I was being a good leader. And instead, I was probably creating invalids.
Very strong developers, yes, but disconnected. They didn’t really know why they were building what they were building. They couldn’t read a business requirement. They had never talked to a client. And when they hit ambiguity, instead of picking up the phone, they’d open a ticket and wait for someone else to resolve it.
The change, for us, was building an internal path we called “from developer to product owner.” Not to turn everyone into PMs. More than anything, to remove the filter.
To say something simple, even if a bit uncomfortable: the mess is yours too. The confused client is yours too. The ambiguous requirement is yours too.
And, above all, the satisfaction of delivering something that actually works for someone is yours too.
I thought it would be unpopular. I was wrong. They surprised me. Maybe they were just waiting for us to give them permission to step out of the bubble.
I stopped saying “it’s public anyway” when talking about compliance #
For years my stance on compliance was the typical one in Italian IT. The bare minimum, done at the last possible moment, treated as a cost and never as an investment.
GDPR? A cookie banner and a copied privacy policy. Accessibility? “We’ll think about it later.” Security? “We’re not a target.”
Then I started actually reading some European regulations. Not articles about those regulations—the texts themselves. And two things became clear.
First: the European legislator, for once, is not kidding. The penalties are real, the timelines are tight, and the chain of responsibility goes all the way down to the supplier of the software component. That is, us.
Second, more important: in a market where everyone waits until the last moment, whoever moves first has an enormous competitive advantage. Not because they’re better. Because they’re the only one who can tell the client “yes, we’re ready” when the client, in a panic, starts asking.
At some point I stopped treating compliance like an obligation. I started treating it like a product.
And I often wonder why it took us so long to understand. Maybe because it’s more comfortable to think it’s just paperwork—until it suddenly becomes a problem with a deadline.
I stopped hiring for technical skills #
This is recent and, if I’m being honest, still a bit painful.
I spent weeks looking for an important role. Candidates with excellent CVs. Years of experience. Solid stacks. Good references. I rejected several—not because they weren’t good, but because they used AI the way they used Stack Overflow ten years ago. Like an oracle.
What I was looking for, and what I still struggle to explain to recruiters, is different. I was looking for someone who could write a declarative spec so precise that an AI agent could implement it with minimal supervision.
Not a prompt engineer. A systems thinker who uses AI as a runtime, not as a crutch.
The difference seems subtle, but it isn’t. It’s the difference between someone who says “I asked ChatGPT to write the code for me” and someone who keeps a claude.md file in the repository with architectural conventions, patterns, domain constraints. It’s the difference between conversation and specification. Between craftsmanship and engineering.
I stopped hiring developers who can code. I started looking for developers who can specify and then verify what AI produced with the same rigor they’d use to review a junior’s code.
The Italian market doesn’t seem ready for this distinction yet, unfortunately. But I have a feeling it will be soon. And anyone who doesn’t get there in time risks ending up with teams that “produce” a lot, but understand little.
I stopped speaking Italian at work #
It seems like a small thing. It isn’t.
When a new non-Italian junior joined—brilliant—we found ourselves facing a choice. Keep working in Italian among ourselves and use English only with him, effectively creating a two-speed team. Or switch completely.
We chose the full switch. Everything in English. Jira in English. Chat in English. Daily in English. Retro in English. For everyone.
I didn’t do it only for him. I did it for us.
Because a small company in an Italian city that works only in Italian is a company that will probably stay small in that city. There’s nothing wrong with that, truly. It’s just not what we wanted.
In the end, English isn’t a language. It’s infrastructure. Like Git, like CI/CD, like documentation. Either you have it, or you’re cut out.
It was uncomfortable. Some people struggled. But today, when I read pull request descriptions, messages, emails, I think it was worth it.
I stopped believing that good code speaks for itself #
This is perhaps the most dangerous lie in software engineering. The romantic idea that if code is clean, tested, well-structured, then its value is obvious. That technical merit can defend itself.
It doesn’t work like that.
Good code that nobody understands is indistinguishable from mediocre code. Refactoring that nobody talks about becomes a cost, not an investment. An architectural migration without a written business case looks like a whim from the engineering department.
I learned, late, that half of a tech leader’s job is storytelling.
Explaining to the board why a migration isn’t a luxury but risk reduction. Explaining to the client why the automated tests they paid for are the reason they sleep well. Explaining to the team why CI/CD isn’t bureaucracy but freedom and convenience.
If you can’t tell the value of what you build, someone else will tell it for you. And they’ll tell it badly.
The thing I still haven’t stopped doing #
If I want to be completely honest, there’s one thing I should stop doing and I still can’t.
Working as if I’m the only one holding the pieces together.
Too many things still go through me. Not because the team isn’t capable—quite the opposite—but because I still haven’t built the systems that make me redundant in each of the areas we operate in.
And that’s what scares me most.
Because every previous step had a clear replacement. Stop writing code? Specs. Stop writing specs? Strategy. Stop doing code review? A team lead. But stopping being the convergence point for everything is different.
The replacement is trust in systems. And systems, if I’m honest, I still have to finish building.
We’ll talk about it again.