A design principle is a decision rule, agreed before the work starts, that settles a class of future trade-offs and states what the choice costs. This article covers how to write one, who sets it, and how a gate uses it.
A design principle is a decision rule, agreed before the work starts, that settles a class of future trade-offs in advance. It names a tension the program will meet more than once, says which way the call goes when the tension arrives, and states what that choice costs, so that the people who lose out on the day know in advance what they agreed to give up. Written well, one principle replaces four arguments. Each of them would otherwise happen at 4pm, in a room where somebody wants an answer today.
Most organisations file design principles with the design team, somewhere between the style guide and the architecture review. Readers there already agree with them. The principles settle very little. Placed in the charter, beside the business problem, the target outcome, and the scope boundaries, and approved by the sponsor at the same moment as the money, they change status. They become an instrument for the people funding the work and stop being guidance for the people building it.
“We value quality” fails as a principle because every side of every argument can cite it. The team asking for six more weeks of hardening cites quality, and so does the person insisting the release goes out on the date, because a product that nobody can use in time is also a product of poor quality. A rule that both parties can quote decides nothing, because it favours whichever side speaks last.
The test is subtraction. A working principle names what the organisation gives up. Take this one: “We will buy before we build, and accept a worse fit to our process to avoid carrying a codebase we have to maintain for the next decade.” It tells the committee what happens when the vendor demo covers 80% of the requirement and somebody proposes writing the rest. It is uncomfortable to sign. That discomfort shows the sentence is doing work.
A second filter is stricter. A principle earns its place when a reasonable person with the same facts and a different remit would plausibly choose the opposite. Legal obligations fail this filter, because nobody argues the other side of privacy law. Keep those constraints on a separate list. The principles list holds only the genuine forks, where the program has picked a side early.
Buy before build. “We will buy before we build, and accept a worse fit to our process to avoid a long-term maintenance burden.” The cost is real. Some teams will change how they work to suit a product, and a few good local practices will be lost. In return the principle settles the recurring argument about the last 20% of functionality, which appears in every vendor selection and can always be won on technical grounds.
The date holds and the scope moves. “Where the date and the scope conflict, the date holds. We would rather go live in October with less than in February with everything.” That means a thinner first release and a second tranche of funding to finish the job. It also settles the final six weeks of delivery. Without it, the same conversation would recur every week, with a different subset of the committee in the room each time.
One process across all sites. “We will run one configured process across all sites and accept that some sites lose ways of working that suit them better.” The cost falls on the two or three best-performing teams, who will be slower for a while and will say so. The principle settles the queue of exception requests during rollout, each reasonable alone and together damaging to the business case.
A sponsor can say each of these aloud in a meeting without checking a document. That is about the right length for a principle.
A change request arrives in month three with a budget impact and a schedule impact. The committee has forty minutes, and half the room read the pack that morning. Without a principle, the call goes to the most senior person present, who works from whatever they happen to know that day, and who may have read a different half of the pack than everyone else. The decision may be right. Nobody can repeat it, so the same request in month nine gets a different answer from a slightly different room.
With a principle in the charter, the discussion narrows to a first question: does this request fall under the rule? If it does, the answer is already written and the meeting spends four of its forty minutes on it. If someone wants the opposite of what the rule says, they argue that the principle itself was wrong. That is a better use of a steering committee's time, and it produces a decision worth recording with its reasoning.
Reconsideration is allowed. A sponsor who overturns a principle deliberately, with the trade-off restated and the consequences priced, has used the charter well. The failure to prevent is the quiet version, where the principle is neither followed nor withdrawn.
The sponsor and the project manager set them together, because each working alone drifts in a predictable direction. A delivery team writing its own principles will lean, in good faith, toward the choices that make delivery tractable, such as build over buy, because building is more interesting to the engineers and easier to defend on technical grounds when a committee pushes back. A sponsor writing alone produces platitudes, because naming values without knowing where the trade-off bites yields nothing else.
The project manager knows which decisions will come under pressure and roughly when. The sponsor lives with the worse outcome on whichever dimension the principle concedes. Only the sponsor has the standing to concede it in advance. A principle spends someone's authority ahead of time, so the person who owns that authority has to spend it.
Timing matters as much as authorship. The business case is the right moment, because funding has not yet been released, no team has been hired, and nobody's reputation is attached to a particular answer. At that point the trade-off is still hypothetical, so nobody has a reason to shade it.
Three to five is the workable range, and there are two reasons for that limit. Nobody recalls fifteen rules in a meeting. A principle that has to be looked up rarely gets looked up. The second reason weighs more. With fifteen principles, every request finds one it can cite and most requests find two that point in opposite directions, so the committee is back to doing what the most senior person prefers, with a document on the table for cover.
Conflicts between principles set the limit. With four principles the sponsor can see the conflicts and resolve them on the page, before anyone needs the answer. With fifteen, the conflicts surface live, in the room, at the moment the principles were supposed to help.
A principle that nobody has cited in six months is either wrong or was never load-bearing. Both facts are worth knowing. At each gate, ask which principles have been used since the last gate and on what decisions. Principles that never come up describe a tension the program does not have, and they can go. The dangerous case is a principle that everyone has quietly stopped following, because once one rule is understood to be optional the others become negotiable, and the charter returns to being a document in a folder.
Retiring a principle follows the same path as any other governance decision. It needs an authority, a date, a reason, and a record. Decisions made under time pressure, with a vendor waiting and a date in the room, are weaker even when they turn out right, because nobody had the calm or the information to make them well. The same call made months earlier, while the trade-off was hypothetical, is usually better. Most of what governance does is move decisions earlier, to the point where the trade-off can be judged calmly and the decision can be recorded with its reasoning.
Tollgate keeps design principles in the business case, as a field in the versioned investment thesis. That field sits beside the business problem, the target outcome, the scope bounds, and the named decision authority, and the sponsor approves it when the money is committed. Change requests, gate decisions, and the append-only decision log live in the same record, so when someone cites or overturns a principle, the reasoning is written where the next person will look. Tollgate runs on Atlassian infrastructure with no Softwired server in the path, so the data stays in your own Atlassian tenancy.
Tollgate keeps the business case, the gate decisions and the payoff in one record, next to the delivery they pay for.