How do you split your time when you are a product owner and a software architect?

Question

I have a role that combines the role of product owner with a role of software architect. I have final say for both product and technical decisions:

• The Product owner role is similar as in scrum: I get requirement from my customers; I manage the product backlog, decide the priorities, decide which feature/requirement goes in which release. In a word I decide the product roadmap (of course, not alone but together with the team).

• My role of software architect is to make the most important technical decisions. For example, I decide which tech stack for frond-end, whether to use nodejs or php/laravel for back-end, and design the most important database designs.

This situation is the reality in my company. As far as I know this kind of combined role is quite common, especially for start up company. I came cross this answer from quora, described the similar role at amazon too "On some teams, there are no Product Managers, and the Dev Manager owns both the product/business and the technology."

Like every practice, it has pros and cons. One of advantages of taking these 2 roles together is that I can know whether a requirement is feasible or not or whether a feature is too big to be done in a single development cycle. And to delegate and work with the team is the key to do both roles right.

However both roles are time-consuming and availability of both are required for the team to operate well. How should I split my time between both roles? Is there any best practice?

P.S:

1. I'm not asking for scrum compliance or advices not to do this because it is the reality in my company.
2. I asked related question "Is there a well established name/title for a role taking the technical and product ownership together in the software industry?" at workplace.stackexchange.com because I felt that question was more workplace related. Too bad it was closed but I got 2 answers worth reading.

Answer 1

This is an interesting question about balancing potentially conflicting interests:

• Product owner is a role more than a person. As a product owner you want to prioritize the features that have most value for the users.
• Architect is not a scrum role, and architecture belongs to the team. So you have also a role of team member, equal to all the other team members in this capacity. As an architect you want to ensure the most lasting and robust architecture to cope with future evolution.

This leads to two major conflicts of interests (i.e. you’re biased in one role because of the other role):

• As product owner you want features early. As architect you want the foundations of the architecture first, which might require delaying some interesting features that do not fit with the challenges of the architecture.
• For the other team members it‘s not clear when you speak as product owner and when you speak as a peer team member. At worst the will just consider your viewpoint as not to be challenged (and you lose the collective intelligence of the team), at best it will create conflicts (and oblige you to be clearer about your roles and responsibilities), but affecting morale and team efficiency.

This tension is the most intense at the beginning of the project, since both roles are equally solicited. In my own experience you should divide time with some discipline, dedicating at least 2/3 for product ownership. Because insufficient time to take this responsibility endangers all the team and the value of its deliverables!

One trick is to allocate most time as product owner, a minimum time for the role as team member, and keep a free buffer to be allocated in priority to product ownership.

The conflicting situation decreases quickly once a stable architecture emerges. It is then not difficult to dedicate most of the time to product ownership. But you need to be aware of your own bias that might lure you away from product value to architectural perfection. It might remain until the end.

Answer 2

You've got yourself in a difficult situation and there's probably no good answer. This has nothing to do with Scrum compliance. There is no good way to wear both of those hats at once - there is way too much conflicting between the two - so you're going to be either switching. (the alternative would be to do both poorly, so switching is probably the best choice) The problem you're really facing is this: when you are PO there is no architect and when you are architect there is no PO.

Now, there is nothing to say you have to keep that constraint. What do you want? If you want to be on the Development Team, focus on architecture and find or train a PO who wants to do that. If you want to be the PO, work to build architectural competence in the team so they can make those architecture decisions themselves.

There's a lot of you questions in this situations. What do you want? What are you willing to let go of. As both PO and architect you have a lot of decision-making power consolidated into one person. Did you make this decision? If so, why? Did someone else make this decision? Why do they want to put it all on you? This situation is almost certainly much more of a people challenge than a time management one.

Answer 3

Delegate work to sub committees.

You need to make a technical call about which database to use? form a subcommittee for databases and get them to list the options, do some tests and recommend a solution. You review the work and approve the recommendation

You need to make a call on the priority of competing features? form a subcommittee for revenue maximization. Get them to review the options, write an exec summary on the pros and cons and make a recommendation. You review and approve

"Subcommittee" isn't a tech term,. but you could make something up, "ninja squadz"? The idea is to allow delegation while retaining authority. You can concentrate your time on the problematic decisions and make a reasonably informed choice, by accepting the recommendation, when you don't have enough time