The best project managers are servant leaders

Today he runs digital projects at FIBA, the world governing body for basketball. He led the two-and-a-half-year rebuild of FIBA's digital ecosystem, including a website factory behind more than 80 event sites a year, and is now revamping its 7 mobile apps.

We got into what a servant leader actually does, why stakeholders are harder than teams, how to say no to a feature everyone calls critical, and what it took to launch a new platform in time for the 2024 Olympics.

Watch the episode on YouTube

Key takeaways#

What is a servant leader in project management?#

A servant leader is the person whose job is to help everyone else deliver. Yann points out that a project manager is rarely anyone's line manager. What you bring is the overview: the vision, the strategy, the objective. From there your work is to build a safe, productive environment so people can be as efficient as possible. If someone hits an issue, you remove it. If a stakeholder has a need, you work out how to answer it. In his words: "You're just there to help people deliver the project."

Try this: ask each person on your team one question this week: what's slowing you down? Remove one of those things before Friday.

Will AI replace project managers?#

Yann's answer is no, at least so far, because the core of the job is people. He uses AI in development, where it buys quality and time, and is starting to try it for project management. Monitoring, tracking and risk evaluation can go to AI, and he's all for it. "The one thing that AI won't be able to replace, at least so far, is the people management." The more time a project manager can spend on communication and coordination, the better it is for the project.

Try this: list the reporting tasks you repeat every week. Automate one, and put the hour you get back into 1:1s.

Which skills should project managers build for the next few years?#

Adaptation, first. Yann has worked in telecoms, logistics, software development and now international sport, and from each job he took what he calls "the positive package" to add to his wallet and reuse in the next context. The world moves fast, and five years ago we didn't have to work with AI. The second skill is giving people room. Teams are more and more autonomous, and the job is to give them the freedom to be the best version of themselves while you hold the team spirit and the coordination together.

Try this: write down one technique from a previous job or industry you've stopped using. Bring it into your current project and see if it still works.

Why do former developers make good project managers?#

Because they speak both languages. Yann started as a developer, and an internship project building WiFi monitoring pulled him into project management. That background means he's never lost when developers get technical. He can translate technical constraints into business language and the other way round, and explain to the business why the answer is to update a process rather than buy a new solution. It also means he can challenge and anticipate without being the person who arrives from nowhere and says "do that."

Try this: if you don't have a technical background, ask a developer to walk you through one constraint on your current project until you can explain it to a stakeholder yourself.

How do you motivate a project team when things get tough?#

You read the person first. Yann doesn't have a trick. Some people need clear directions. Others need freedom for their creativity. Some like to be rewarded in front of everyone, others would rather work in the shadow and never be congratulated publicly. The payoff is trust: when someone has a good relationship with their project manager, they're far more likely to raise constraints, problems and issues early, and to feel confident doing it.

Try this: next 1:1, ask how the person likes to be recognised for good work. Write the answer down and use it.

Why are stakeholders harder to manage than teams?#

Because you get time with a team, and sometimes you pick them. When Yann runs an RFP, he's often recruiting the technical team or partner himself, so he knows their spirit before the work starts. Stakeholders arrive with their own priorities and their own vision of the project. The job is to understand those priorities and include them without losing the key objective and the strategy you've set. Yann's advice is to bring stakeholders along on the adventure and maybe over-communicate, so they feel included and consulted from start to finish.

Try this: send every key stakeholder a 3-line progress note this week, even the ones who haven't asked. Silence is where surprises start.

How do you decide what not to build when every stakeholder says their feature is critical?#

You earn the right to say no long before the request lands. At the very start of a project, Yann talks with each stakeholder about their needs, priorities and expectations. During the project, he keeps communicating on progress, constraints and ongoing work. So when a new request appears after the goals are set, he first works out why it's being asked and what it's really about. Then he answers with facts. If the stakeholder has been informed all along, the decision is understood and respected, even when it isn't the one they wanted.

Try this: next time you push back on a request, write the reason in two sentences tied to the project objective before you send it. If you can't, it's probably not a no yet.

How should you adapt agile to a real project?#

Take what fits your context and drop what doesn't. Yann did his agile training while working in software, where the framework fits naturally. Outside that, with fixed budgets and fixed dates, theory and reality split. His example: sometimes you do the analysis in waterfall first, to build the backbone of the project, and only then scope the work into sprints. The fixed base protects a fixed budget, and the sprints absorb delays.

Try this: list the agile ceremonies your team runs. Cut the one your team wouldn't miss, and keep the ones that actually catch problems.

What can team sports teach us about project teams?#

Every role has to play its part or you can't win. Yann plays football and works in basketball, and he maps it directly. The coach sets the frame, like a scrum master. The captain makes sure teammates respect the tactics and talks to the referee, the way a product manager deals with external stakeholders. Then there are positions: business analyst, project manager, backend developer, frontend developer, infrastructure. "If we are missing one of the skills, we cannot deliver." The project manager's job is to act as captain, so each person hits their own goals and the whole team wins.

Try this: draw your project team as a line-up. Any empty position is a risk you should name now.

How do you deliver a global digital platform against an Olympic deadline?#

Fix the date, then plan backwards. FIBA runs what Yann calls a website factory: a site for every event, more than 80 events a year. The project was to build a new engine while keeping the old one running, because competitions never stop and fans have to be served. It started in March 2022. The analysis phase was long and essential. Every FIBA region and business unit had its own spot in the old digital footprint and wanted a better one in the new. That shaped a new corporate website and all the event websites. The development partner had to learn basketball's rules and what content to show at each moment of a competition. The target was set at the start: the Olympics 2024. Yann built a retro planning to make sure they hit it. The corporate site followed three months later.

Try this: find the one date on your project that cannot move. Plan every milestone backwards from it, and share that plan with stakeholders on day one.

How do you get people to adopt a new platform?#

Bring the key stakeholders in from the very beginning. Yann calls the FIBA project the biggest thing he's delivered: two and a half years, millions in budget, and something significant for a lot of people worldwide. He involved key stakeholders from different areas early so they could contribute, and so they could tell their own teams what was coming, what would change and how they'd contribute. That's what made the transition, the training and the adoption smoother. People who have worked with a tool for years have their own prism, and they can be afraid of the change.

Try this: pick one person in each team affected by your next rollout and give them a role in the project now. They'll carry the message better than any announcement.

---

Listen & watch#

• Watch the episode on YouTube
• Listen on Spotify
• Listen on Apple Podcasts
• All episodes at infinum.com/delivered DELIVERED is a production of Infinum and Your Majesty.