How Much Time Do Engineers Waste Searching for Information?
By Norbert Wlodarczyk
Your engineers are building less than you think. Not because they’re slow. Because they’re searching.
The number everyone cites
A McKinsey report found that knowledge workers spend 19.8% of their work week - nearly one full day - searching for and gathering information. Not building. Not reviewing. Not thinking about architecture. Just trying to find something that already exists somewhere in the organization.
That number has been floating around boardrooms for over a decade now, usually rounded to “20% of the work week.” It’s become one of those statistics people nod at and then do nothing about.
But here’s what makes it worse: that figure is an average across all knowledge workers. For engineers, the problem compounds. Engineering work depends on layered context - understanding not just what a system does, but why it was built that way, what constraints shaped it, which decisions still hold and which have been quietly superseded. Every search isn’t a quick lookup. It’s an investigation.
The studies behind the stat
The McKinsey number isn’t an outlier. Multiple studies converge on the same range.
IDC’s knowledge worker study found that employees spend 2.5 hours per day searching for information, and fail to find what they need 50% of the time. That failure rate is the part most people skip over. Half the time, the search doesn’t even succeed. The engineer either gives up, asks someone senior, or makes a decision without the context they were looking for.
A 2022 survey by Coveo reported that 74% of employees have trouble finding information needed to do their job. Not obscure information. The basics: who owns a service, what was decided last quarter, whether a particular approach was already tried and rejected.
And Stack Overflow’s Developer Survey consistently shows that developers spend 30-60 minutes per day just searching for answers to technical questions - and that’s only the external search. Internal search - finding the right Slack thread, the current architecture doc, the decision that explains why the API works this way - doesn’t show up in those numbers.
The research points in one direction. Engineers are spending somewhere between one-fifth and one-quarter of their working hours looking for information instead of using it.
What search time actually costs your team
Let’s make this concrete with a per-team calculation.
The inputs you need:
- Number of engineers on your team
- Average fully-loaded annual cost per engineer (salary + benefits + overhead)
- Estimated percentage of time spent searching (use 20% if you don’t have internal data)
The formula:
Annual search cost = Engineers x Fully-loaded cost x Search percentage
For a team of 30 engineers at $200K fully-loaded cost each, using the conservative McKinsey 20%:
30 x $200,000 x 0.20 = $1,200,000 per year
That’s $1.2M annually spent on engineers looking for things. Not building features. Not fixing bugs. Not improving performance. Searching.
Scale it to 80 engineers and you’re at $3.2M. At 150, it’s $6M. These aren’t theoretical numbers. They’re arithmetic applied to research that’s been replicated across industries for fifteen years.
But the direct cost is only part of the story.
The costs you’re not counting
The 20% figure captures active search time. It doesn’t capture three downstream effects that arguably cost more.
Context switching penalties. When an engineer stops building to search for information, they leave a flow state. Research by Gloria Mark at UC Irvine shows it takes an average of 23 minutes to regain deep focus after an interruption. If an engineer searches for information four times a day, that’s potentially 92 minutes of recovery time on top of the search time itself. The real productivity loss isn’t 20%. It’s closer to 30%.
Interrupt-driven knowledge transfer. When search fails - and IDC says it fails half the time - the fallback is asking someone. Usually someone senior. That means your search problem becomes a senior engineer productivity problem. Every question that couldn’t be answered by the knowledge base is a question that pulls two people out of productive work instead of one.
Decisions made without context. This is the cost nobody tracks. When an engineer can’t find the information they need, they don’t always escalate. Sometimes they make a judgment call with incomplete context. They reimplement something that already exists. They contradict a decision they didn’t know about. They build on an assumption that was invalidated three months ago. The cost surfaces later as rework, tech debt, or incidents - and it’s never attributed to the original search failure.
How to measure it on your team
You can calculate the dollar figure above in two minutes. But if you want a more honest picture, run this exercise with your team.
For one week, ask every engineer to track:
- How many times per day they searched for internal information (docs, Slack history, asking a colleague)
- How long each search took
- Whether the search succeeded, partially succeeded, or failed
- What they did when it failed (asked someone, guessed, or dropped the task)
Most teams that run this exercise discover three things. First, the search frequency is higher than anyone expected - eight to twelve searches per day is typical. Second, the success rate is lower than anyone assumed. Third, most failed searches end with interrupting a senior engineer, which means the cost is distributed across the team in ways that don’t show up in any individual’s timesheet.
If tracking feels like too much overhead, try the simpler version: ask your three most recent hires how much of their first month was spent searching versus building. New engineers feel the search problem most acutely because they don’t yet have the tribal knowledge shortcuts that tenured team members rely on.
Why this is getting worse, not better
You might expect that better tooling would reduce search time over the years. The opposite has happened.
The average engineering team now operates across more tools than ever. Slack, Confluence, Notion, Google Docs, Jira, GitHub, Linear, Figma - each one a potential location for the answer you need. The information isn’t missing. It’s fragmented across platforms, with no single system that knows how the pieces connect.
A 2023 report from Grammarly and Harris Poll found that knowledge workers use an average of six different communication tools. Each tool has its own search, its own permissions model, its own conventions for where things live. The result is that finding information requires not just searching, but knowing where to search - which tool, which channel, which project space.
This fragmentation means that the organizations generating the most knowledge are often the worst at retrieving it. Every new Slack channel, every new Notion workspace, every new Google Drive folder adds another place where an answer might be hiding.
What actually reduces search time
The teams that have meaningfully reduced their search burden share a few traits.
They index across tools, not within them. Searching Confluence doesn’t help if the answer is in a Slack thread from last quarter. The search layer needs to span the entire knowledge surface.
They preserve relationships between information. A document about your payment service is more useful when it’s connected to the team that owns it, the decisions that shaped it, the incidents that tested it, and the other services it depends on. Flat search returns a list of results. Connected search returns context.
They treat search failure as a system problem, not a user problem. When an engineer can’t find something, the default assumption in most orgs is that they didn’t look hard enough. In high-performing teams, the assumption is that the knowledge infrastructure failed - and they fix the gap before the next person hits the same wall.
These aren’t just process changes. They require tooling that understands knowledge as a graph - connected, evolving, and queryable across the full surface of how your organization communicates and decides.
That’s the problem Nexalink was designed to solve. We connect your existing knowledge sources into a single, searchable graph where information is linked by context - not just keywords. If your team is spending a million dollars a year on search time and you’d like to see what an alternative looks like, we should talk.