Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Product Owner micro-managing developers - advice needed

Last post 09:47 pm January 19, 2023 by David Sabine
3 replies
06:07 pm January 18, 2023

I have a product owner that is micromanaging some of our developers. Specifically, this person is rewriting code for the devs (the PO used to be a developer). I have not witnessed this first hand but was told about it (I'm the scrum master on the team). Anyone have advice on how I can gently remind the PO of their role in a scrum team? If I need to have the blunt conversation of "don't do this" I will but I'd like to try a softer approach with this person first.

Would appreciate any advice!


08:22 pm January 18, 2023

Are you sure the PO stopped being a developer? Was it a decision he or she was happy with and was it helpful to others? Why was that decision made and by whom?


08:55 pm January 18, 2023

There is nothing that says an individual that fulfills the Product Owner accountability can't also help fulfill the Developers accountability.  In fact the Scrum Guide states in the section that describes the Daily Scrum that: 

If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

Remember that the 3 accountabilities in the Scrum Guide are not job descriptions or job titles.  There is nothing that says someone has to have a job title of "Developer" to fulfill that accountability.  

However, this individual seems to be acting as a command-control manager for the other Developers.  That is the part that you might want to have a conversation about.  They are taking away an opportunity for the others on the team to learn, self-organize, self-manage to deliver the usable increments of value.  This might be a conversation worth having with the individual.


09:47 pm January 19, 2023

It's natural from people to struggle to relinquish control of things as they grow into leading roles. It sounds to me that this Product Owner is struggling to move out of their previous territory.

I'd try to determine if this person is adjusting/contributing to code out of sheer *opinion* or if their skill is significantly different and better than the others. I've dealt with both scenarios:

- If the person is largely driven by opinion in this case ("I want the code to be this way, I prefer my way to the way others wrote it") then they need help to relinquish control and to trust. The others in the team will have to earn that trust and prove their code is up to standard.
 

- If this person is in highly skilled and their code is objectively better than the others', then they need help to share knowledge, patterns, techniques with the other developers.

 

Either way, I'd consider pair-programming, mobbing, and technical demonstrations. The team must establish acceptable patterns and must grow to know and fully understand each other's code styles/tendencies.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.