Responsibility Confusion and Lean/Agile Solutions
2 May 2017
As a futurist, I look for ways to fast-forward to a future when teams can successfully transport more value across the "business/technology gap" than they currently do. As it stands, immense value often doesn't make it over to the other side. There are many reasons why that happens. "Responsibility confusion" plays a part. I expect more of it in the future, not less.
What responsibility confusion looks like
What does responsibility confusion look like? My short answer is, you experience it when it's not clear which role is responsible for the important things (let the trivial things go). For example, who is in charge of making sure that an incoming client request is crystal clear and thoroughly understood? A lack of clarity about incoming requests can cause havoc all along the value chain, across client-facing, technical, and operational teams.
People in charge of strategy are more likely to get this. I overheard a senior executive musing openly about who was ultimately responsible for moving the needle on financial performance: the client organization or the vendor organization? If a team gets the "Who is responsible?" question wrong, the strategy layer is going to be off the mark. When it drives strategy, the question is big and important, so it tends to get attention.
I worry more about the roles in charge of tactics and operations. The "Who is responsible for . . . ?" questions are still very important there too, but it's easy to see them as not even interesting at all. Nobody is flying into town to discuss the matter in a fully-catered day of meetings attended by the elites of the company. There might be only a single person thinking about it randomly on their lunch break.
Managing responsibility confusion
Stepping back, responsibility confusion doesn't "look" like anything. It's invisible. That's part of the problem. It's up to knowledge workers to notice symptoms that something's amiss, call attention to it, and start actively managing it. It's similar to "invisible queues." Don Reinertsen, author of The Principles of Product Development Flow: Second Generation Lean Product Development, argues that it's invisible queues of work that will bite you. They go unmeasured and mismanaged, chewing up time and resources that aren't accounted for. I'd say that undefined or weakly defined responsibilities operate the same way.
Why are we headed for more responsibility confusion, not less? I think it's a natural result of strengthening that bridge that spans the business/technology gap. Adding to the gap analogy, teams form a "bridge of talent" across the gap. Visually, I think of this bridge as a set of talent circles that have to be linked together in several places to be strong. Often, there are weak points and gaps. When that happens, I'm in favor of cultivating people who can step out of their usual, comfortable roles and do some stretching to cover those weak points and gaps, within reason. I'm in favor of more hybrid, more nuanced people. Well, that sounds great, but it's also a perfect recipe for yet more responsibility confusion than before. I see that as an issue that people will have to get good at resolving, too. I don't see any way around it.
What can be done about it? Reinertsen's solution pattern works here, too. That is, notice the thing that went unnoticed. Make visible the thing that couldn't be seen. Then, start actively managing the thing that wasn't being actively managed.
I'll explain what I don't mean. I don't mean for teams to engage in turf battles over responsibilities, or to become overly rigid about who does what. Rather, I suggest that those discussions take place so that orphaned or misplaced responsibilities can be better managed. It may be that a responsibility will need to be handled by a person or team that ideally should not shoulder the responsibility, but, under imperfect circumstances, it will do for the time being. The opportunity cost of doing that should be well understood and, in some way, measured. Then the imperfect circumstances can be looked at and perhaps be adjusted at some point.
In one case, the company ran product management as a support organization. Support would be given to a newer division, which came in as an acquisition, but that support wouldn't be fully functional for some time. Meanwhile, the division would need to either manage those responsibilities or let those responsibilities go unmanaged. If significant effort must be diverted there, taking away from other output, affected teams may be viewed as underperforming or mismanaged. Strategies might be in place that do not account for the orphaned responsibilities. Those strategies could be optimized if those responsibilities were taken into account.
Reducing the cost of political capital
I anticipate the argument that political capital is a finite resource, and discussions about responsibilities can use up this resource. But perhaps some ground rules can be established. Raising issues about responsibilities should not cost a person or team their political capital. Raising these issues should be part of the culture, accepted, and expected. If that can't be arranged, I consider that an avoidable malaise — a leadership problem.
Tactically, if the team uses visualizers for tasks or ideas, like a digital ticketing system, orphaned responsibilities can go in as an idea, or as its own entity type, to add visibility and spark discussion.
I'll echo the Lean/Agile literature that suggests writing up "classes of service" and "service-level agreements." These artifacts should be crafted to capture key responsibilities and to avoid or actively manage orphaned responsibilities.
What's at stake
I'll end with some comments about what's at stake and why this matters. It's outcomes that are at stake. It's value that matters. Far too much of life's work gets spent on value chains and work flows to let so much avoidable value slip away or for outcomes to be subject to so much avoidable chaos. That's why responsibilities need to be far better managed than they are today. The Lean/Agile community needs to offer leadership.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4 (3 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.