Application Sprawl and Switching Cost

Organisations accumulate applications. Each was adopted for a reason and the total is a tax nobody measures.

The friction described in “Application Sprawl and Switching Cost” becomes easier to prioritise when the team can separate active work from waiting and repeated handling. An organisation evaluating the full article can record time against the affected workflow and compare the effort before and after a change, while ticket and device records remain the evidence of the technical event itself.

For an independent benchmark, compare this approach with Atlassian IT service management resources; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.

What the count costs

Switching: every move between tools carries a re-orientation cost, and knowledge work involves a great many switches.

Duplicate entry, where two systems hold overlapping information.

Finding: knowing which tool holds what.

Notifications, each tool demanding attention on its own schedule.

Licences and administration.

And onboarding: every new starter learns the whole set.

Measuring it

Telemetry reports installed and actually used, which is the most useful single output of a platform.

Count distinct applications a typical role opens in a week.

Count tools that serve overlapping purposes — two chat systems, three places documents live, four ways to run a meeting.

The overlap count is the actionable one.

The never-opened finding

A substantial share of installed software is opened by nobody.

Removing it saves licences, reduces the attack surface and declutters the start menu.

It is also the easiest win available and a good early result for a programme that needs to show something.

Consolidating overlaps

Pick one and decommission the others, with a migration path and a date.

Expect resistance from the users of the losing tool, which is legitimate: they chose it for reasons.

Ask what those reasons are first. Frequently the winning tool can be configured to cover them, and frequently the reason is that nobody told them about the other one.

What not to do

Removing something people depend on because it looks redundant from a dashboard.

Consolidating onto the tool with the best licensing deal rather than the one that does the work.

Or announcing a decommission without a migration path, which produces shadow adoption of something worse.

The notification question

A separate and underrated friction: the number of interruptions per day from tools.

Default notification settings are set by vendors to maximise engagement.

Setting sane organisational defaults is free and has a larger effect on experience than most technical fixes.

The counter-argument

Fewer tools is not automatically better: a single tool used badly for everything is worse than three used well.

The target is overlap, not count.

Say that explicitly, because consolidation programmes measured on tool count reduce the count and the capability together.

What to check

How many applications does a typical role open in a week?

How many of your tools overlap in purpose?

What proportion of installed software is never opened?

And who sets notification defaults?

The point

The target is overlap, not count.

Consolidation programmes measured on tool count reduce the count and the capability together.

Underlying all of this

Everything in this collection reduces to four habits: find the friction cheaply before buying anything, fix what needs no budget first, report the worst tenth rather than the average, and keep the data about systems rather than about people. None requires a better platform, and a programme doing all four changes more than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the measurable is mistaken for the important. Device health stands in for experience, ticket categories for causes, a composite score for a finding. Each substitution is convenient, each produces confident decisions on thin ground, and each is corrected by going and looking at the thing itself.