From SWE to Engineering Manager: a career crossroads in the age of AI

The transition from Software Engineer to Engineering Manager should not be seen as a natural promotion, nor as a simple change in responsibilities. It is a true career crossroads.

When I was offered the opportunity to change roles, I honestly didn’t fully understand all the implications. I became a manager in a rather unconscious way, but it didn’t weigh on me: fortunately, it turned out to be a role that fit me very well. As a Tech Lead, I was already influencing my team and had gradually taken on responsibilities related to people management and growth.

What felt almost natural to me, however, is not necessarily the case for everyone. Becoming an Engineering Manager also means giving up an important part of one’s identity as an engineer: the immediate feedback loop of code, the satisfaction of “closing” a task, the feeling of direct control over the outcome. It is not the natural next step for a Software Engineer, because it requires a set of soft skills that are nice-to-have but not must-have for an individual contributor. On the contrary, my personal conviction is that a background as a Software Engineer is, by far, the best possible foundation for becoming an Engineering Manager.

From a practical standpoint, my transition started as an addition: management responsibilities layered on top of a technical leadership role. Over time, this gradually eroded the time and energy I could dedicate to hands-on contribution, until I reached a sustainable balance. Timing and pace are highly subjective and depend on the organization and the people involved, but I firmly believe that a gradual transition is a healthy one.

Communication

If I had to choose a single fundamental soft skill that a Software Engineer needs in order to become an Engineering Manager, I would say communication. The ability to communicate clearly and effectively makes all the difference. That doesn’t mean it has to be an innate talent, it can absolutely be developed, but different people typically progress at different speeds and achieve different results.

Balanced communication is extremely hard. It’s a skill where perfection is unattainable, but meaningful improvement is always possible. The most common mistakes I’ve personally made over the years include:

• being verbose, especially confusing clarity with the amount of information shared
• speaking when it would have been better to listen
• failing to strike the right balance between firmness and openness to dialogue
• the absence of communication: avoiding difficult conversations and letting problems fester instead of addressing them early

Leadership

Closely following communication, in my view, comes leadership, which is deeply connected to it. As for what leadership means, my personal interpretation is that leadership is the ability to guide: to point in the right direction and make others willing to follow.

Leadership is a situational discipline. Theory tells us that depending on the context, one might need to be more directive, visionary, or supportive. In any case, in my experience, the most effective approach has been leading by example. Leading by example works because it builds credibility and coherence, reduces the gap between words and actions, and accelerates learning. Every time I’ve been able to concretely show a team how to solve a problem, I’ve achieved two outcomes at once: they learned and they gained trust in me.

That said, leading by example is costly in terms of time, energy and required expertise. It cannot be done continuously, it simply doesn’t scale. The risk is turning it into an automatic reflex rather than an intentional tool. Used selectively but consistently, especially in the early months of working with a team, it can be extremely valuable.

Engineering in bold, Manager in italics

To lead a team of engineers by example, strong technical skills are required. As mentioned earlier, we cannot be experts in everything, so we must alternate, honestly and transparently, between moments where we actively contribute and moments where we rely on the team’s expertise, delegate decisions to them, and simply supervise.

To do both effectively, however, an Engineering Manager needs a solid technical background. This is why I often say that my way of seeing and interpreting the role is with Engineering in bold and Manager in italics. I don’t want to be misunderstood: I fully recognize the importance of the managerial side, and I firmly believe that a pure people manager can achieve extraordinary results with teams of great engineers. That said, my experience has always been with teams that, in one way or another, needed technological guidance.

Moreover, we are living in an era of transformation driven by the rise of GenAI, where we must assess both opportunities and risks of new tools and new ways of working. Without technical guidance, AI adoption risks becoming noisy rather than effective.

Inspected trust

The biggest risk of being a manager who gets their hands dirty is doing it too much. I’ve heard countless colleagues and experts warn about the micromanagement that can stem from being overly operational. This approach might catch problems early, but at an enormous cost: it destroys team morale, prevents growth, creates bottlenecks, and ultimately doesn’t scale. The manager becomes a single point of failure and burns out trying to be everywhere at once.

At the same time, I’ve seen managers lose touch with the reality of their teams and delegate blindly, almost as an act of faith. Blind trust assumes everything is going well until proven otherwise. The problem is that by the time you have proof, the damage is often already done.

The approach that best reflects my view of trust and delegation is the one articulated very clearly by Will Larson in one of his books: inspected trust. The idea is simple but powerful: trust your team to do the right thing, but create intentional mechanisms to verify that things are on track. The key word here is “intentional”. Inspection should not be random or driven by anxiety. It should be systematic, transparent, and designed to help rather than control.

In practice, this management style translates into three concrete initiatives:

• work transparency: a small set of truly meaningful KPIs, periodic demos, documented decisions and any other tool that enables autonomous and non-intrusive inspection
• strategic deep dives: occasionally going deep into a task, sometimes even participating in a sprint, provides a very efficient understanding of how the team works and creates opportunities to contribute (lead by example)
• 1:1s (including skip-levels) where personal perspectives on technical topics are openly discussed

To code or not to code, that is the question

If you ask an Engineering Manager whether they miss hands-on development, they will almost certainly say yes. I believe some lie, fearing that saying otherwise might make them look like pure people managers without technical skills. Others say it with conviction and usually try to carve out time to code, even on personal projects, because they still genuinely enjoy it. I belong to this second group.

AI does not eliminate the need for technical skills, but it lowers the barrier to exercising them effectively, even when you’re no longer hands-on every day. In this sense, I find AI to be a tremendous enabler. As an Engineering Manager, it is one of the most tangible benefits I’ve experienced personally, and I make extensive use of it.

I believe that carving out time to be operational within a team (once a month, once a quarter or even once a year, depending on how many teams you manage) has immense value. Many times, I’ve identified blockers, potential optimizations, or critical issues in a project just minutes after cloning a repository, issues that had not surfaced through conversations alone.

In my interpretation of this role, getting your hands dirty is extremely valuable. The hard part is doing it in the right measure, without becoming inefficient.

Conclusion

It’s not uncommon to hear about Software Engineers who tried the management path, found it unsatisfying, and returned to being individual contributors. That makes sense, because, as mentioned, it’s not a natural evolution, but a genuine crossroads. In my case, the opposite happened: I firmly believe this experience has helped me grow professionally.

There are two aspects of being an Engineering Manager that I particularly value and consider the main rewards of this role:

• the growth of people, especially those you manage to positively influence or help change course
• the ability to have an impact at scale through your teams, far greater than what you could achieve as an individual contributor

In full transparency, this is my experience after several years in the role. I hope it can be useful or inspiring for those who find themselves at that crossroads today, wondering what lies ahead.