You Have Control

July 2, 2017



I'm sure this issue is not specific to the software industry, but that's where I've seen it:

An email goes out to a number of people, some directly, some via cc. It states an action, something like "We must correct this problem for customer X!".

There may be a number of replies, usually of the form of "yes, for sure, we should to that at once"... Perhaps along the lines of "We could do Z - Z will fix it".

Then, the silence.

There is agreement that the problem exists, and discussion on things that might be done to correct it, but it's all NATO (No Action - Talk Only).

The bit that was missed, in my view, is the definition of control. It was not clear who had control of the issue, and therefore, who should take the leading action.

I like to compare it to commercial airline pilots (I know a few personally). One of the basic tenets of their job is that there is always a pilot-in-command. He isn't necessarily the guy in the left seat, or the most senior, but it is never unclear who it is.

When the pilots sit down to get a flight underway, they choose who will start. At any point, the pilot-in-command has one job, and one job only: fly the plane.

There have been a number of tragic accidents (if the word accident is applicable), resulting in loss of life, when this rule is not followed.


For pilots, there is a clear procedure if the pilot-in-command wants or needs to be relieved of his primary responsibility. He says something to the effect of "You have control" to the other pilot. This is actually a question, in a sense, not a statement.

The other pilot then must reply "I have control" once he's ready to accept this responsibility, and once he has his feet on the pedals, his hands on the yoke, and his attention on the job.

Then, and only then, the pilot-in-command becomes someone else, and the original person can put his priority and attention somewhere else.

I think this applies precisely in distributed communications (between people) as well.

If the originator of something expects another person to take over the issue, they should tell them that.

Bob: "Joe, we have a problem with customer X. Can you please take on responsibility for resolving it?"

Joe then needs to come back with something to the effect of "Yes, for sure, I've got it!" to confirm that transfer.

There is no ambiguity here: Until (and unless) Joe comes back with a clear acceptance, this is still Bob's problem.

If Joe comes back with questions, instead of a confirmation, it continues to be Bob's problem until Joe has everything he needs.

Bob doesn't just let go of the wheel, stand up, and head to the bathroom, calling over his shoulder "Bob, take over!". This is how projects end up in pieces at the bottom of the ocean;.