Relentlessly Steer Applicability

Applicability is often treated as the final question.

After the strategy is written, after the system is built, after the
workshop is delivered, after the policy is approved, after the model is
presented, someone eventually asks:

Can people actually use this?

That question should not arrive at the end.

It should guide the whole initiative.

Applicability is not a soft preference. It is a discipline. It is the
discipline of keeping ideas, tools, systems, measures and practices
connected to the real conditions in which they must work.

An initiative that is not applicable may still look impressive.

It may have strong logic, good slides, elegant language, modern
technology, detailed process maps and executive approval.

But if it cannot be used well in the real world, it is not yet
relevant.

The real measure of relevance is applicability.

Applicability Is Not
Simplicity

Applicability does not mean making everything simple.

Some work is complex because the world is complex. A hospital,
university, bank, logistics network, manufacturing plant, public
service, software platform or large organisation cannot always be
reduced to a few easy steps.

The problem is not complexity by itself.

The problem is complexity without use.

An applicable solution can be complex if the complexity is necessary,
visible and manageable. It can ask people to learn. It can require
judgement. It can introduce new disciplines. It can change how work is
done.

But it must still connect to practice.

People must understand what it is for. They must know when to use it.
It must fit into the flow of work. It must be measurable in ways that
matter. It must produce information that helps people act. It must
improve the system rather than merely describe it.

Applicability asks:

Where will this live?

Who will use it?

What decision will it improve?

What behaviour will it change?

What evidence will show that it is working?

What will people do differently because this exists?

If these questions cannot be answered, the initiative may be clever,
but it is not yet applicable.

The
Difference Between Relevance and Presentation

Many initiatives are presented as relevant because they sound
current.

They refer to digital transformation, artificial intelligence,
agility, customer centricity, data-driven decision-making, resilience,
innovation, culture, productivity or performance.

These themes matter.

But language can create the illusion of relevance.

An initiative becomes relevant only when it is located in real-world
measures and practices.

For a customer service initiative, relevance may be shown in
resolution time, first-contact resolution, repeat contacts, customer
effort, complaint patterns, escalation quality and product defects
resolved.

For a learning initiative, relevance may be shown in changed
behaviour, improved capability, fewer errors, better decisions, faster
onboarding or stronger performance in the work itself.

For a technology initiative, relevance may be shown in adoption,
reliability, task completion, reduced rework, lower support burden,
improved data quality or better customer outcomes.

For a strategy initiative, relevance may be shown in resource
allocation, trade-offs made, projects stopped, capabilities built and
decisions changed.

Without this connection, relevance remains a claim.

Applicability turns relevance into evidence.

Steer Applicability from
the Beginning

Applicability must be steered relentlessly because initiatives
drift.

They drift toward internal politics.

They drift toward fashionable language.

They drift toward what is easy to measure.

They drift toward what the system can already report.

They drift toward what the vendor can demonstrate.

They drift toward what senior people want to hear.

They drift toward completion rather than usefulness.

This drift is rarely malicious.

It is the natural movement of organisational work when nobody keeps
asking whether the initiative still connects to real practice.

To steer applicability is to keep returning to the point of use.

What problem are we solving?

Who experiences the problem?

Where does it appear in the workflow?

What does good look like in practice?

What evidence would show improvement?

What action should be taken when the evidence appears?

What would make this initiative irrelevant even if it is
completed?

These questions should not be asked once.

They should be asked throughout the work.

People Give Information

People give information all the time.

They describe frustrations. They make mistakes. They create
workarounds. They abandon processes. They call support. They delay
decisions. They complain. They repeat tasks. They ignore dashboards.
They ask the same question again. They use one part of a system and
avoid another.

All of this is information.

The problem is that organisations often treat this information as
noise.

They see the user as difficult, the customer as uninformed, the
employee as resistant, the manager as impatient or the stakeholder as
unrealistic.

Sometimes that may be true.

But it is a dangerous first assumption.

People’s behaviour often reveals whether a system is applicable.

If users keep calling support, the issue may not be that they refuse
to learn. The system may be unclear.

If managers keep asking for manual reports, the dashboard may not
answer the real decision.

If employees keep bypassing a process, the process may not fit the
work.

If customers keep misunderstanding an instruction, the communication
may not be designed for them.

If adoption is low, the problem may not be motivation. It may be
relevance.

People give information.

Applicable systems listen.

Observability Is a
Management Discipline

Applicability cannot be steered by opinion alone.

It needs observability.

Observability means that the organisation can see what is happening
in the system with enough clarity to understand behaviour, performance,
failure, friction and consequence.

In technology, observability is often associated with logs, metrics
and traces.

In management, the principle is broader.

Can we see where the work slows down?

Can we see which errors repeat?

Can we see which customer problems are really product problems?

Can we see whether people are using the process as designed?

Can we see where decisions are delayed?

Can we see what people do after training?

Can we see where the system produces rework?

Can we see whether a measure is driving the behaviour we
intended?

If we cannot see these things, we are managing through stories.

Stories matter, but they are not enough.

Without observability, teams argue from anecdotes. The loudest
complaint becomes the priority. The most recent incident becomes the
pattern. The most confident interpretation becomes the truth.

Observability gives management a better relationship with
reality.

Instrumentation
Separates Signal from Noise

Instrumentation is the discipline of deciding what to measure, where
to measure it, how to interpret it and what action should follow.

This matters because not all information is useful.

Some information is signal.

Some information is noise.

