Overloaded operators exist when an operator or operation has different meanings in different contexts. This usually applies to variables and sets, but it can be true for people, too. These people try to do the work of many different roles—and usually fail. If you have an overloaded people operator, analyze the work and try to divide it up.
In software, overloaded operators exist when an operator or operation has different meanings in different contexts. A developer might do this unintentionally when she uses a variable to mean one thing in one context and that same variable has a different meaning in another context.
We even overload conversational operators. A number of years ago, a client told me, “We’re agile. We change all the time. We don’t finish a darn thing.”
In this case, the idea of agile supporting change makes sense. On the other hand, not finishing anything is not how agile supports change. His organization’s approach to agile was all about change, not about collaborative work delivering value.
I’ve seen many other agile approaches that also suffered from teams not finishing anything—or the team finished work, but it wasn’t what people wanted or expected. There can be a number of root causes. Often, I find a primary cause to be that the product owner is an overloaded operator.
When the Product Owner Is Product Everything
I have met many product owners who were the product manager, product owner, and business analyst.
One team had a product owner, Gina, who was also the product manager. Gina spent about half her time at customer sites seeing how people used their product or a competitor’s product. She also spent time at trade shows and conferences to see and hear what people wanted in products like hers.
She only had about a week each month to spend in the office. She had valuable information for many other people, such as the sales and marketing teams, but she had very little time to spend with them. She could not accept stories more often than once every two or three weeks.
Product managers work directly with customers and may bring great ideas back into the organization. The product manager creates the product roadmap to show the team what features are desired in which release.
Product owners work with the team to help them understand stories and build backlogs, write small stories, and make the micro-tradeoffs. The PO also accepts stories and works with the product manager to understand the sequencing of features and why.
Business analysts help the PO decode the requirements and create small stories for the team.
Gina realized she was overloaded. She asked Dan, a business analyst, to work with the team on breaking stories apart. In this case, Gina and Dan became one product owner value team to collaborate on the roadmap and the release strategy.
Gina and Dan working together as a team was successful for a few months. Then, Gina realized the organization could make more revenue if they changed the order of some of the features.
Dan understood how to make stories smaller and how to make stories that made sense to the team. But he did not understand the strategy behind the entire product. He had a difficult time building the roadmap.
Instead, Gina asked Tracey to be the team’s product owner and got another team to work on the same product roadmap.
Gina created the first draft of the product roadmap and asked Tracey and Dan to review it and provide her feedback. When they agreed on the order of features for each release, Tracey and Dan wrote small stories. Dan was available to both teams daily for questions about the stories. Tracey accepted stories for each team and updated the backlog for the next time period.
Gina was still able to travel and build the roadmap. Tracey was able to provide both teams the work they needed. Dan was available for consultation. Eventually, Dan became a product owner as Tracey taught him more about what a PO does.
Gina’s organization now assesses their needs. They always have a product manager to guide the roadmap. They either have a business analyst or PO for the team. If they need another team, they add a PO to each team, or a BA with close ties to a PO. That way, the product manager creates the strategic view, the PO provides the day-to-day tactical view, and the BA helps with story breakdown and explanation.
Recognize When You Have People Who Are Overloaded Operators
I often see people called product owners who are supposed to visit customers, break stories into the smallest chunk of value, accept stories, and create the release roadmap. Those POs are overloaded operators. They change what they do depending on the context.
The problem with overloading the PO is that the PO becomes a bottleneck for the team, preventing the flow of value.
Your team might have more overloaded operators. Here are some ways to spot these people:
- They can’t describe their role without many “ands.” They violate the single responsibility principle, as applied to their jobs.
- They work at different levels. They have strategic and tactical work. If you ask them, they will tell you they feel pulled apart because of all the directions of their work.
- They either overwork or are bottlenecks for the team. They can’t finish the work in a reasonable amount of time because they work at so many levels.
How to Eliminate Overloaded People Operators
If you have overloaded people operators, ask them to take time to work with you and write down all their activities. Ask these questions for each activity and deliverable:
- Should this work be done at all?
- Should you do this work?
- If not you, who could do this work? Do we have someone who is better at this piece of work?
When Gina analyzed her job, she realized she was trying to do the work of several people—and failing. She decided to keep the outward-facing work and build a product owner value team that would work with the teams.
If you are the overloaded operator, don’t try to do all the work. That’s recipe for disaster. Instead, break your current role into its parts and make sure you have someone for each part.
Even though Bob Martin coined the term single responsibility principle for code, it works quite well for people, too. Decouple your many strands of work and make your job cohesive, and you will no longer be an overloaded operator.
