“Who” Creates Risk

Costello: Well then who's on first? Abbott: Yes.
Costello: I mean the fellow's name. Abbott: Who.
Costello: The guy on first. Abbott: Who.
Costello: The first baseman. Abbott: Who.
Costello: The guy playing... Abbott: Who is on first!

Today’s blog is triggered by the entry authored by my friend and colleague, Ben Sommer, reflecting on the laziness of describing architecture with pronouns. In our roles as architects, IT strategists, or just technical leaders guiding successful project implementations we frequently find ourselves defining plans and parceling out tasks.

I learned many years ago on a project with a wise project manager that an action, task, or follow up requires one and only one owner. Assigning in any other manner inserts enough ambiguity to create risk, for two reasons:

  1. The task manager has nobody to hold accountable for the action.
  2. The owners may all assume somebody else on the team has it covered, thus nobody has it covered.

Even assigning a task to two people creates an issue. Who will get the ice cream? Ben and Jerry. Unless Ben thinks Jerry is getting it and Jerry thinks Ben is getting it, then nobody gets the ice cream and even more importantly nobody gets ice cream at the company picnic. Who’s fault is it? Ben’s? Nope. Jerry’s? Nope. It is the fault of the coordinator who assigned the task, that’s who.

Learn to prompt until you have a single name to whom you can assign an action! In case I haven’t already overstated the problem and the solution, here is a helpful sample dialogue to illustrate:

You: Who will own this?
Them: We will.
You: Who is we?
Them: The food services team.
You: Who specifically on the food services team?
Them: Ben and Jerry.
You: It’s fine that you both will be doing it, but who will be the point person?
Them: Ben.
You: Thank you, Ben.
Them: No, thank you. <- Not really. This never happens.

Now everybody enjoys ice cream at the picnic!

In summary: Who creates risk? Vague and/or multiple owners create risk. Which means you create risk if you don’t assign every action to one and only owner owner!

Need any assistance slinging pronouns, tasks, or architectures? Contact us!

Dan Hughes
Dan Hughes is a principal consultant and partner at Systems Flow, Inc., where he leads the technology services practice. He has 20 years of software engineering experience spanning a broad range of technologies and techniques. Startup to enterprise, he has launched, managed, and executed all aspects of both product and enterprise life cycle, delivering complex, enterprise-scale architectures for clients in the public and private sector, in industries ranging from banking and insurance to international development. Dan holds a Bachelor of Science in Computer and Systems Engineering from Rensselaer Polytechnic Institute. For more details, please visit Dan's LinkedIn profile
Dan Hughes

Latest posts by Dan Hughes (see all)


Comments are closed.