Signal tells us something meaningful about the system. It reveals a
pattern, a failure, a constraint, a user need, a risk or an
opportunity.

Noise distracts us. It may be dramatic, recent or emotionally
persuasive, but it does not necessarily explain what is happening.

The danger is that organisations act on noise.

They change policy because of one incident. They blame users because
the dashboard shows low adoption. They increase training because errors
are visible, while the real problem is poor system design. They add
controls because a process failed once, while the real issue was an
exception that needed judgement.

Bad instrumentation creates wrong action.

Good instrumentation helps people ask better questions.

What is the pattern?

How often does this happen?

Where does it happen?

Who is affected?

What changed before the problem appeared?

What action did the user take?

What did the system make easy?

What did it make hard?

What would we expect to see if our interpretation is correct?

Instrumentation is not measurement for its own sake.

It is measurement in service of applicability.

The Browser Example

Consider a customer service agent helping a user who cannot complete
a task in an application.

The user reports the problem.

The agent asks which browser they are using.

The agent then says, “Install another browser.”

At first this may look practical. The customer receives a workaround.
The call may be closed. The support metric may improve. The agent may
have followed the knowledge base. The immediate problem may even
disappear.

But applicability has not been served.

The customer did not want to become a browser tester.

The customer wanted the application to work.

If the correct response is always to ask the user to install another
browser, then the organisation is transferring the burden of system
failure to the user.

The more applicable response is different.

Yes, help the customer complete the task.

But also capture the signal.

Which browser?

Which version?

Which page?

Which action?

Which error?

How often has this happened?

Can it be reproduced?

Is it affecting a segment of users?

Is the problem in the application, the browser, the configuration,
the integration or the user’s environment?

Then work with the vendor or product team to improve the
application.

This is the difference between a workaround and a learning
system.

A workaround solves the ticket.

A learning system improves applicability.

When Measures Create
the Wrong Behaviour

Applicability is often damaged by measures that appear
reasonable.

If customer service agents are measured mainly on call duration, they
may close conversations too quickly.

If they are measured mainly on ticket closure, they may prefer
workarounds over root-cause correction.

If project teams are measured mainly on delivery date, they may
complete work that users cannot adopt.

If training teams are measured mainly on attendance, they may deliver
learning that does not change performance.

If technology teams are measured mainly on uptime, they may miss
usability problems that make the system practically unavailable to users
even while it is technically online.

The measure is not neutral.

It steers attention.

It tells people what the organisation really values.

This is why applicability must include real-world measures and
practices.

The question is not only whether the initiative achieved its internal
target.

The question is whether the target was meaningful.

Applicability Requires
Ownership

Many initiatives fail because ownership stops at delivery.

The project team delivers the system. The training team delivers the
workshop. The consultant delivers the report. The vendor delivers the
configuration. The policy team delivers the document.

Then the real world begins.

Users struggle. Customers complain. Managers create workarounds. Data
is inconsistent. Exceptions increase. The process behaves differently
from the design. The system works technically but not practically.

If ownership ends at delivery, applicability is abandoned at the
moment it matters most.

Applicable initiatives need ownership after implementation.

Who watches usage?

Who reads the signals?

Who distinguishes user error from design error?

Who works with the vendor?

Who improves the process?

Who decides whether the measure still matters?

Who protects users from being blamed for system problems?

Who ensures that learning flows back into design?

Without ownership, applicability becomes accidental.

The Discipline of
Real-World Practice

Real-world practice is untidy.

People are busy. Customers are impatient. Systems are integrated
imperfectly. Data is incomplete. Training is forgotten. Workarounds
appear. Exceptions multiply. Incentives conflict. Legacy decisions
remain in the architecture.

An initiative that works only in the controlled environment of a
slide deck, pilot group or demonstration is not enough.

Applicability asks how it works in the ordinary mess of practice.

What happens when the user is tired?

What happens when the customer is angry?

What happens when the manager has ten minutes?

What happens when data is missing?

What happens when the policy meets an exception?

What happens when the integration fails?

What happens when the person using the system was not in the
workshop?

This is not pessimism.

It is respect for reality.

Relentless Steering
Without Rigidity

To relentlessly steer applicability does not mean controlling every
detail.

It means refusing to let the initiative become detached from use.

Sometimes that requires discipline.

Sometimes it requires adaptation.

Sometimes it requires stopping a feature.

Sometimes it requires changing a measure.

Sometimes it requires simplifying a process.

Sometimes it requires adding instrumentation.

Sometimes it requires challenging a vendor.

Sometimes it requires accepting that the original idea was wrong.

Relentless steering is not stubbornness.

It is continuous alignment with reality.

The leader must keep asking whether the initiative is still useful in
the world it was meant to serve.

Conclusion

Applicability is the discipline that keeps initiatives honest.

It asks whether ideas can be used, whether systems fit practice,
whether measures reflect reality, whether signals are understood, and
whether information leads to better action.

The real measure of relevance is not how impressive an initiative
sounds.

It is whether it applies.

People give information. Systems should learn from it. Measures
should clarify rather than distort. Observability and instrumentation
should separate signal from noise. Support should not only close
tickets; it should improve the product, process or practice that created
the ticket.

This is why applicability must be steered relentlessly.

Without it, initiatives become internally complete and externally
weak.

With it, initiatives remain connected to the work, the customer, the
user, the decision and the real world.

Applicability is not the last test.

It is the discipline that should guide the development of all
initiatives from the beginning.