Skip to main content
AI Inside Organizations

The Monoculture Problem of Expertise

Teams need useful specialisation and more than one route to understanding critical work.

Examine how concentrated knowledge and shared methods create different organisational vulnerabilities, and how to build tested coverage without duplicating every role.

The Monoculture Problem of Expertise

A platform team has twelve engineers, a shared incident guide, and an AI assistant that searches its service documentation. During an outage, several people investigate in parallel. Each begins with the same dashboard, accepts the same explanation of the symptoms, and tests a variation of the same hypothesis.

The team has enough people to divide the work, but its apparent breadth conceals a common starting point. A specialist who understands the data pipeline later notices that the dashboard is reporting incomplete information. The earlier investigations were competent within an account of the incident that none had independently examined.

The monoculture comparison is a metaphor for that narrowness, not a claim that teams behave like crops or ecosystems. Organisations can become vulnerable when important knowledge is concentrated in too few people or when many people share the same untested method. Those are different problems, and adding headcount does not necessarily resolve either one.

Distinguish concentrated knowledge from shared blind spots

A single specialist may hold the only practical understanding of a legacy billing rule. The vulnerability is coverage: the service depends on that person being available and able to act. Another team may have many capable specialists who all depend on the same incomplete documentation. Its vulnerability is the shared representation of the work.

Both deserve attention, but their remedies differ. Developing another person can reduce dependence on one specialist. It may do little for a misleading reference document if both people learn from it without testing it against the system. Conversely, adding another analytical method does not provide cover when nobody else can execute the required correction.

Map these dimensions separately:

DimensionQuestion that reveals the dependency
PeopleWho can perform the critical task when its usual owner is absent?
EvidenceWhat can contradict the team’s common account of the problem?
MethodsCan the team investigate through more than one useful approach?
AccessCan the alternative investigator reach the required records and tools?
AuthorityCan the person who understands the problem make or obtain a decision?

The map should refer to tasks and scenarios. A list of technologies on employee profiles gives little evidence that two people can independently recover a failed service. Ask what each person has actually demonstrated and which parts remain dependent on someone else.

Keep specialisation while building usable coverage

Specialisation can support depth, speed, and sound judgment. A team does not need every employee to know every subsystem equally well. The objective is enough coverage and coordination for the outcomes the organisation expects to deliver.

For a critical billing rule, a second person might need to diagnose common exceptions, identify dangerous uncertainty, and execute a supervised correction. A deeper specialist could remain responsible for rare policy interpretation. The arrangement is viable if escalation, availability, and response time fit the service’s requirements.

Develop coverage through actual decisions. Let the learner lead a representative investigation while the specialist observes. Record where the learner needs help and repeat the relevant task with a changed case. A second name on a support roster should follow evidence of capability rather than serve as a substitute for it.

Do not expect the specialist to transfer knowledge while retaining an unchanged delivery workload. Teaching requires selecting cases, exposing reasoning, and responding to questions. The investment considered in the maintenance cost of expertise includes that short-term reduction in available production time.

Research by Darr, Argote, and Epple found differences in knowledge transfer across ownership boundaries within a franchise setting. It is not evidence for a universal handover method, but it cautions against assuming that useful experience automatically spreads wherever people work on related tasks.

Examine the sources that everyone trusts

In the incident example, the dashboard is a shared evidence source. A fault in its collection pipeline can mislead several investigators at once. The relevant safeguard is a way to examine the underlying events or another appropriate observation, not another person refreshing the same chart.

HSE’s guidance on control systems examines independence and common-cause failure in industrial protection systems. The transferable question is which shared dependency could defeat several apparently separate checks. Applying that question to knowledge work is an analytical exercise, not a claim that a business team meets an industrial safety standard.

Review the team’s common assumptions too. An incident guide may state that a particular error always means a database problem. Ask what evidence supports the rule, which versions it applies to, and what would show that it no longer fits. A well-used guide can be valuable while still needing a clear route for revision.

