First Among Equals
Last week, in One Product Owner Is Not Enough post, I shared some thoughts on when a team might consider complementing one product owner with several feature owners and offered an actionable tip which might help identify bottlenecks in communication (visualize!). Today, I’d like to elaborate on feature teams and on their guiding principles/values in particular, should some of you decide to give this setup a try.
The very first thing to do would be to pick the feature owners. These people would’ve ideally spent several years working in the organization, where they would’ve followed in the evolution of the product/-s, building up their awareness of the priorities and business objectives. Of course, the priorities and objectives can be shared and discussed in a conversation with a relatively new person, but someone with the intrinsic knowledge would fit much better. Someone who’s been in the product context for quite a while, as a dev, or as a QA, or as a UX designer, would be more capable of balancing the strategic priorities projected on their feature. A feature owner would eventually become an informal leader, based on the “first among equals” principle (or primus inter pares, as in Latin), where this person has no formal “order-forbid” rights, but is viewed by the other peers as a competent authority, as someone who champions the team. The feature owner would also paste this feel of awareness on the rest of the team, thus fostering engagement.
Next, the #1 goal of a feature team would be to release their feature as fast and as best as they can — here, we step onto a shaky terrain of the recent MVP-related controversies, but I’d rather not get into this discourse for now — and then re-iterate based on the feedback from customers and stakeholders, of course. Anyone in the team has to be aware of that goal, and keep it in mind. They have to learn to think in the context of the whole feature, not only within their one user story, or task. In other words, go beyond their primary knowledge domain (sorry, curiosity can’t wait!). The notorious UX-dev clashes, where developers say something like “it’s very hard to do this UX in terms of development”, have no right for living. Yes, sometimes code-related things make it hard to implement a nicer UX solution. But this is not to be left hanging in the air. Developers and designers in a feature team are supposed to sit down and discuss best viable alternatives, considering all the challenges, pros and cons from both the sides. The faster things are discussed, the higher the chance that a good approach is found faster, and this would bring the team closer to their ultimate #1 goal. That’s what integrity as a feature team value is about.
In a feature team, there’s no subordinate relationship. A feature owner is not supposed to assign work as such. Neither it is supposed to work as in: “I have no tasks left, tell me what to do?” A feature team is even more about a collective ownership of a feature, so if a team sees some challenges, they need to talk, discuss and decide by themselves. There’s no micro-management either. If there’s a bottleneck at the UX stage, or at the development stage, or at the QA stage — it’s up to the team to come to a solution. That’s what autonomy as a feature team value is about.
A few more words about engagement. This is something that has to be in the organizational DNA for feature teams to exist. And, engagement can only be rooted in the culture of an organization. The genuine interest, and a broad outlook which goes beyond “this is my task, and that’s all I know”. Such awareness of shared goals and priorities in product development is a must, and this would be a job of strategic management to keep people on the same page with the objectives, updates, and changes (e.g. share feedback from customers, communicate changes in priorities, all the while making sure that teams do follow in the org’s big picture flow).
Finally, the “first among equals” principle might be better known to some of you as “organizational flatness”. In brief, this means no formal authority. But I would advise to use extra caution with anything flat, because, as I’ve observed, an absolute organizational flatness is not only futile but perilous, as a goal. It can be reached to some extent, but, in the end, everything hinges on the culture of genuine engagement. And, let me re-iterate, that “flatness” as such would rather be about the “first among equals” setup. There’s no way for a group to go without a leader, be it a formal or an informal one. “Right-sizing” or “right-layering” look better as terms for what is now generally known as “flatness” to me… and I hope to write on that some other time :)
Related:
One Product Owner Is Not Enough
(fr)Agile Teams: Handle with Care
It’s Teamwork. Rescue Me, Quotation.
Beware Flat Hierarchy: A Personal Story
Further reading:
The Leader Who Is First Among Equals (fun fact: the “primus inter pares” insight re: feature teams has actually “descended” on me from some higher planes independently, with no connection to the referenced article, a few years before, in fact. Another reason to celebrate and validate myself :)
What Many Fail to Remember When Flattening an Organization
The MVP is broken: It’s time to restore the minimum viable product
This article has been re-written from an earlier story.
