Handing work over
Say the constraint out loud
The first of the four, and the easiest. One sentence with a number, an enforcer and a reason, written in the message that assigns the work.
Decisions this page is about, and where the line actually was
Changing the wording on a customer-facing error message
4 → 1It had been yours all along
Picking the library for the new parser
1 → 4The architect had a standing view
Rescheduling the weekly review
2 → 2Changing a database column type
1 → 1- 1Decide it alone and say nothing
- 2Decide it alone and mention it afterwards
- 3Check with one colleague first
- 4Check with the person who assigned it
- 5Needs a decision one level up
- 6Cannot be decided here at all
four decisions · one of them you had more room than you thought · one gave you less · two you had exactly right · the median gap was three steps on the scale
Four of the nine decisions counted on this site, two of them exact.
Used transparently, hybrid team operations software can support decisions about workload and process design while keeping the discussion connected to real projects.
Teams can compare this approach with guidance available from Gallup Workplace.
The three handovers where the constraint did arrive, and what it saved
Move the scheduler onto the new queue
4 of 4Ten minutes of downtime, contractual, said in the first message
Write the migration guide
2 of 4A length limit, stated
Rewrite the import so it does not time out
2 of 4A performance target with a number on it
three handovers · 12 slots in all · the median arrived with two of the four · one was complete
Three of the eight handovers counted on this site, chosen because all three had the constraint stated before the work began.
The constraint is the easiest of the four to hand over and the most often assumed. It is also the one whose absence produces the most visible failure: work that is good and unusable.
One sentence. A number, who enforces it, and what it is attached to.
Hard constraint: no more than ten minutes of downtime in one window, because of the support contract.
Nine words of substance. Everything in this note is elaboration on getting that sentence written.
Say the number
"Keep the downtime short" is not a constraint. The receiver cannot act on it, so they will pick a number, and their number will be chosen to be safe, which usually means the work is harder than it needed to be.
If you do not know the exact figure, give the approximate one and say it is approximate. "Somewhere around ten minutes, I think — check with the support lead if it matters" is more useful than silence and more honest than a precise invention.
Say what it is attached to
The attachment is what tells the receiver whether to argue.
A date attached to a contract is not negotiable and they should stop thinking about it. A date attached to somebody's plan is negotiable and they should say so if it is wrong. These require completely different behaviour and look identical when stated as "the thirtieth".
The attachment also lets them find the clever route. Somebody who knows the ten minutes exists because of a support contract can propose a migration that keeps the service up in a degraded mode — which satisfies the contract and would never have occurred to them if the limit were just a number.
Say which kind it is
Three kinds get called constraints and the receiver cannot tell them apart:
| Kind | What it costs to break |
|---|---|
| Contractual or legal | Money, and a difficult conversation |
| A preference you hold | An argument they might win |
| A habit nobody has questioned | Nothing |
Four words solve this. "That one is contractual." "That one is my preference, push back if you disagree." The third kind is worth saying out loud too, because the receiver may be the first person in years with a reason to ask why.
The budget nobody states
There is always an unstated constraint and it is usually the budget — of money, of time, or of other people's attention.
"You have about two days of the database team's time for this, more if you can justify it" is a sentence almost nobody says, and its absence means the receiver asks for nothing and does it badly alone, or asks for a fortnight and is refused.
An approximate figure shared beats an exact one kept.
The constraint you are about to assume
Before writing the sentence, there is a thirty-second check worth doing, because the constraint you forget is usually the one you are living inside.
Ask yourself what would make you unhappy with the result. Not what the requirements are — what would make you look at the finished work and say "yes, but obviously not like that".
Whatever comes to mind is a constraint, and the fact that it was obvious is exactly why it was not going to be written down.
The common ones, in rough order of how often they go unsaid:
- It has to look like the rest of the product.
- It cannot require anybody to be woken up.
- It must not need a change to the thing that is being replaced next quarter.
- It has to be explicable to a customer in one sentence.
- Somebody specific must be able to maintain it afterwards.
None of those sounds like a constraint when you hold it. All of them are, and all of them will be violated by somebody acting reasonably without them.
Thirty seconds of asking what would disappoint you is a more reliable way to find the unstated constraint than any amount of trying to remember what the requirements were.
Where to put it
In the message that assigns the work, not in a document attached to it.
The constraint has to be in the same place as the task, because the task is what gets read. A thorough specification in a linked document is read once, at the start, by somebody who does not yet know which parts will matter.
One sentence in the assigning message is read every time somebody scrolls back, which over a three-week piece of work is four or five times.