When a new incident falls outside the guide, preserve the alternative explanations long enough to test them. Prematurely converting the first plausible account into the shared account can narrow the investigation before the evidence warrants it. Someone should own checking the assumptions behind the account, alongside the people testing its consequences.

Different routes into an incident
Different routes into an incident Service incident Application behaviour and traces Underlying data and pipeline checks Recent changes and operating constraints Compare findings and assumptions Test explanation and decide action
Investigators compare evidence and methods before combining their findings into an operational decision.

Check whether AI broadens the inquiry

A shared assistant can make specialist knowledge easier to find and help people encounter unfamiliar approaches. It can also give several people similar starting explanations, particularly when they ask similar questions against the same material. Evaluate the resulting inquiry rather than assuming that tool access either creates or destroys diversity.

Doshi and Hauser’s research on AI-assisted creative writing found improved evaluations of individual stories alongside greater similarity between AI-assisted stories. That experiment concerned short fiction. It does not establish that engineering teams lose expertise or that every shared model makes decisions uniform.

Its relevance is a narrower possibility worth testing: individual output can improve while variation across outputs decreases. In an investigation, several polished analyses may still leave the same explanation unexplored. Compare which evidence sources and hypotheses the analyses cover, not only how convincing each report appears on its own.

For selected cases, ask investigators to identify their starting evidence and possible explanations before combining findings. An assistant can then suggest further tests or challenge an account. Keep the source checks visible, especially when the assistant’s answer is derived from the same guide the team is trying to assess.

Changing model providers does not automatically establish another knowledge path. The providers may receive the same incomplete extract or be asked the same narrowing question. Equally, two people using one assistant can investigate differently if they bring distinct evidence and responsibilities. Trace the actual dependence before labelling either arrangement independent.

Test breadth through the work it must support

Choose scenarios that require more than routine delivery. One might remove the usual specialist from an exercise; another might introduce a misleading dashboard; a third might require a decision across a handoff between teams. These scenarios examine different vulnerabilities and should produce different evidence.

A coverage exercise should establish whether the substitute can reach the records, recognise the problem, select an appropriate action, and obtain authority to act. A method-diversity exercise should establish whether someone can question the shared account and test another explanation. Passing one does not establish the other.

Measure useful outcomes: time to locate the right expertise, quality of the diagnosis, support required, and whether the intervention reached the service. Count unresolved dependencies honestly. A team that identifies a gap during practice has gained information that a reassuring roster would not provide.

Keep exercises proportionate and controlled. Simulations and replays can expose reasoning without creating a live outage. Record what was omitted from the exercise, including scale, concurrent demand, or access conditions. Those limitations affect how much confidence the result can support.

After an exercise, give someone responsibility for the gap. That might mean developing a second operator, correcting a reference source, maintaining an alternate diagnostic path, or clarifying decision rights. Feedback failure in expertise becomes relevant when a team repeatedly discovers the same weakness without changing how work is learned or supported.

Review the arrangement after organisational and technical changes. A reorganisation can separate people who once solved a problem together, while a tool migration can remove the independent source used by a fallback investigation. Capability depends on these relationships as well as individual knowledge.

Give alternative investigation a bounded purpose. During an outage, someone can check whether the shared telemetry is complete while others pursue the leading hypothesis. Agree what evidence would justify continuing, changing direction, or stopping that additional inquiry. This preserves a route for challenge without requiring every investigator to explore every possibility.

Do not reward disagreement by itself. The team needs alternatives that improve its ability to understand and act, and sometimes independent checks will support the same explanation. Retain the evidence behind that agreement. It shows which assumptions were actually tested and gives the next investigator a firmer starting point than a record that everyone simply concurred.

The useful outcome is a team with sufficient depth and tested alternatives. Preserve the specialists whose judgment matters, develop enough cover for their critical work, and examine the common evidence and methods that can mislead everyone together. That builds a more credible account of resilience than either counting experts or requiring everyone to become a generalist.