Shared Responsibility When Nothing Works

Work requires a device, software, a connection and access. Under BYOD some of those belong to the employer and some to the employee, and when it stops working nobody can tell which half failed.

The practical lesson in “Shared Responsibility When Nothing Works” is to connect every record to a named decision. Organisations exploring how to identify mouse jigglers for how to detect mouse jigglers can add structured workforce context, provided the use is disclosed and interpretation is reviewed with the people affected.

Why diagnosis is the hard part

The employee sees one symptom: they cannot do their job. The cause might be the company application, the operating system, the home network, the device itself, the access configuration or a vendor outage.

For an independent reference relevant to “Shared Responsibility When Nothing Works”, consult the Apple Platform Deployment guide; compare its principles with the proposed ownership model, access rules and real support process.

Only one of those is clearly the employer's, and determining which it is requires the expertise the employer has and the employee does not.

Which is why the support note argues that the diagnosis commitment matters more than the repair commitment. Without it the employee is being asked to adjudicate a question they cannot answer.

The home network, which is nobody's

A slow or unreliable domestic connection makes work impossible and belongs to neither party in any obvious way.

The employer did not provide it. The employee did not buy it for work. And the work depends on it.

Positions that are taken: nothing, a contribution to the broadband bill, or supplying a mobile data device as a fallback. The third is the most useful and the least common, and it also solves the outage case.

The failure that nobody owns

A company application stops working on a particular operating system version on a particular device model. The vendor says it is the platform; the platform says it is the application; the employee is in the middle.

Under a managed fleet the organisation would change the configuration. Under BYOD it cannot, and the person waits.

A loan device resolves this in a day. Without one, somebody is unproductive for however long the vendor takes.

What to write down

Who diagnoses, and the commitment that diagnosis is always available.

What the employer fixes and what it does not.

What happens to the work when the cause is on the employee's side.

And a fallback route — a loan device, a borrowed machine, browser access — so that an unresolved cause does not mean an unresolved day.

The disposition that helps

Treating the problem as shared rather than as apportioned. An employee who feels the organisation is looking for a reason to say "your device, your problem" will stop reporting things and start working around them.

The arrangement depends on people telling you when something is wrong, which the loss note also argues for different reasons. Both come back to the same thing: the easier it is to report, the better the arrangement works.

Who is accountable for the whole

The arrangement splits a working system between two parties and gives neither responsibility for it functioning end to end. Naming somebody accountable for the employee being able to work, regardless of which component failed, is the organisational fix. Without it, every unclear failure becomes a negotiation at the moment somebody most needs to be working.

The fallback matters more than the diagnosis

Knowing whose fault it is does not get anybody working. A route that produces a functioning setup within the day — loan device, browser access, a borrowed machine — resolves the operational problem while the diagnosis continues at its own pace. Organisations invest heavily in the first and rarely in the second.

Making reporting easy

Every control in this collection depends on somebody telling the organisation that something is wrong, and every disincentive to reporting undermines all of them at once. A reporting route that is quick, blameless and visibly acted upon is worth more than most technical measures.

Owning the outcome rather than the component

The useful question is not whose fault it is but who is responsible for the person being able to work by this afternoon. Naming that owner resolves the stalemate that otherwise forms between a service desk that has correctly identified a device problem and an employee who still cannot do their job. When somebody cannot work and the cause is unclear, who owns the next hour?