The Feature Owner

One of the strongest concepts I learned in Check Point is “Ownership”. For almost any task there is an “owner”. The term “owner” is quite different than “manager”. On one hand it implies emotional attachment and on the other hand it implies you don’t have to be a manager to have responsibility.

The simplest way to describe the owner function that the owner bares the sole responsibility to finish the task he owns. He is accountable.   The “Feature Owner” is a specific example for an ownership within the R&D organization (which is actually called “products organization” in Check Point).

How does it work?

The product manager wants a new feature added to the on-line application. Let’s assume the feature is a new usage report for an on-line application. The group manager chooses a Sara to be the feature owner. Sara is a senior developer.

Sara now owns the entire life cycle of the feature: requirements, design, user experience, coding, testing, documentation, upgrade and deployment.

At first this seems very strange. As the lead developer on the project Sara would not have time to work on all the other tasks, and if she does, who will do the coding?

Furthermore, Sara does not have the skills to write an MRD or describe the user experience since she is “Just” a database programmer.  

The trick here is that Sara does not need to do everything on her own. As the owner she has ad-hoc managerial power to push other people to do their work. She demands requirements from the product manager, pushes QA for the test design and nags tech writers for better version.

There are multiple advantages to this approach:

  • 1. Sara has to know what the product goals of the feature are.
  • 2. Sara has to take into account testing, tech writing and other considerations she would otherwise ignore. The nice thing is that she can make changes in coding to help them.
  • 3. There is a clear owner for the task success with a strong emotional attachment.
  • 4. The feature owner has strong technical understanding of the feature.
  • 5. It is easy for the managers to monitor the feature progress and status.

 

But the best advantage is there is no escapeway for the feature owner by blaming others.

“GUI didn’t finish on time”

“QA missed the bug”

“The Requirements are not clear”

“We don’t get enough priorities from infrastructure team”

“No one told me how to handle failures in the database”

Sara is the owner, she has to take care of everything by definition. By empowering the developers, the results are improved and everyone is much happier.  On a future post I’ll describe some of the downsides of this approach.

Tags: ,

4 Responses to “The Feature Owner”

  1. Gregory Appel Says:

    Well, as someone who has been such a “feature owner” for quite some time, in Check Point and in other companies, I can say that not everything you describe is “as good as advertised” – but you probably know it yourself…I waited for the second part of the blog you promised, but it never came so I decided to put in my own two cents…not something I usually do – this is officially my first blog, which might also be the last.

    First, the “feature owner” term is actually an attribute of the infamous Matrix Management approach, where line management and project management duties are decoupled and put on different axis in relation to each other. This is usually done in larger companies (like Check Point), where the number of projects and features (yes, both) is much larger than the amount of products and the number of managerial or any other senior positions is hopelessly smaller than the number of people who need/want/ought to be promoted.

    In such an environment, the matrix introduces a wealth of possibilities for both, achieving the business objectives and keeping the employees happy by introducing a greater variety of roles (now, spanning in different dimensions) and allowing people greater flexibility to move sideways as well as up and down, as in traditional pyramid.

    The theory looks awfully nice on paper but it is extremely hard to implement and control in such a way that it would actually deliver the benefits that it promises.

    In Check Point for example, the “feature owner” term was used to describe the fact that the owner is given responsibility. That’s it. There it stopped. No authority was actually given to the feature owners, no specialized training was provided, and the capacity was ALWAYS estimated incorrectly and allocated sporadically – amongst other reasons, because any decent project spanned across teams and groups and the line manager initiating the project together with the feature owner himself never had the power or ability to estimate its worth correctly or allocate the necessary manpower – simply because they themselves acted from within a “different cell in the grid” and not top-down as in pyramid where you are actually in control of your resources.
    Requirements capturing was the best example where the impotence of the system could be seen – it depended entirely on the feature owner’s own abilities and skill, and no system was set in place to compensate for that. I personally saw a feature owner (it was not me) who had implemented support for a product for an end-of-life product version, and he did it twice (!) because he was incapable of capturing requirements – this is like developing an application for Win 95 and then (seeing the EOL of Win 95 !!!) developing another version for Win 98 with Vista being on the market…and the people supervising him didn’t even blink an eye!
    As for authority, even if the manager that delegated the task actually meant to delegate authority together with responsibility (which happened quite rarely) – it didn’t go through because the corporate culture didn’t support it. And the corporate culture didn’t support it because the company was not organized around the matrix – it was meant as a pyramid company from top to bottom and matrix was implemented “at the discretion of line managers” – but it doesn’t work this way, you see.

    My point is, given an ABLE person (like Sara, for example), the person can only achieve the objective (feature / project) given three things: responsibility, authority and capacity. The laws of nature are such that lacking anyone of these things would render the goal unachievable.
    Not unachievable in principle – unachievable in the specified timeframe, with the specified quality and with the desired psychological effect on people – e.g. satisfaction with what one has achieved, with one’s role, etc.

    The problem is of course universal and can be seen in all companies and with all management structures but in Check Point’s implementation of the matrix, the problem was and remains very profound.

  2. ophirk Says:

    Thanks Gregory, I think you just wrote my second post🙂

    I tend to agree with your writing and I’ll add another criteria for success:

    Willingness – It just so happens that many development team leaders don’t want to be the de-facto “product manager” for a feature.

    They don’t like talking to customers ( or people , for that matter )
    They don’t want to fly 12 times a year
    They are more interested in Kernel Threads and AJAX libraries than user experience
    They want to excel in what they do , and they don’t like doing things they are just “good” at.

    Beyond willingness, I think training is a key for success.
    Some organization rely on “training by example” and others rely on “structured training” . I think only the combination of both works.

    However, when you have people that want to be “feature owners” they tend to produce an excellent product, even without official authority.
    In many other “matrix” like organizations the ownership is divided by so many people that things never get done.

  3. The Proof is in the Pudding- Stating the Obvious III « Evil Fish Says:

    […] The reason I put the responsibility on the coder is simple. The coder is the one who writes the code, the one that understands it and the one that can change it. Why should anyone else be the owner ? […]

  4. The product owner « Silly Features – Uri Gilad's Blog Says:

    […] like “feature ownership” described by my good friend Ophir, ownership implies passion, excitement and a burning […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: