Team Mentoring

When mentoring is the right fit

When all the knowledge about the infrastructure lives in one person's head, the problem is not just operational: it is structural. Hiring a full-time senior engineer can solve it, but the right person to make the most of the existing team is not always easy to find quickly.

Mentoring, working alongside the team, is the right path for teams that need to grow organically and become autonomous. These are usually small teams, often overloaded: capable people who need a clear direction and someone to talk through the important decisions with.

With AI agents, the hard part is deciding what to do

AI agents have made doing things much faster: writing code, changing infrastructure, producing configuration and documentation. What has not become any easier is deciding what to do, and in what order.

This is not a detail. A team working with agents without a clear direction can produce, in very little time, an enormous amount of changes in the wrong direction. Speed amplifies decisions, the right ones as much as the wrong ones. Losing your way is easier, and you notice the mistake later.

That is why today the value of mentoring lies above all in the decisions: setting goals, choosing priorities, recognizing when an activity is not delivering results and stopping it in time.

How I work

I work with the team as a fractional lead: I help define the strategy and follow the project over time, so that we aim at the right goals and do not waste energy on work with little impact. We tackle problems together, review architectures and processes, and introduce good practices from day one.

Ways of working:

• Design sessions for the most important architectural decisions.
• Pairing on real problems, side by side on the same code or the same infrastructure.
• Weekly or fortnightly meetings to take stock, review the board and realign priorities.
• Code review, including for infrastructure.
• Dedicated training sessions, alternated with project work, to consolidate the fundamentals where needed.

What the team keeps

The goal is to leave the team with a way of working that is more solid, autonomous and sustainable even after the engagement ends. In practice:

• Infrastructure as code, versioned, reproducible and reviewed like all other code.
• An incident management playbook: who does what, how to communicate, how to analyze what happened.
• Development and debugging with agents: the team knows how to use AI agents to build and to analyze failures and anomalies, giving them the right context and the right boundaries.
• Documentation generated and maintained automatically, instead of pages written once and never updated again.

Mentoring, project or course?

They are three different tools. A project is what you need when there is a precise technical outcome to reach by a certain date. A course is what you need when the team needs a shared foundation on a technology. Mentoring is what you need when the goal is the growth of the team itself: its skills, its habits, the way it makes decisions.

The three often combine: a mentoring engagement can include training sessions, or deliver concrete projects along the way.

Growing the team, including with new people

I regularly take part in interviews and in selecting new team members. When the time comes to hire an internal senior figure, such as a Head of Platform, I help define the role, evaluate candidates and manage the handover.