What Changes with Size

Overview

Structure and culture are a snapshot. Size is the force that changes both, and it changes them on a schedule you can anticipate.

The useful consequence is personal: the headcount at which an organisation hires its first architect tells you what the job is. Get that wrong and you spend a year solving the previous stage’s problem competently.

Three thresholds

graph LR
  A["<b>~50 engineers</b><br/>everyone stops<br/>knowing everyone"] --> B["<b>~150 engineers</b><br/>nobody holds the<br/>whole system<br/>in their head"]
  B --> C["<b>~500 engineers</b><br/>the architecture function<br/>itself needs structure"]

  classDef one fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef two fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef three fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A one
  class B two
  class C three

Three transitions. The numbers are soft — they depend on product complexity, turnover and how much the organisation communicates — but the order and the symptoms are reliable.

Around fifty engineers, informal coordination stops working. Below it, everyone roughly knows what everyone is building, and architecture happens in conversations. Above it, two teams make incompatible choices in parallel and nobody notices for a month. Symptoms: duplicated work, the same problem solved three ways, integration surprises. What the organisation needs: explicit interfaces and the first written standards. Architecture as an activity, done by senior engineers.

Around a hundred and fifty, nobody holds the whole system in their head. This is the painful one. The company can no longer assemble a shared mental model, so changes have consequences nobody predicted and integration becomes the bottleneck rather than construction. Symptoms: nobody can answer what the whole system does; every cross-team change needs an archaeology phase; the same architectural question is re-litigated because its answer was never recorded. What the organisation needs: architecture as a role. Which is why first architects get hired right about here.

Around five hundred, the architecture function itself needs structure. One person cannot hold the decisions, and the architect becomes the bottleneck they were hired to remove. Symptoms: decisions queue; teams proceed without asking because waiting is worse; standards exist and are ignored. What the organisation needs: a practice rather than a person — delegated decision rights, boards, and standards that work without their author present. Module 9’s subject.

What the hiring size tells you

The inference worth drawing:

An architect hired at fifty is there to make choices. An architect hired at a hundred and forty is there to stop the company colliding with itself.

Those are different jobs. The first is selection — which database, which style, which pattern. The second is coordination — making boundaries explicit, recording decisions so they stop being re-litigated, and giving the organisation a shared model of its own system.

Arriving at the second and doing the first is the characteristic failure of a new architect. You produce excellent technology selections for a company whose actual problem is that three teams disagree about what a job record is and nobody wrote down which one is right.

The diagnostic question for your own role: what did they hire you to stop happening? If the honest answer is “the thing where two teams built the same service twice”, your job is coordination, and your first useful artifact is a decision record rather than a technology choice.

Preparing for the next stage without building for it

The discipline is asymmetric: know what will break, and make only the cheap preparations.

A decision-record practice at a hundred and forty costs almost nothing and is the single most valuable thing you can have at three hundred. An architecture board at a hundred and forty is premature — it adds ceremony to an organisation whose problem is that nothing is written down, not that too few people approve things.

The test for a preparation: is it cheap now and expensive to retrofit? Those are worth doing early. Everything else waits, which is Module 3’s reversal-cost reasoning applied to practices rather than to designs.

Hired at the collision point

The facts: 320 employees, about 140 engineers, and the case states plainly that this is “past the point where everyone knows what everyone else is building, but well short of having formal processes to compensate — the size at which companies start colliding with themselves, and the size at which they hire their first architect.”

So the job is coordination, not selection. That reframes the earlier work: the stack choices in Module 4 and the agent design in Module 5 were real decisions, but they are not what this role exists for. What it exists for is that nobody holds the whole system in their head, and the evidence is specific — about twenty Go services produced by a two-year migration, no practice of recording decisions, no architecture board, and no mandate.

What is about to break, concretely. The migration’s service boundaries were set by whichever team extracted each slice, which the previous topic predicted. Nobody owns the resulting whole. At 140 that is uncomfortable; at 250 it becomes the thing that stops the migration finishing, because every remaining extraction requires reconstructing why the last five were shaped as they were.

The cheap preparation that pays later. Recording decisions. It costs a template and a habit now, and at 300 engineers it is the difference between onboarding an architect in a month and in a quarter. Module 9 builds it, and the argument for doing it first — before boards, before standards, before a technology radar — is exactly the cheap-now-expensive-later test.

The premature one to refuse. An architecture board. With no existing practice, no recorded decisions and no mandate, a board would be a meeting that approves things nobody wrote down. Workbook exercise 9 asks what you would deliberately delay; this is the answer, and the reason is the size.

And the reframe worth stating to Maya Ortiz, who sponsored the role: the AI platform is the occasion for hiring an architect, not the reason. The reason is that a 140-engineer company with no decision record is accumulating a coordination debt that the migration will eventually run into. That is a more durable justification for the role than any single initiative, and it is the argument that survives the initiative being cancelled.

Feeds the workbook

Your organisational analysis should state the size transition you are in and what it implies the job is. Your positioning statement then follows from it — you cannot say how you will build a remit until you know which problem the remit is for.

→ Structure, culture and size are the terrain. The last reading is who can actually say yes. — Power and who actually decides