Specification and Delegation

In any handoff of work, there are two ways for decisions to be transmitted: specification and delegation.

When specifying, the party requesting the work makes a decision and communicates that decision. When delegating, the requesting party conveys intent and authorizes the work-provider to make the necessary decisions on their behalf.

If you aren't getting the results you want out of communicating requests for work - whether it's enablers coming from architects or requirements coming from Product - you have two ways to make it better.

One option is to improve how you delegate. Make an attempt to better-convey intent, give a broad charter to realize that intent, and educate the people doing the work on how to evaluate whether or not they are moving closer to or further from the goal.

Another option is to improve how you specify. Make an attempt to eliminate the potential for misunderstandings in lines of communication, channels that cause information to change hands many times. Install feedback loops to ensure that specifications are met.

While you don't have to choose between getting good at one and getting good at another, do you have to choose one and only one path for any given decision at any given point of time.

That is, you can hand off the specification of a decision you've made or you can delegate a decision to someone else but you cannot delegate a decision to be made exactly as you would have made it.

The Telephone Game

There's a reason they make us play the telephone game in kindergarten. I'd like to think it's more than just that it's an interesting effect you can demonstrate in a small classroom.

I think that, on some level, it's an attempt to demonstrate one of the most fundamental problems faced by mankind, today. Maybe not consciously by the teachers, but I suspect somewhere in its origins lies a motivation along those lines.

For those of you unfamiliar with the telephone game, the classic version goes like this:

1. The teacher arranges the children in the circle, with herself as part of the circle.
2. The teacher whispers something to one of the children next to her. It's usually something simple and factual, like "There's a bow in Jennifer's hair, today."
3. Each student whispers what they heard from the student next to them to the other adjacent student.
4. The message travels around the circle, changing hands once for each student until it reaches the teacher.
5. The teacher compares what the final message was with the initial version for the whole class.

Invariably, the message is mangled. Often, it is distorted beyond recognition. If you play the same game without whispering, the message keeps its original form, more or less.

The point of the game is to show that communicating via numerous intermediaries introduces error into the flow of information.

It rings true in business as well. Without a means of combating communication-error, you can be more or less certain that someone won't get what they want if they are asking someone to ask someone to ask someone for it.

It's Okay to Talk with Product about the Outcome of Engineering

The hard-cast roles I often see in a newly-turned-agile organization tend to drive some unproductive ideas about how people should communicate. Specifically, regarding what not to communicate.

Sure, you don't want to bore a freshly-minted product owner with technical details but the goal is nothing to do with boredom. Instead, it's about signal-to-noise ratio.

Technical details are the purview of an engineer but the outcomes of technical choices have ramifications that are unquestionably business-facing.

Consider the following (made-up) report from an engineer to a product owner.

I did it the right way. I noticed there was a Strategy pattern indicated by the problem. So I took care to properly-encapsulate the variation and extract the common part away. I made sure I wrote a full suite of tests because I'm a test-driven developer.

Here's an alternative way of saying the same thing.

I did it the right way. There are currently several options and I made sure adding or subtracting choices won't have an undue cost, later. I also made sure that nobody will be able to break this functionality without us finding out immediately and fixing it before it has a chance to become a real problem.

Imagine you are a product owner with no technical knowledge. Which of those sounds better to you?

The answer should be "the latter".

For one thing, there's nothing technical in it. For another, the first report sounds like it's about a developer's sense of pride. The latter is a clear delineation of the real costs and benefits involved in doing things the right way. It's information that is useful to the product owner.

That's the key. It's okay to talk about technical matters with nontechnical people. If you have the impulse to do so, there's probably a good reason. There's something you are trying to communicate that is actionable or meaningful to them.

Just make sure the message is focused on the part that will be interesting to its recipient instead of expressed in the way you find most appealing or convenient.