Last week, I got the question in this story title from an ex-colleague whose organization has recently started implementing Scrum.
My former colleague understood the theory that there is no such role as "principal software engineer" in Scrum, but his problem was a typical one that most organizations new to Scrum find themselves facing.
The organization had a profile with superior technical knowledge, experience, and intellect. The senior operational management of this organization wanted the principal software engineer to assume the product owner role.
But my ex-colleague felt that might not work well and so called me to seek my opinion. Here's what I said:
The principal software engineer is
not a good choice for the product owner role.
While Scrum doesn't say that the principal software engineer cannot assume the product owner role, it is not a good fit for the skill set of a principal software engineer.
In Scrum, there are three roles: the product owner, who owns the product; the ScrumMaster, who owns the process of developing the product and works toward removing the impediments; and the team members, who carry out the development activities.
Consider what Roman Pichler writes about the chief duties of the product owner in this article
"The product owner is required to closely collaborate with the team on an ongoing basis and to guide and direct the team (e.g., by actively managing the product backlog, answering questions when they arise, providing feedback, and signing off work results). In simple terms, the product owner sits in the driver's seat, deciding what should be done and when the software should be shipped."
Is this what a principal software engineer's core competence is?
One of the most important points Scrum makes is this: Self-organize in a way that gets the value delivered, as fast as possible.
Will the optimum value be delivered if the principal software engineer is operating in another function (in our case, as the product owner), which requires a different kind of competence?
Typically, a principal software engineer would be biased toward getting the activities done, and he'd subconsciously take the "service" side, not the "direction" side.
While in theory there is no such thing as a "side" in Scrum, as human beings we are generally not good at unlearning -- so we bring our biases from past experiences into new arrangements without even noticing.
So, a principal software engineer, lead developer, or technical lead as a product owner is not a good idea.
Sure, there might be exceptions, and a few organizations might have seen some success with that -- but in principle, it should be avoided.
The key take-home point: If the person responsible for a particular task is not operating from his strength, from his core competence, then it's not a good idea to let the person perform that particular task.
What does your experience suggest? Have you observed a case where the principal software engineer acted as product owner and immense value was delivered? Let's open a dialogue and learn from each other's experiences.