Product Owner, Servant Leader? Part 1: Trust

When I first starting learning about Scrum I seem recall there being a lot of conversation and focus on the Scrum Master as a servant leader. What I also seem to recall was the fuzzy level of understanding that I gained over this time in regards to just what Servant Leadership really meant. In the years that have followed I’ve heard it mentioned less and less (at the same time I have not been actively seeking it out!) so my ears pricked up when a good friend (Samantha Hemmings) asked me the question:

“Should a Product Owner be a Servant Leader?”

What I wasn’t expecting was to have quite so much reflection and introspection on the topic (including growing my understanding of Servant Leadership). During my internet Servant Leadership meanderings I happened across the Servant Leadership Institutes “9 behaviours of a Servant Leader” which I quite liked so started comparing some of them to the Product Owner role.

What is Servant Leadership, quick recap.

There is so much written about Servant Leadership so it was straight forward reacquainting myself with the topic with this new question in mind. So not only did I check the Wikipedia article on the topic (I pushed the boat out and went a little further) I also looked at the work of Robert Greenleaf, The Servant Leadership Institute and Larry Spears 10 Servant Leader Behaviours all of which I would recommended reading if you have not done so before.

So to set the scene, in the words of Robert Greenleaf himself

The servant-leader is servant first. It begins with the natural feeling that one wants to serve. Then conscious choice brings one to aspire to lead. The best test is: do those served grow as persons: do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society; will they benefit, or, at least, not be further deprived?

(Greenleaf, 1977/2002)

Or to put it another way I quite like this description by Ann McGee-Cooper & Gary Looper which I feel relates well to an agile environment

Servant Leadership is empowering all employees to contribute towards decision making

Ann McGee-Cooper & Gary Looper, Pocket Guide to Servant Leadership

First of all I want to gloss over whether it is possible to truly empower anyone, assume that the empowerment is there and pick up on the sentiment of this statement, to be a Servant Leader is to serve first, create space and allow people to contribute towards and be responsible for (some) decision making. So how does that manifest if we think about the role of Product Owner? What does ‘serve’ mean in this context? How do you know when you are doing it? Here are some examples:

  • Educating others on the product, its users, customers, market forces et al.
  • Coaching and mentoring the team on soft skills that will help them build stronger relationships with the users.
  • Getting out the way so that the customer can lead the development with support from the development team/s
  • Letting people experiment with new product or technical ideas and innovations that can help drive the product
  • Letting development teams and users fail safely and learn quickly to enable growth in them and the product
  • Doing all of this by working with others to create a high trust, psychologically safe environment where teams are able to come to a decision and act upon it

I have made up a scenario to further frame this from a Product Ownership perspective.

There are 5 teams all working on the same collection of features and they are stuck on how to break down a newly discovered big, chunky feature. As The Product Owner finds this frustrating, she feels she has the answer.

The Product Owner would not be a Servant Leader in this situation if they were to

  • Break it down into not so big pieces for them
  • Order the all resultant Product Backlog Items for them
  • Only give them the tasks she believed they can do comfortably
  • Dictate to them how they should slice it and track their progress whilst doing so.
  • Go to the users, help them think through what would be valuable and useful for them and then bring this back to the team

Behaving in this way whilst seemingly effective in the short term and conceptually simple (which is attracting for many) it strips away team empowerment, growth, autonomy and pride making this the antithesis of Servant Leadership. Often when I have observed this it is because of a lack of trust and regularly correlates to a Product Owner’s stress level.

Trust always affects two measurable outcomes: speed and cost. When trust goes down—in a relationship, on a team, in a company, in an industry, with a customer—speed decreases with it. Everything takes longer. Simultaneously, costs increase. Redundancy processes, with everyone checking up on everyone else, cost more. In relationships, on teams, in companies, that’s a tax. I call it a low-trust tax where literally everything is being taxed off the top. Where trust is low, everything takes longer and costs more.

Stephen M.R. Covey, Forbes July 2018

If I take Stephen Covey’s quote and explain it in relation to the above scenario: if a Product Owner does not help to nurture and build the team capabilities then it will be difficult for them to extend trust. With no trust being extended the team will depend upon the Product Owner to design their work thus diminishing their credentials and experience as a self-managing team.

Build Trust

Are you trustworthy? Are you willing to extend trust to others?

In Large Scale Scrum (LeSS) one of the most mind altering concepts it presented to me was the Product Owner Five Relationships. It affected me so much because it answered many questions I had about how a Product Owner works with multiple teams and have those teams be close to what agile was meant to be.

It’s no secret that great relationships are built upon a foundation of mutual trust. If I follow this logic through and think of my original question then this seems like a great opportunity for a Product Owner to act as Servant Leader in the interests of helping to create and nurture these relationships.

I could see a Product Owner educating development teams (and perhaps others) on practices and techniques that help relationships blossom over time and increases everyone’s capability.

There is also another area where the Product Owner will most likely have skills that if executed well could go a long way to increase trust, prioritisation. I believe teams should have skills in prioritisation as in an agile environment with them spending so much time directly interacting with the users and (in a LeSS environment) with the Product Owner focusing on direction over clarification when a team can prioritise well and are delivering increasingly valuable software this not only builds trust between the team and users but also between the Product Owner  and teams.

Of course these are also areas in which a Scrum Master, Coach, Mentor or other person may be able to offer assistance too, I am in no way discounting this simply presenting another option.

If we now think back to the previous non-Servant Leader Product Owner example, how would they look if we had trust and good relationships?

  • Break it down into not so big pieces for them
    • She guides the team through some options and lets them experiment. She could also keep asking questions to help them reflect on their choices.
  • Order the all resultant Product Backlog Items for them
    • The team and users work together to order them
  • Only give them the tasks you believe they can do comfortably
    • Let the team choose tasks that challenge them and trust the Scrum Master to help them maximise their learning and have them seek the right type of support
  • Dictate to them how they should slice it and track their progress whilst doing so.
    • Leave them to it and make sure the team are clear on where they are heading and why. With this situation your chances of the team feeling compelled to monitor and manage their own progress increases.
  • Go to the users, help them think through what would be valuable and useful for them and then bring this back to the team
    • Spend some time to help nurture the relationships between the teams and users so that they can work through their options and find something that balances the value/usefulness of each item and how the team feel it would be good to approach the work

Closing thoughts

I feel it is an imperative for a Product Owner to build trust within a Servant Leadership context to be true to Scrum and help develop a safe and positive environment where people and products flourish due in large part to them having space, feeling empowered and acting upon it.

Some Product Owners do not trust the teams and/or the users (perhaps with good reason) which then affects the speed of the delivery and their personal lives due to always feeling like you have to be in every conversation.

If you can build trust you can preserve your sanity and get home in time for dinner.

Ben, last week.

You can then get out the way of the development team and users and focus on direction over clarification and take a step closer to one of my favourite and always most debated of agile principles

Business people and developers must work together daily throughout the project.

My eyes are open as to the reasons why trust may have evaporated or was never present. In my experience it is usually because of a lack of capability (teams and Product Owners alike) and/or a lack of clarity over direction. B

I am not saying anything I have mentioned is easy. What I am saying is the things in life that are really worth working for are rarely (if ever) the easy ones to achieve.

Photo by Bernard Hermant on Unsplash