They Understood Me

A management AntiPattern.

It happens when a manager, leader or senior developers briefly explains what he/she wants to junior developers without a specification. The junior developers implement:

what they understood
what they are able to do with it
in the way they imagine is best, usually AntiPatterns or WorstPractices

Solution: specify it correctly

-- GeraldoXexeo

I've learned the hard way about this.

After someone has performed a task at my behest, I have to be careful about how responsible I hold them for the quality of the result. If I complain that it has deviated from my instructions, then I am liable to confound them.

So I always try to make sure that before I have someone perform a task, I consider the following:

Am I reasonably sure that the performer understands what I want?
Is the performer reasonably sure, too?
Should I make time allowances for a review of the results before they are finalized?
Should I make time allowances for some rework subsequent to the review?
How much time will I have to do the review?
How important is the quality of the work to me?

Could not this help to improve decision making of junior developers, their responsibility? If there is good communication don't you think this will turn out as strength than weakness? e.g. less paper stuff, flexible implementation, implementation in the best way developer can.

The developer can't develop code that meets the customer's needs if s/he doesn't know what those needs are. That's the purpose of a specification (by "specification" I don't necessarily mean a pile of dead wood; it could be a UserStory on a card), and it's the job of the ProjectManager / ProductManager / OnsiteCustomer (whoever represents the customer's wishes within the company) to get that specification to the developer.

Meanwhile, on the other hand, the developer is not completely blameless in this situation, if s/he didn't fully understand what needed to be done, s/he should have asked! -- MikeSmith

One of the biggest problem is not that the developer doesn't understand what needs to be done, and didn't ask, but that the developer understood something different from the manager and implemented it.

Isn't this AntiPattern also applicable to any link of a communication chain? Why junior developers only? -- Guest

I agree -- this happens (all too often) with all kinds of "communication".

EditHint: refactor this to a generic "manager / leader" and "developer" (is that OK ?)

Occasionally the same sorts of things happen in reverse: subordinates imagining that they've told their managers what sorts of office environment / furniture / tools / software they want, but he gives them something wildly inappropriate.

This isn't so bad when the manager accepts what the junior has done, otherwise it becomes what I call TrialAndErrorManagement?

Solution: specify it correctly

I think this isn't a complete solution -- we need more than that to solve this problem. It's not possible to completely specify everything up-front (see BigDesignUpFront).

Wow. This really, really annoys me when supposedly professional people make statements like that. It most certainly is possible to specify everything that has to be done by the product up front -- this is the CriticalSuccessFactor. Whether this or that feature is in the final product, or whether it does this or that many foos per bar, or whatever other fudge factor matters that come up are inconsequential to hitting the critical success mark. Specifying the product correctly involves figuring out which characteristics and behaviors are critical to the product and which aren't. If you can do that then you can, in fact, correctly specify the product. If you can't do that then you don't have a product in the first place.

Wow??? You seem to have been really lucky, working on stand-alone systems where everything that the product has to do is known up-front. It really annoys me when lucky people with this limited experience then batter everybody with this limited viewpoint. In many MANY cases, the thing you are building cannot be specified up front simply because the otehr parts it interfaces with are not yet purchased or built, or may be in different phases of readiness. You can write a story saying 'foo must call out to bar to get widgets' but you cannot specify it fully yet if the calling mechanism, protocol, adapter etc to sperak to bar has not been built or even scoped yet. I hate projects where a bunch of designers think they've completed their work simply because they've produced a load of vacuous user stories at a high level, a bit like designing a Word Processor app by writing "must be able to write a novel on it" as a requirement.

ThereIsNoFinalProduct?

See: TaskCompleteDefinition, PleaseUnderstandMe

CategoryRequirements, CategoryAntiPattern, CategoryManagementAntiPattern