A change advisory board when there are three of you

Strip the ceremony away and a change advisory board does one job: it puts somebody other than the person making a change in a position to stop it. Everything else, the membership list, the agenda, the Thursday slot, is machinery built to make that one job happen reliably at scale.

Atlassian describes the CAB as a cross-functional group that provides oversight and guidance to change management teams from the initiation of a change ticket through to post-implementation, and is explicit that CABs have shed the gatekeeper label and become strategic advisors rather than a queue. The same page lists seven suggested member roles, including a change manager, service desk analysts, an operations manager, an information security officer and senior network engineers.

You do not have seven roles. You have three people, one of whom is also doing the client call. Copying the membership list is how a small team ends up with a process it stops using in six weeks, which is worse than never having had one.

There is also a decent argument that the meeting is the wrong instrument even at scale. Atlassian's roles guidance is unusually blunt about it, citing the State of DevOps Report 2019 to the effect that procedures requiring CAB approval can negatively affect performance, with no evidence that formal approval processes produce lower change failure rates. It also quotes ITIL 4 directly: in high-velocity organisations it is common practice to decentralise change approval, making peer review a top predictor of high performance.

So the question is not how to shrink the board. It is which of the board's functions you genuinely need, and the honest answer is two: risk assessment before the change goes live, and a written record of who approved it.

The enterprise pattern is a standing meeting because at that scale you cannot predict who needs to be in the conversation. On a team of three you always can, which means the meeting is pure overhead and the routing rule does the same work.

A routing rule says: for this class of change, this named person approves, within this window, or the change proceeds. Three sentences, written once, applied every time. The person is named because a role is not accountable and a person is.

The deadline matters more than most teams expect. Without one, review becomes an unbounded queue and the change author starts routing around it, which is how you get an approval process with a 100 percent approval rate and no actual review happening. Atlassian's Cloud documentation ships a default here worth borrowing: the IT service template includes an SLA that allows five business days for approvers to act before it breaches, measured between an approval stage and an approval outcome.

Five business days is right for an enterprise change to a payment system. For a tag container publish it is absurd, and the correct number is measured in hours. The transferable idea is not the duration, it is that the review window is written down and has a defined consequence when it lapses.

The second row is the one that makes this work at small scale. Letting a reversible single-client change proceed after four hours with an unreviewed flag is a deliberate trade: you accept a slightly higher error rate on low-consequence changes in exchange for a process that never becomes the bottleneck. Count the unreviewed flags monthly. If the count is high, either the window is too short or the team is too thin, and both are worth knowing.

The consent row has no fallback because there is no version of that change that should proceed by default. Getting consent configuration wrong is not a data quality problem, it is a compliance one, and the asymmetry justifies a hard block.

The emergency row deserves the same discipline as the rest, applied afterwards. Emergency changes are reviewed after the fact, not exempted from review, and the review asks one question: could this have been a normal change if it had been caught earlier?

Enterprise change management attaches numeric risk scores to changes. On a small team those scores are invented, everybody knows they are invented, and the number becomes a way of dressing up a judgement call.

Ask four questions instead, in this order. Can this be reversed, and how fast? If it goes wrong, is the damage visible immediately or does it accumulate silently? Does anything downstream depend on the thing being changed? And has this exact class of change gone wrong before?

The second question separates the genuinely dangerous martech changes from the merely alarming ones. A broken tag is loud. A tag that fires with a wrong value is quiet, and by the time anyone notices you have three weeks of contaminated data and no way to recover it. That asymmetry is why measurement changes deserve more scrutiny than their apparent size suggests.

The fourth question is where a change log earns its keep. Atlassian's CAB guidance notes that boards monitor evolving change patterns and iteratively improve the change process, which is only possible if somebody is looking back at what failed. On a small team that is a fifteen-minute look at the last quarter's reverted changes, not a governance programme.

The role that survives compression is the change authority, which Atlassian defines as the person who decides whether or not to authorize a change, and notes may be a senior manager, a board, or simply a peer reviewer. The same page acknowledges that in small companies the change manager and the change authority are the same person. That is your situation, and it is a documented pattern rather than a compromise.

Where risk assessment becomes a formal artefact rather than a conversation, it belongs on the register rather than in the change record. The distinction between a risk you are carrying and an issue you are working is the subject of the difference between an issue, a risk and a blocker, and the register that holds the first is covered in a risk register that gets updated.

There are two ways this goes wrong and they look nothing alike.

The first is rubber-stamping. Approvals arrive in under a minute with no comment, every time, and the approval field becomes a formality that proves only that somebody clicked. The tell is the approval rate: if it has been 100 percent for a quarter across dozens of changes, either your team is extraordinary or nobody is reading. The fix is to reduce what requires approval until the remaining set is small enough that reading it is realistic.

The second is the queue. Approvals sit for days, delivery slows, and the change author starts batching six changes into one request to reduce the number of approvals needed. Batching is the worst outcome available, because it destroys the one thing the change log exists to give you, which is the ability to tie an effect to a single cause. When batching starts appearing, the process is already failing.

Both failures have the same root: the scope of what requires review was set by anxiety rather than by evidence. Start narrow. Add a class to the review list only after something in that class has actually broken something.

None of this scales up unchanged. On a programme with a sponsor and multiple workstreams, approval routing does become a scheduled forum, because the coordination cost of asynchronous review exceeds the meeting cost. Where that line sits, and who runs the forum, is part of what a fractional technical project manager is engaged to decide. A database automation programme decomposed into 159 tracked work items with acceptance criteria needed a sequenced approval structure precisely because no single reviewer could hold the dependencies in their head.

Write the routing table. Six rows, one page, named individuals. It will take twenty minutes and it will be wrong in two places, which you will discover within a month and correct.

Then set the windows deliberately rather than by default. Match them to how fast the underlying thing can hurt you: hours for anything that touches live measurement, days for anything with a legal dimension, never for anything on the standard list.

Add one field to the change record: approved by, with a timestamp. Not a status, a name. That field is the entire audit trail and it costs nothing.

Then leave it alone for a quarter and look at three numbers. How many changes proceeded unreviewed. How many were reverted within seven days. How many were batched. Those three tell you whether you have a control or a ritual, and they are worth more than any amount of process design done in advance.

The same asynchronous-review-against-a-deadline pattern shows up wherever a small team needs a control without a meeting, which is why it belongs in the same family as a definition of done a client has to accept rather than in a separate governance document nobody opens.