Experiences and Opinions About the Technical Product Owner
In my current organization I came across the technical product owner figure, which acts like between the developer team and the product owner. Actually in my organization the technical PO also has a role as Scrun master and developer team member as architect, all in the same team, but that is another issue I won't discuss here...
I would like to hear opinions and experiences about the technical product owner figure. I know the Scrum Guide does not mention such figure. What that title brings to my mind, is that the organization does not trust the product owner nor the developers, so instead of empowering or helping them bridge any eventual skill gap, they add a further role to control them.
. It depends on how this role is implemented. Some scaled agile frameworks have a 'system architect' role to ensure system-wide consistency.
However, based on what you describe, my first thought is that there is too much wrapped up in this one role, and I can understand your concern that it may be misused to circumvent the team's self-management. This role is likely a hub or central admin where all decisions pass through, which is not ideal.
they add a further role to control them.
Are they adding a role or just rebranding a current one, so existing control structures are maintained and change is avoided?
Remember that the Scrum Guide provides 3 sets of responsibilities and not 3 job titles. The job titles that an organization chooses to use has nothing to do with the Scrum framework. And it is possible for multiple individuals to with varying job titles to fulfill the responsibilities that are listed in the Scrum Guide. For example, Developers in the Guide could have titles such as Software Engineer, Quality Assurance Engineer, DevOps Engineer, UX Designer, Data Engineer, Software Development Engineer in Test, or Architect. The job titles do not have to match the responsibility title.
There are also no job descriptions in the Scrum Guide. Every organization that I have encountered still uses job descriptions for which a job title has been assigned. Those job descriptions describe the work that and responsibilities that the organization expects that individual with that title to fulfill.
@Ian's comment is unfortunately the sad truth in most instances. A common example is that Project Managers often become Scrum Masters in title but their job description remains the same. My advice is not to get too hung up on the job titles and instead look at the nature of the work that is being done. Are the responsibilities provided by the Scrum Guide being considered in the work/responsibilities being provided in the job descriptions? Is the work that is being done providing the value that is described in the Scrum Guide? Does the organization understand the value and purpose of the Scrum framework and are they benefiting from it?
Thank you for the insightful comments. The fact that the Scrum Guode describes 3 sets of responsibilities and not 3 job titles is fundamental, and a fact I tend to ferget. I believe issues arise when the same person holds more than one set of responsibilities, which might in some cases be conflicting and meant to balance each other. Or if the responsibilities are not clearly denied. For example, if it is not clealry defined what are the responsibilities of the technical PO vs the PO or the development team.