Landscape architecture firms often say they want people who understand how projects move from concept through construction. Fair enough. Every design firm needs that kind of range.
The problem is that in a lot of firms, what they really mean is: we need someone who can inherit a pile of context that was never made portable in the first place.
That context lives in people’s heads, in email threads, in marked-up PDFs, in old detail sets, in construction administration notes, in half-remembered stories about why the team stopped doing something a certain way three projects ago. When the right person is still around, the firm feels smart. When they leave, the same firm suddenly feels like it has amnesia.
Where The Context Actually Lives
The drawings survive. The context often does not.
You can usually sort the lost knowledge into three buckets.
Concept-phase knowledge usually lives with the lead designer and the project manager. Documentation knowledge gets scattered across standards, templates, and whatever old packages people can still find. Construction knowledge is the most fragile of all. It is often buried in field reports, RFIs, punchy email threads, and the memory of whoever handled construction administration.
That is why a departure hurts more than firms expect. The files remain. The decision context thins out. The next team can see what was built, but not always why it was built that way, what constraints shaped it, or what tradeoffs were already tested and rejected.
Why “Document Better” Usually Fails
The default response from leadership is predictable: we need better documentation.
I understand the instinct. It just tends to solve the wrong problem.
Documentation is usually treated as extra work that happens after the real work. So it gets deferred. When it does happen, it often captures the artifact rather than the reasoning. A precedent set shows the final drawing. A folder name tells you where the files went. Neither one reliably tells the next person why that detail was chosen, what site condition forced the revision, or what lesson the team would absolutely not want to relearn from scratch.
That is the gap. The firm saves artifacts. The staff who come later need context.
The Cost Of Knowledge Loss
The cost is not only replacement expense when someone leaves. It shows up in repeated mistakes, slow handoffs, reinvented details, and senior staff answering the same retrieval questions over and over again.
Where did we solve drainage on a project with similar grade conditions?
Which jurisdiction pushed back on that planting palette?
Why did we stop using that wall detail?
Who remembers how the consultant team handled that sequence on the last school project?
Those are not unusual questions. They are signs that valuable knowledge is present somewhere in the firm but inaccessible at the moment it matters.
That is expensive. Not in a dramatic, line-item way at first. In a slow leak kind of way. Knowledge retrieval eats time that should be going into design judgment. Senior people become walking indexes. New staff take longer to get productive because orientation work never really stops.
What A Knowledge Workflow Layer Does
The firms that handle this better are not necessarily documenting more. They are capturing more context while the work is already happening.
That is a different habit and a different systems problem.
When a design review happens, the rationale can be attached there. When a detail is approved, the precedent and the reason for the adaptation can be stored there. When an RFI comes in during construction administration, the answer can carry the local context with it instead of disappearing into another mailbox.
That is what I mean by a knowledge workflow layer. Not some grand knowledge-management fantasy. Just a way for context to travel with the work instead of evaporating after the meeting ends.
The Three Traps
If a firm has this problem, it usually shows up in one or more of three ways.
The archaeology problem. A new project starts and someone asks, “What did we do last time?” Answering it requires pinging three people and opening six folders with names like FINAL_v2_REVISED_USE_THIS.
The bottleneck problem. Certain people are indispensable not because they are the only ones qualified to decide, but because they are the only ones who remember the path that got the team here.
The reinvention problem. Similar conditions keep producing fresh work from scratch because the prior solution is technically somewhere in the archive but operationally unavailable.
Any one of those should get your attention. Two or three together usually mean the firm has a systems problem, not merely a filing problem.
What To Build First
This does not require a giant documentation initiative. Those tend to die under their own ceremonial weight.
I would start much smaller:
- identify where valuable context is already being created
- attach lightweight rationale capture to those points
- make retrieval show up inside the next workflow that needs it
- measure whether handoffs get faster and precedent hunting gets shorter
That is enough to change the texture of the work. New staff get oriented faster. Senior staff stop serving as manual search engines. The next project starts with memory instead of vibes.
And in design firms, that matters. Accumulated project knowledge is one of the few advantages that actually compounds. When it is accessible, the firm prices better, designs better, and avoids reliving the same field lessons. When it is trapped in scattered files and human memory, it walks out the door one resignation at a time.
The drawings are not the whole asset. The reasoning is part of the asset too. Firms that treat it that way operate very differently.
I work with design firms to build knowledge workflow layers that capture decision context automatically and surface relevant precedents at the right moments. The process starts with a Knowledge Workflow Audit that identifies where your firm’s valuable context is being lost and maps a path to capturing it. Get in touch if you want to talk through it.