A design principle is a decision rule, agreed before the work starts, that settles a class of future trade-offs in advance and states what that choice costs.
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 hit more than once, says which way the call goes when it does, and states what that choice costs. Written well, one principle replaces four arguments — each of them otherwise held 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. That is where they do the least good, because the people reading them already agree. Put them in the charter instead, next to the business problem, the target outcome and the scope boundaries, approved by the sponsor at the same moment as the money, and they change status. They stop being guidance for the people building the thing and start being an instrument for the people funding it.
"We value quality" is not a principle. Every side of every argument can cite it. The team asking for six more weeks of hardening cites quality; so does the person insisting the release goes out on the date, because a product nobody can use is not quality either. A rule both parties can quote is decoration.
The test is subtraction. A real principle names what you are giving up. "We will buy before we build, and accept a worse fit to our process rather than carry a codebase we have to maintain for the next decade" tells you what happens when the vendor demo covers 80 per cent of the requirement and somebody proposes writing the rest. The sentence is uncomfortable to sign, which is the signal that it is doing work.
There is a second filter, and it is stricter. A principle earns its place only if a reasonable person with the same facts and a different remit would plausibly choose the opposite. Legal obligations fail this test — nobody argues the other side of privacy law, so writing it down settles nothing that was in doubt. Write your constraints down by all means, but do not confuse them with the handful of genuine forks where you have 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." What it costs is real. Some teams will change how they work to suit a product, and a few genuinely good local practices will be lost. What it settles is the recurring argument about the last 20 per cent of functionality, which arrives in every vendor selection and is always technically winnable.
The date holds, 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." What it costs is a thinner first release and a second tranche of funding to finish the job. What it settles is the final six weeks of delivery, when the same conversation would otherwise be had weekly with a different subset of the committee each time.
One process, no local variants. "We will run one configured process across all sites and accept that some sites lose ways of working that suit them better." What it costs is the productivity of the two or three best-performing teams, who will be slower for a while and will say so loudly. What it settles is the queue of exception requests during rollout, each individually reasonable and collectively fatal to the business case.
Each of those is a sentence a sponsor can say out loud in a meeting without checking a document. That is the working length.
A change request lands in month three, carrying a budget impact and a schedule impact. The committee has forty minutes and half the room read the pack that morning. Without a principle, decisions get made based on the opinion of the most senior person, based on the limited information they have available on the day. The decision may well be right. It will not be repeatable, and the same request in month nine will get a different answer from a slightly different room.
With a principle in the charter, the question narrows to two parts. Does this request fall under the rule? If it does, the answer is already written and the meeting spends four minutes rather than forty. If someone wants the opposite of what the rule says, they have to argue that the principle itself was wrong, which is a far better use of a steering committee's time and a decision worth recording with its reasoning. Either way the room moves quickly, and it moves the same way it moved last time.
That second path matters. Principles are not there to prevent reconsideration, and a sponsor who overturns one deliberately, with the trade-off restated and the consequences priced, has used the charter well. What you are trying to stop is the quiet version, where the principle is neither followed nor withdrawn.
The sponsor and the project manager, together. Neither alone produces anything useful. A delivery team writing its own principles will lean, honestly and predictably, toward the choices that make delivery tractable — build over buy, because building is more interesting and easier to defend technically. A sponsor writing alone produces platitudes, because platitudes are what you get when you name values without knowing where the trade-off actually bites.
The project manager knows which decisions will come under pressure and roughly when. The sponsor is the one who will live with the worse outcome on whichever dimension the principle concedes, and only that person has the standing to concede it in advance. A principle spends someone's authority ahead of time. It has to be spent by the person who owns it.
The timing is the whole trick. Principles get written at the business case, before funding, before a team is hired, before anyone's reputation is attached to a particular answer. At that point the trade-off is hypothetical, which is exactly why the answer will be honest.
Three to five. Past that, two things break. The first is memory — nobody recalls fifteen rules in a meeting, and a principle that has to be looked up will not be looked up. The second is worse. 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 are the real limit. With four you can see them and resolve them on the page. With fifteen you discover them live, in the room, at the moment the principle was supposed to be helping.
A principle nobody has cited in six months is either wrong or was never load-bearing. Both are worth knowing. Ask at each gate which principles have been used since the last one and on what — the ones that never come up are describing a tension the program does not actually have, and they can go. The dangerous case is the principle everyone has quietly stopped following. Once one rule is understood to be optional, the rest are negotiable too, and the charter goes back to being a document rather than an instrument.
Retiring a principle should look like any other governance decision. Someone with authority, a date, a reason, and a record.
A decision made under time pressure, with a vendor waiting and a date in the room, is a poor decision even when it happens to be the right one, because nobody in the room had the calm or the information to make it well. The same decision, taken months earlier while the trade-off was still hypothetical, is not a different decision, it's the same decision made well. Most of what governance does is move decisions earlier.
Tollgate keeps design principles in the business case — a field in the versioned investment thesis, sitting with the business problem, the target outcome, the scope bounds and the named decision authority, approved by the sponsor when the money is committed. Change requests, gate decisions and the append-only decision log live in the same record, so when a principle is cited or overturned, the reasoning is written where the next person will look. Forge-native, 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.