Mentoring four people without one standard programme

Context

I mentored four people during two different periods of my career: two Scrum Masters and two Product Owners.

The first relationship developed informally. A junior Scrum Master worked in my department after the agile coach had left, and I became the nearest replacement. We met at least every two weeks and spoke throughout the working week.

The other three relationships came later, while I was a Product Owner and guild master. I joined a loosely defined company mentorship programme in which senior staff supported junior colleagues and people moving into new roles. I agreed to mentor both Scrum Masters and Product Owners.

The presenting problem

The formal programme partly served a company need: make delivery practices more consistent so the consultancy could describe a recognisable service to prospective clients. The people being mentored did not arrive with detailed statements of what they needed from me.

Their role labels suggested an obvious syllabus. A Scrum Master could be taught Scrum practices; a Product Owner could be taught product practices. That baseline material was sometimes necessary, but it did not describe the actual work of the relationships.

The underlying problem

Each person came from a different professional starting point.

One Scrum Master had a communication background and needed to understand software development as an empirical process before the ceremonies made sense. Another brought strong people skills from customer service and needed room for feedback and reflection more than a general introduction to working with people.

One Product Owner had years of test-management experience and needed to shift attention towards vision and communicating priorities. The other came from an entrepreneurial background and found the coordination and constraints of scaled software development difficult to adapt to.

The common problem was therefore not a missing body of role-specific content. It was finding the gap that mattered for the person in front of me.

What I did

I did not bring a fixed mentoring framework. I discovered needs through dialogue: asking what someone already knew, using scenarios from upcoming work, and questioning how they were thinking about a decision.

The form of support varied. At different times it involved doing work together, asking questions, shadowing, or teaching techniques. For someone starting with software delivery, the foundation was development as empirical and iterative work. A Scrum course introduced the practices; our continuing conversations connected those practices to agile principles and values.

Across the relationships, I repeatedly made room for reflection. Some people evaluated their work independently. Some used a structured document with me. Others reflected through conversation during a walk. The point was to stop long enough to derive a lesson from the work rather than moving directly to the next task.

What changed

I saw all four people develop rapidly within their respective roles while I worked with them.

One Scrum Master later led a new DevOps team in a newly established scaled business unit and subsequently became a Product Owner. A Product Owner with a test-management background became effective in the role quickly. Another Scrum Master continued developing over the two years we worked together.

The Product Owner from an entrepreneurial background continued to find scaled delivery difficult and later left to establish a life-coaching company. That was a change of environment, not an outcome I can reasonably classify as either a mentoring success or failure.

Evidence

My evidence is the work I observed: how the four people reasoned through upcoming situations, reflected on completed work, and took on their roles over time. Their later responsibilities and career moves are factual outcomes, but they are not proof that mentoring caused them.

There was no common assessment, comparative measure, or controlled evaluation. The relationships occurred in live organisations where managers, colleagues, opportunities, and the individuals’ own effort all mattered.

Limits

I cannot claim ownership of any of their achievements. I stood beside them while they developed; they did the work and made the career decisions.

What this demonstrates

People with the same role title do not necessarily need the same mentoring. The consistent element was not a syllabus but the discipline of finding the relevant gap and creating enough space to reflect on real work.