Technical leadership and IT project management: real cases

This section covers the part of the job that does not live in execution plans: decisions, teams, method. It is the space of technical leadership, where people, systems and choices have to work together.

I’ve seen project managers make senior developers cry in meetings. I’ve seen brilliant teams destroyed by PMs who confused authority with authoritarianism. I’ve seen software delivered “on time” that didn’t work, and multi-million euro projects that ended in nothing.

And I’ve seen the exact opposite: small, autonomous, respected teams — building solid systems in a fraction of the time and budget.

The difference was never technology. It was always the method.

After thirty years in this profession, I’ve understood one thing: people don’t give their best when they’re afraid. They give their best when they have trust.

Trust in the team. Trust in the process. Trust that if they make mistakes, they won’t be punished — they’ll be helped.

The project manager who works isn’t the one who controls, terrorises and counts hours. It’s the one who:

sets clear objectives and gives the team the freedom to achieve them
builds deep competencies and protects them from turnover
does team building every day, not once a year at the go-kart track
measures results, not hours in the office
uses smart working as a competitive advantage, not as a concession
when something goes wrong, stands in front of the team, not behind it

📊 How I work #

My approach is Scrum — but Scrum done properly, not the liturgy of post-it notes.

Scrum that works is based on a pact: radical transparency, shared responsibility, and autonomy in the “how”. The PM defines the what and the why. The team decides the how. Because those who write the code know better than anyone how to write it.

And this pact works even better with smart working. The daily standup? 15 minutes on a call. The sprint review? Screen sharing with the client, who sees the software — not slides. The retrospective? An hour where the team tells the truth, because there’s no PM two metres away staring them down.

I measure few things, but I measure them well:

Metric	What it tells you
Velocity	How much the team delivers per sprint
Lead time	How long from request to release
Bug escape rate	How many defects slip into production
Sprint goal success	% of sprint goals achieved
Team happiness	How the team feels — the most important metric

The last one — team happiness — is the one traditional PMs never measure. A happy team isn’t a team that’s having fun. It’s a team that feels respected, heard and valued. And a team like that produces more. Not because they work more hours. Because they work better.

📚 What I write about here #

True stories, hard numbers and lessons learned. No textbook theory. Just what I’ve seen work — and what I’ve seen fail.

I write about artificial intelligence applied to workflow, IT consulting and its hidden costs, smart working as a competitive advantage. Every article comes from a real experience — mine.

No revolutions needed. Just precise choices, implemented with method.

And the ability to say “no” to those who sell you complexity when the solution is simple.