One Neck to Ring

This post is an extension of What Did The Boss Say. In that post, we explored why executives and managers tend to want a single point of control or responsibility, as well as some of the things that must be delegated to that single point. But there are disadvantages to the single point strategy.

When contemplating a large software program, one that spans specific systems and vendors as well as serving multiple internal business units the single point strategy can run into some issues. Those issues tend to fall into the following categories:

Capacity

Does the single point of control have the capacity to exert control? Is this their “only” job responsibility or one of many concerns they oversee? We make them responsible, but what happens when they “take their eye off the ball”? The answer is that the ball ends up in the bunker or the weeds. What is our model/process for increasing the capacity of governance? In the single point strategy, that answer is that we either take other responsibilities away from the single point or we re-assign responsibility for THIS program to someone else.

Perspective

With any single point of control, we have a single perspective on what is important. Perspective implies bias – we all look at things from a particular angle. The person assigned will naturally steer the program based on their knowledge and experience. If the program must cover business aspects beyond the experience of the single point, risk increases. Managers are paid to make decisions. Some are very good at gathering, analyzing and organizing information, but it is very hard for any of us to remove the bias of our own experience from our decision making.

Incentive

You get what you incent. If the single point of control is incented to meet certain objectives, and her responsibilities extend beyond the program in question, or are bound to a business unit that is one of several exerting influence over the direction of the program, then she may have a conflict of interest between meeting her incentives for that business unit and balancing that business influence with that of others.

— While there are probably more issues than this, I think these are enough to contend with. They argue for a model of product ownership that can scale the capacity of product ownership when needful. They argue for model of product ownership that allows for some diversification – so that governance of the product is not resting solely on one person/perspective. They argue for a model of product ownership that creates incentives for the owner based on the valuation of the product exclusive of business objectives.

The Portfolio Analogy

If we think of the software product (or group of products providing needed capabilities) as a portfolio (like your 401K) – you want an un-emotional, unbiased highly skilled manager making decisions about what to invest in, based on a methodology that makes sense; One who has no relationship or incentive to steer your investment in a particular way. You want a manager who has sufficient understanding of all the risk and return properties of the different investment choices who will tune the portfolio to meet the investor’s needs. If the portfolio has multiple investors, you want that manager to have no direct affiliations with any specific investor, so that all of the investors are treated fairly sharing equally in the returns while they remain invested.

The Business Owner

The idea of a “business owner” of a software product works moderately well, when the stars align. When the business owner knows enough about investing in software to make good investment decisions. When the business owner is one of the investors in the product, she is the majority investor. When she understands enough about the goals of the other investors that she can adequately represent them. When she has the capacity to focus on product decisions that need to be made.

The Technology Owner

The idea of a “technical owner” for a software product, can work when your technology folks or at least one is business savvy; when he has the perspective to understand the business value represented within the software capabilities. When he is incented by business goals and results rather than technology process. When he has the authority to balance investor needs and investors don’t simply escalate through their management around him. When he has the capacity to focus on the way that the software meets business need, in addition to any purely technical or process issues he must focus on.

The Portfolio Manager

The idea of software as an asset – means that I have a portfolio of software capabilities. The software capabilities do not produce a return unless they are used. The portfolio manager does not invest in capabilities that will not get used, he owes each investor returns on investment as fast as possible. He can explains the risks of specific investments and the implications of those risks – not only for one investor, but to all investors. He balances long term returns with short term returns, as well as transaction costs. His number one job is to grow the value of the portfolio in terms of the business value that each investor receives from the portfolio. The number of products in the portfolio does not matter – he chooses which product to invest for each capability to get the best value and risk.

No Comments

Leave a Reply