What autonomy needs
What a constraint actually is
Not a preference and not a deadline somebody would like. A constraint is a fact about the world that the work must fit, and it has an owner and a reason.
Decisions this page is about, and where the line actually was
Picking the library for the new parser
1 → 4The architect had a standing view
Dropping a requirement nobody had asked about in six weeks
2 → 5A commitment made before you joined
Changing a database column type
1 → 1Small, reversible, tested once before
- 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
three decisions · not one of them gave you more room than you thought · two gave you less · one you had exactly right · the median gap was three steps on the scale
Three of the nine decisions counted on this site.
Before adding another approval step, it helps to take a closer look at the service and check whether unclear ownership or missing context is the real source of delay.
For an independent perspective on management and working practice, consult American Management Association.
"Do it however you want, just keep it simple" is not a constraint. It is a preference, and the person receiving it cannot tell how much it costs to violate, which is the only thing they need to know.
A constraint is a fact that the work must fit, which somebody will enforce, for a reason that exists outside the work. It has three parts, and a statement missing any of them will be treated as advice.
The three parts
The limit itself, stated in units. Not "keep the downtime short" — "no more than ten minutes of downtime, in a single window". Not "this is urgent" — "the thirtieth, because that is when the contract renews".
Who enforces it. A limit with no enforcer gets renegotiated by whoever is most inconvenienced by it, usually two days before the deadline, usually successfully, and usually after somebody has already built around it.
The reason. This is the part people skip, on the grounds that the limit is what matters. The reason is what lets the receiver tell you that your constraint is wrong, which happens more often than anybody expects, and it is what lets them find the clever route that satisfies it a different way.
Say all three and you have given somebody something to work with. Say the first alone and you have given them a rule to resent.
Hard, soft and invented
Three kinds get called constraints and only one of them is:
| Kind | Example | What it costs to break |
|---|---|---|
| Hard | Ten minutes of downtime, contractual | Money, and a conversation with a customer |
| Soft | We would rather not add a dependency | An argument, which you might win |
| Invented | We have always done it this way | Nothing, once somebody asks why |
The person receiving the work cannot tell these apart from the outside, and the common failure is that they treat all three as hard. The invented ones are the expensive ones, because they are obeyed indefinitely by people who assume somebody must have had a reason.
Saying which kind it is takes four words. "That one is contractual." "That one is a preference, argue if you like."
The constraint nobody states
There is always one, and it is almost always the budget — of money, of time, or of other people's attention.
Nobody says "you have about two days of the database team's time for this" because it is not written anywhere and feels unfixed. So the person doing the work either asks for nothing, and does it badly alone, or asks for a fortnight and is refused, and both outcomes get read as a judgement about them.
An approximate figure said out loud is worth more than an exact one nobody shares. "Roughly two days of their time, more if you can justify it" is actionable. Silence is not.
How to find one that was not given
If you are on the receiving end and the constraint did not arrive, there are three places it usually is.
The last thing that went wrong in this area. Constraints are mostly scar tissue; the ten-minute downtime limit exists because of an eighty-minute outage somebody remembers.
The contract or the commitment. If there is a date, something is attached to it. Asking what is attached to the date is not a challenge; it is the question that tells you whether the date is real.
The person who will be annoyed. Who gets paged, who gets the complaint, who has to explain it. Their situation is the constraint.
When the constraint is wrong
Stating the reason has a consequence people do not anticipate: it lets the receiver tell you the constraint is mistaken, and sometimes it is.
This happens more often than anybody expects, for three ordinary reasons.
The limit was set against an older system and nobody revisited it. Ten minutes of downtime was a real figure when the failover took eight; after the rebuild it takes forty seconds, and the limit has outlived the thing it protected.
The limit was a proxy for something else. "No new dependencies" usually means "we got badly burned by an unmaintained library once", which is a different rule and admits exceptions the blanket version does not.
The limit was invented by somebody who no longer works here and has been obeyed ever since by people who assumed it had a reason.
A constraint stated with its reason can be checked against reality. A constraint stated as a bare rule cannot, so it persists, and the cost of persisting is paid in every piece of work that has to route around it.
Which gives whoever receives the work a legitimate move that is worth using sparingly and without apology: ask what the limit is protecting, and if the thing it protects has changed, say so.
The test
A constraint has been properly handed over when the receiver can answer one question: what happens if this is broken, and to whom?
If the answer is "I do not know, but I assume it would be bad", it was not handed over. It was mentioned, which is different, and the work will be shaped by somebody's guess about how bad.