We usually start measuring a piece of work when implementation begins. By then, quite a lot may already have happened.
Someone has looked through old tickets, tried to understand an unfamiliar part of the product, asked who owns it, compared several versions of the same rule and waited for a colleague who remembers why a decision was made. That work is easy to overlook because it is spread across messages, meetings and short interruptions.
I have started treating it as part of delivery rather than preparation for delivery.
Knowledge is spread across the product
Documentation is one place to look, but it is rarely the only one. Useful context may sit in a database column, a naming convention, an old release note, a support exchange or the memory of the person who worked on the feature three years ago.
People who know the product well move through this landscape quickly. They already know which ticket matters, which table is misleading and who can confirm an assumption. A newcomer sees the same material without the same map.
The problem is therefore not always missing knowledge. Quite often, the knowledge exists but is difficult to locate or difficult to trust.
Teams can recreate things they already have
I have seen a team prepare a new data structure because nobody present could find the existing one. The proposed change was reasonable, and the work around it—analysis, implementation planning, review—was real. Only later did someone with the missing context point out that the product already supported the need.
This is not simply a documentation failure. It is a discoverability failure.
When the path to an existing decision is unclear, recreating it can look safer than continuing to search. The organisation then pays twice: once for the original solution and again for rediscovering or rebuilding it.
The cost arrives in fragments
Search cost rarely appears as a clean block in a plan. It looks more like this:
- twenty minutes reading tickets with inconsistent titles;
- a short meeting to identify the actual owner;
- several messages asking for historical context;
- an afternoon comparing code, configuration and documentation;
- a delay because the only person who knows the area is unavailable.
Each item looks minor. Together they can become a significant part of the work, especially in mature products.
This also explains why a task can feel tiring before any visible output exists. The effort has gone into reconstructing the conditions needed to make a sound decision.
Faster delivery sometimes starts before implementation
Improving development practices is useful, but it does not solve every delay. A team will still move slowly if basic questions are expensive to answer:
Where does this rule live? Who can decide? What was already tried? Which source should we trust?
Clear naming, visible ownership, decision records and maintainable documentation all help. None of them needs to capture everything. Their purpose is to reduce the distance between a question and the context required to answer it.
A useful test is: can someone unfamiliar with the feature find a reliable starting point without first locating the person who remembers everything?
Finding is not work that happens before the real work. In many teams, it is a substantial part of the real work.