System+Signal: A Folder Named 'Final'
There is a particular kind of organizational failure that
never makes the news.
It doesn't arrive with a breach notification or a regulatory
fine. Nobody gets fired over it. The firm doesn't lose a client—at least not in
any way that traces cleanly back to a cause. It just quietly becomes a slower,
more fragile version of itself. People work harder to accomplish the same
things. Institutional knowledge concentrates in fewer and fewer hands. And
somewhere in the background, a digital environment that was supposed to make
everything easier is doing precisely the opposite—not because it broke, but
because it was never really designed.
Most law firms and professional services businesses across
Greater Boston, the South Shore, and the MetroWest corridor are living inside
this failure right now. They just don't have a name for it.
The name, if you want one, is data without discipline.
Microsoft 365 is an extraordinary piece of infrastructure.
It handles email, documents, meetings, collaboration, storage, and
communication across devices and time zones, often without a single moment of
obvious friction. That frictionlessness is the product of years of engineering
and billions of dollars in development. It is also, quietly, the source of the
problem.
When a tool makes it easy to create, easy to share, and easy
to save work wherever you happen to be standing, it removes the small
resistances that once forced decisions. The physical filing cabinet was
inconvenient. That inconvenience had a hidden value: it made you choose. You
had to decide where something lived. You had to label it. You had to commit to
a system, however imperfect, because the alternative was chaos you could see
and touch and trip over.
Digital environments offer no such feedback. The mess is
invisible. It accumulates in silence—in the OneDrive folder nobody audits, in
the Teams channel created for a project that ended eighteen months ago, in the
SharePoint site that technically exists but that only one person knows how to
navigate. The clutter doesn't pile up on your desk. It distributes itself
quietly across a system that looks, from the outside, perfectly organized but
in reality it's a hodge-podge of nested folders with one labelled 'final'
buried deep. .
This is the central illusion of modern document management: that having the tools is the same as having a system.
The moment the illusion breaks is almost always the same.
A key person leaves. Not in scandal—just in the ordinary way
that people leave, with two weeks' notice and a handoff that everyone agrees
went well. The firm moves on. Cases continue. Clients are served.
And then, weeks later, someone needs a document.
It might be a template the firm has used for years. It might
be the research behind a brief, or the correspondence log for a matter that's
suddenly back in dispute, or the engagement letter a client is now asking
questions about. It exists—everyone is certain of this—somewhere inside
Microsoft 365. But "somewhere inside Microsoft 365" turns out to be
an address with no street number.
The template lived in that person's OneDrive, where drafts
go because OneDrive is fast and personal and always open. The research folder
was in a Teams channel, but Teams channels nest files in SharePoint, and the
SharePoint permissions were tied to that person's account in ways nobody
documented because nobody thought to ask. The correspondence log is in an email
thread, and the email thread is in an inbox that has since been deactivated,
and the backup policy—if one exists—has never actually been tested.
The data is all technically there. It just isn't, in any
functional sense, accessible.
What the firm discovers in that moment is something
uncomfortable: it has been storing information the way people store things in a
house they plan to organize someday. Everything has a location. Nothing has a
home.
In most small and mid-sized firms—the kind of practices that
anchor communities from Plymouth to Worcester to the neighborhoods just south
of Boston—data ownership follows people rather than the organization. This is
not a policy decision. It's the natural outcome of a system that defaults to
personal workspaces and individual permissions, combined with a culture that
prioritizes speed over structure. Nobody decided that critical documents would
live in one attorney's OneDrive. It just happened, one saved draft at a time,
over the course of months or years, in the ordinary course of work.
The insight that matters here is not that this is avoidable—of course it is—but that it is invisible until it isn't. The firm runs fine, right up until the moment it doesn't. And when it doesn't, the problem isn't a missing file. The problem is a missing system—and a system, unlike a file, cannot be recovered from a backup.
There is a second failure mode, quieter still, that runs
alongside the first.
It doesn't involve loss. It involves exposure.
Somewhere in the firm's Microsoft 365 environment, a file
was shared with an outside party. A client, perhaps, or a co-counsel, or a
consultant brought in for a single matter. The sharing was legitimate. The
method was the simplest available: a link that anyone with the URL could
access. It took fifteen seconds. The work got done. Everyone moved on.
That link is probably still active.
Nobody revisited it when the matter closed. Nobody set an
expiration date, because the sharing dialog didn't make expiration feel
urgent—it made it feel optional. Nobody knows, today, whether the link was
forwarded, or saved, or shared again with someone the firm never intended to
reach. The information is out there in a way that cannot be recalled, attached
to an access permission that the firm no longer controls, for a matter that is
technically resolved.
There was no breach. No incident. No violation that anyone
could point to.
And yet.
This is where the compliance conversation gets uncomfortable
for firms that believe they are doing fine. Risk in a Microsoft 365 environment
is not usually the result of a sophisticated attack. It is usually the result
of habits—small, reasonable, individually defensible habits that accumulate
into something no one designed and no one is managing. A link shared here. A
folder opened there. A permission granted because it was faster than explaining
why it shouldn't be. Over time, the firm's data has spread into configurations
that nobody can fully describe, governed by a policy that exists, if at all,
only in the vague sense that everyone knows they're supposed to be careful.
Careful is not a system.
The temptation, when firms recognize these problems, is to
reach for technical solutions. Better backup software. A new document
management platform. A security audit. A migration to a more structured
environment. These are not wrong answers—some of them are genuinely
necessary—but they tend to address the symptom rather than the condition.
The condition is the absence of what might be called data
discipline: the set of quiet, unglamorous decisions about where information
lives, who can reach it, how long it persists, and what happens to it when the
work is done.
These decisions don't require an IT department. They don't
require a new platform or a six-figure implementation project. They require
something harder to schedule: the willingness to treat information as an
organizational asset rather than a personal byproduct of work.
Every document produced in the course of serving a client
belongs to the firm, not to the person who created it. This is obvious when
stated plainly and routinely violated in practice. Files live in personal
workspaces because personal workspaces are convenient. Permissions are granted
informally because formality takes time. Structures go undocumented because
documentation feels like overhead. The result is an organization whose
institutional memory is distributed across individual habits rather than embedded
in the system itself.
When a firm finally gets this right—and many do, without
drama or enormous expense—the change is less visible than you might expect.
Files are where people think they are. New employees find what they need
without needing a guide. A partner can step away for two weeks without becoming
a single point of failure. The departure of a key employee is an inconvenience
rather than a crisis.
None of this makes headlines. It doesn't generate case
studies or conference presentations. It is simply the texture of an
organization that decided, at some point, to be less fragile.
Most businesses don't recognize their data management
problem until something breaks. A deadline missed. A document that can't be
produced. An audit that reveals access permissions nobody can explain. By then,
the instinct is to treat it as an isolated incident—a gap to be patched rather
than a symptom of something structural.
But the gap was always there. The incident just made it
visible (which is also a reason you need to regularly test your backups).
The firms that avoid these moments are not the ones with the
most sophisticated tools. They are the ones that understood, before the crisis,
that a digital environment left to grow on its own will grow in the direction
of convenience rather than coherence. And that convenience, over time, is one
of the more expensive things a firm can default to.
There is a version of Microsoft 365 that works the way it
was meant to work: where information is organized around the business rather
than around the people who happen to be there today, where access reflects
intent rather than inertia, where the departure of any single person leaves the
work intact and findable and usable.
That version isn't a different product. It's a different set
of decisions.
And for firms across Southeastern Massachusetts and Greater
Boston that are serious about running a tighter, more resilient practice—most
are one conversation away from starting to make them.
If you want a concrete place to start, we've put together
a one-page M365 Data Flow Checklist for law firms—a short, plainspoken document
designed to help you see where information enters your organization, how it
moves, and where it gets stuck. Not a compliance document. Not a technical
audit. Just a clear-eyed look at the system you already have.
