These are not best practices, not principles, not even a manifesto.
They are real observations from the trenches…
Things noticed over years of working in architectural practices where Revit, BIM, standards, templates, audits, and good intentions all collide with deadlines, hierarchies, and human behaviour.
Each Field Note is a pattern that shows up again and again — regardless of software version, project scale, or how well-written the BIM Execution Plan looks.
If one of these makes you uncomfortable, it’s probably doing its job.
Culture eats software for breakfast
Tools don’t fail in isolation.
They fail inside organisations.
This note sits behind every story about “bad BIM”, resistant teams, or expensive platforms that never quite deliver what was promised.
Standards without intent aren’t standards. They’re folklore
Rules outlive the problems that created them. Templates become rituals.
Compliance replaces understanding.
This note is about inherited behaviour — and what happens when nobody remembers why a rule exists, but everyone still enforces it.
→ The Five Monkeys and the Revit Model
→ Cargo Cult BIM
Revit doesn’t punish curiosity. Offices do
Most tools are more flexible than we give them credit for.
What actually limits experimentation is social pressure: risk-aversion, unspoken hierarchies, and the fear of being seen as “difficult”.
This note explains why innovation quietly dies long before it reaches a model.
→ The Five Monkeys and the Revit Model
Past pain is not evidence of present risk
Something breaking once does not make it permanently dangerous. Yet many workflows are frozen in time by a single bad experience — retold until it becomes policy.
This note legitimises retesting, sandboxing, and letting go of decisions made under very different conditions.
→ The Five Monkeys and the Revit Model
Consistency is not the same thing as quality
Uniform outputs are easy to audit.
Good outcomes are harder to measure.
This note sits behind every critique of checkbox BIM, performative metrics, and processes optimised for appearance rather than usefulness.
→ Moneyball BIM
Most BIM problems are social problems pretending to be technical
When something “breaks” in BIM, the instinct is to blame the tool: the model, the template, the software version. In reality, the issue is usually about ownership, communication, trust, or incentives. The technical failure is just where the tension becomes visible.
Throwing people at a model never makes it mature faster
Adding more hands to a struggling model feels productive, but it usually increases coordination overhead, inconsistency, and rework. Maturity comes from clarity of intent and structure, not headcount.
This note pushes back against panic staffing near deadlines. It encourages investment in model structure, decision-making, and responsibility instead of short-term capacity theatre.
Metrics without context optimise the wrong behaviour
What gets measured gets gamed. When BIM metrics are applied without understanding why they exist, teams learn how to pass audits rather than deliver value. Consistency and compliance become proxies for quality.
This note acts as a warning against checkbox BIM. It asks you to interrogate what your metrics are actually encouraging people to do — and what they quietly discourage.
Automation doesn’t remove judgement — it exposes where you avoided it
Automation only works when decisions are already clear. If a workflow falls apart once it’s automated, it’s usually because the underlying judgement was never made explicit in the first place.
This note reframes automation as a diagnostic tool. Instead of asking “why doesn’t this script work?”, it asks “what decision did we refuse to make?”
How to read this site
The Field Notes are the lenses.
The blog posts are the case studies.
Each article exists because one of these notes proved true — again.
New Field Notes are added slowly, if at all. Most ideas don’t earn one. That’s intentional.
This page doesn’t change often.
The work underneath it does.