Robbin Schuurman — December 3, 2019 
What is a Clerk?
The Clerk is your personal waiter for all your user story serving. Gathering all the wishes, user stories and demands is what The Clerk does. (S)he isn’t focussed on achieving the product vision, nor on crafting clear goals and objectives and the Clerk most certainly never says ‘no’ to stakeholders. There’s nothing wrong with servant leading your customers and stakeholders as a Product Owner, but if your main purpose during the day is getting new ‘orders’ from stakeholders… then you’re missing the point of being a great Product Owner.
A clerk is a white-collar worker who conducts general office tasks, or a worker who performs similar sales-related tasks in a retail environment (a retail clerk). The responsibilities of clerical workers commonly include record keeping, filing, staffing service counters, screening solicitors, and other administrative tasks.
—?Wikipedia, October 2019 —
The Clerk is also referred to as the admin, secretary, waiter, yes man or order taker.
The Product Owner as a Clerk
With the many Product Owners and Product Managers we have trained and coached in their daily practice, we’ve observed the following patterns in Product Owners that we would classify as Clerks:
- The Clerk tends to have (endlessly) long Product Backlogs, which is mainly caused by the fact that (s)he rarely (never) says ‘no’ to the stakeholders. A typical response from a Clerk when someone (a stakeholder) poses an idea, requests a new feature or tells them what to do, they’ll respond: “Sure, let me add that to the Backlog.”
- The Clerk typically has an internal focus. Internal stakeholders typically tell them what to do and what to build. Clerks typically don’t interact with external stakeholders, rarely with external users and (almost) never with real, paying customers who actually buy the product. Clerks are also rarely talking (or allowed to talk) to external influencers or governance stakeholders, such as legal authorities and/or regulators.
- Other associated behaviors with the Clerk type of Product Owner are: acting as a go-between (carrier pigeon) between the Development Team and the stakeholders, not taking any decisions eventually being a demotivator for everyone, no ability to say no, trying to please everybody, being a micromanager, distributing tasks amongst team-members, managing via spreadsheets, being a people utilizer, reducing effort estimates by the Development Team, maximizing output and being a team coordinator.
The results/effects of acting like a Clerk
Obviously, not all (Product Owner) Clerks are the same, and not all the results/effects may be visible in your context. That being said though, what we typically observe when Product Owners act like Clerks is:
- The Product Backlog may contain hundreds of items, that were added to it, without talking about the why, the value, the opportunities in the market, etc. It’s just an unmanageable, endless list of user stories;
- You aren’t building a product based on a vision, you’re just delivering what everybody wants from their perspective. No great product has ever been built by a committee of stakeholders;
- Focus on short term results;
- Little to none focus on long term outcomes (TCO, ROI, P&L, etc);
- You are slowing the Scrum Team down;
- The Scrum Team isn’t learning and obtaining more business, domain, customer and product knowledge. This prevents them from making better, faster and more informed decisions and herewith increase self-organization;
- The Development Team isn’t learning to be self-organizing their own work, they won’t be taking ownership (over planning, results, quality, etc) and controlling everything will cost you a lot more work and time yourself (which you can’t spend on more important things);
What you can do to move away from this stance
As mentioned earlier in this post, servant leadership is important for every organization, however, it is about servant leadership, not about being a servant (or clerk, as we like to call them). So, what can you do to move away from the misunderstood Clerk stance?
Well, one thing you could do is to stop being the carrier pigeon between the stakeholders and the Development Team. Instead, have them talk to each other! Let stakeholders explain the requirements to the Development Team directly. And let the Development Team interact, ask for feedback and test stuff directly with stakeholders, customers and users.
Also, stop saying ‘yes’ to everything. Create some kind of a plan for your product or service. Define your own vision and goals. And start explaining them to people. Ask for their feedback and input. See if you can come to a shared understanding perhaps? And, oh and this is important, try to focus your vision, goals and feedback to the outside world! Make it all about customers and users. So get out of the safe environment of your office, and start talking to your real, paying customers!
Business & Finance Articles on Business 2 Community
(20)
