Notes.

A practice that takes on too many engagements stops being a practice and becomes a service organisation. The arithmetic is unforgiving. There is a fixed amount of attention available in a year, and dividing it across a growing number of clients does not produce more attention — it produces less, distributed thinner.

We have a hard ceiling on how many engagements we accept in a year. Not because we lack ambition, but because senior-led work demands the practitioner's actual hours — read, write, think, attend — not a delegated facsimile of them. If the work cannot be done properly within the cap, it is not work we should accept.

This is also why we say no — to retainers, to framework agreements, to anything that lets scope expand without a fresh decision. Each engagement begins and ends, and the gap between them is when the practice does its own thinking.

Smallness is not a constraint. It is the discipline.

A proposal is a document a vendor produces to win a job. We are not vendors.

When a practice writes a proposal, what it is really saying is: "I have not been hired yet, and I am willing to spend my time competing for the work rather than doing the work." This is a fine bargain for vendors, who have many proposals in flight at once and only need a fraction to convert. It is a poor bargain for a practice that takes on a small number of engagements per year and earns work by reputation.

Instead: a brief letter back to the prospective client, written in our voice, a paragraph or two on whether the engagement fits and how we would scope it. Either we both agree the work is right, or we agree it is not. No competitive proposal, no scope-shaped speculation.

This works because we are senior-led, discreet and known. It would not work for a vendor at scale. We are not at scale. That is the point.

Peer review is often described as quality control. We think that is wrong. It is more accurately a system of disciplined attention.

A peer reviewer reads a manuscript with a particular kind of attention: not the author's, not a critic's, but a colleague's. The question is not whether the work is good or bad in the abstract, but whether it does what it claims to do, in language a reader other than the author can follow, with evidence a reader other than the author can check.

This is precisely the attention we offer when we write a forensics report or a system specification. We are not arguing for a position; we are reading the work — the logs, the architecture, the integration — and reporting what is there in language another professional can verify.

The discipline is the same. The journal article and the technical brief are two versions of the same kind of object: an account, signed, that someone else will read carefully.