Part 4: The Chief Technical Product Owner

In part 3 of this series, Herbert introduced the role of Technical Product owner as a counter part of the (Functional) Product Owner. Before Product Owners and Technical Product Owners can start their work, high-level priorities need to be set by upper management. In this post the Chief Technical Product Owner is introduced. He represents the technical perspective in this high-level prioritization phase.

Getting Things Prioritized

In a typical company, there are many requests for new functionality. Usually, the number of requests exceeds the realization capacity by far. Therefore, early on in the process, choices have to be made. Functionality can be picked up in the order of priority. And priority is a result of expected business value, relative cost and feasibility.
Early on in the process, it is difficult to estimate the effort to realize it. Usually, at that stage a functional request has not been analyzed, detailed or scoped strictly. Providing a low estimate gives the business owner a blank check to later on design the user story in such a way that it is more expensive to build than initially estimated. They can refer to the initial low estimate when IT says “no”.
Providing a high estimate may block the feature from ever getting picked up. The business owner may look for external parties to realize the functionality without involving IT. As a result, there are even worse architectural incompatibilities.
In the agile organization model sketched in the first post, there is a phase designated for prioritization of features. For a large part, prioritization is done by business managers. Many business managers have no idea of technology. They cannot estimate the technical size of a story.
Some functional requirements depend on larger technical changes. For people with a technical background, it seems difficult to explain the value of such technical changes to business managers. Especially when talking to upper management. This is where the Chief Technical Product Owner (CTPO) comes into play.

The Chief Technical Product Owner

The Chief Technical Product Owner is a specialized Technical Product Owner who distinguishes himself from the others with political sensitivity and the ability to communicate and negotiate with upper management. He helps the business decide which functionalities should be picked up in what order and how to improve the non-functional qualities of the system.
In an ideal world, stories should be prioritized strictly on business value. In the real world there are practical and technical hurdles to overcome like legacy systems and technical debt. Sometimes, in order to pick up a set of user stories, in an effective way, a technical change needs to be made first.
The Chief Technical Product Owner distinguishes himself from the Technical Product Owner by being more focused on the management. The Technical Product Owner is more focused on the team.
On the other hand, the Chief Technical Product Owner needs to have an understanding of technology in the Ready, Done and Production phase. For example, when the system operators are haunted by production issues, the CTPO should convince upper management to take actions that provide a structural solution on the long run rather than loading the teams with large piles of new functionality to build.
To do this, the CTPO is a high profile function. If you draw a comparison with traditional IT organization, the manager of the architecture department may be best capable of fulfilling this position. If no manager is available for this position, you could consider one of your enterprise architects to fulfill the role of CTPO. Make sure that upper management trusts this person and that he is sensitive to the technological challenges in the IT organization.

What is next?

With the roles of CTPO and TPO, the prioritization and specification phases of a user story’s lifecycle are well-managed. In terms of classic architects, the architecture manager / enterprise architect and information architect are replaced with more agile roles. The next post will discuss the architectural responsibilities of the Senior Software Engineer in an agile organization.
Stay tuned!