Microsoft’s collaboration stack breaks every rule of a modern delivery toolkit
How SharePoint will sink your project: hidden pitfalls that suck the life out of teams. It’s getting worse, not better.
This article speaks to technical delivery teams with a voice in their tooling decisions. For teams mired in SharePoint and Teams with no way out — I introduce some strategies to make things better toward the end.
Picture this: a program manager wants to confirm a design decision before a release. She asks, innocently enough, “Can someone point me at the current version of the architecture document?”
A pause. Then: “I think it’s in the Teams channel — the one from the February workshop.” Someone else chimes in, “No, there’s a newer one. Sriram emailed it last week.” A third voice: “That’s the draft. The signed-off version is in the SharePoint site. But the link in the meeting invite is broken because they restructured the folders.” A fourth: “I have a copy in OneDrive. It might be the latest, I’m not sure.”
Five people. Five different versions. Zero confidence that any of them is authoritative. And this is a team that cares about documentation.
The common denominator is always the same: a collaboration stack built on SharePoint, Teams and Microsoft’s various Office products. Sometimes with Azure DevOps (ADO) bolted on to handle tickets and code.
Here’s an argument that will sound harsh to anyone who’s invested in Microsoft 365 as their delivery platform: the Microsoft collaboration stack is diabolically deficient for serious product delivery. It wasn’t built for the problem delivery teams actually face. It has, piece by piece, gone after what enterprise IT wanted to solve in 2007: replacing the file share.
That’s not the same problem.
If you’re new, welcome to Customer Obsessed Engineering! I publish about one article each week. Free subscribers can read about half of every article, plus all of my free articles.
Anytime you’d like to read more, you can upgrade to a paid subscription.
What a delivery team actually needs
There are five table stakes a team needs. I describe the first three in Getting started: Using the Delivery Playbook. I’ll restate those briefly here, along with the other two:
1. Live collaboration. Multiple people must be able to work on the same artifact at the same time, editing simultaneously, seeing each other’s cursors, throwing virtual sticky notes on a board in real time. Design work is a collaborative act. The moment one person has to collect and collate feedback, fidelity drops off a cliff.
2. Version control. Every change, by every author, is always captured and reversible. Not just “saved revisions” — the full, granular history, searchable, with diffs, always available. This is table stakes. Git has had it for two decades. Any tool that tracks less than Git doesn’t take the goal seriously.
3. Immutable linking. A document’s URL must never change. Not when the file is renamed. Not when it’s moved to another folder. Not when the folder is reorganized. Not when the author leaves the company. A reference made today should still resolve in five years. Without this, every link in every other document becomes a ticking time bomb.
4. Workflow integration. The documentation platform has to talk, fluently and deeply, to the work-tracking platform. Specs have to link to tickets. Tickets have to link to pages. Status changes in one system should not only be visible in the other, but trigger cross-tool workflow changes and render live embeds, not stale URLs. When that integration is tight, your specs, documentation and tickets stop drifting apart — they become a single living view of the work, not several systems the team has to reconcile.
5. Universal, web-first access. One consistent experience for everyone, on any device. Not a degraded web version and a feature-rich desktop app — a single canonical surface, served through the browser, that everybody gets equally no matter what hardware they’re on.
These five criteria are the measuring stick. Let’s hold SharePoint — and Teams and ADO — up against them.
Links that rot
This is the most damning, and the one I want to spend the most time on, because it’s the one almost nobody takes seriously until they’re knee-deep in the damage.
In SharePoint, a document’s URL is a function of its name and its location in the folder hierarchy. Rename the file, and the URL changes. Move it to another folder, and the URL changes. Move the whole folder, and the URLs of every file inside it change. You can turn on “managed metadata” and “content types” and a bunch of other gears that promise to fix this, but in practice — across every tenant I’ve ever touched — they don’t. The URLs change. References break.
Microsoft has shipped “durable links” and “document IDs” — features that are off by default and rarely enabled. What a team actually encounters is: you renamed the file, the link in the meeting invite from three weeks ago is now dead. The problem is pervasive enough that a cottage industry of third-party tools has emerged just to detect broken SharePoint links.1
Compare that to Atlassian Confluence. Every page has a numeric ID assigned at creation. The ID is embedded in the URL (/pages/12345) and it does not change. You can rename the page, move it between spaces, reorganize the whole tree — the ID-based link still works. You can also use the human-readable URL (which does change when pages get renamed), but the ID-based URL is your forever-address. The system gives you both, and the tight URL is the one you automatically get when you cite the page in another document.2
This seems like a small, technical detail. It is not. It is the single most consequential design choice a documentation platform makes, because it determines whether cross-references decay or persist.
Here’s what happens in practice when links rot: people stop trusting links.
Think about that for a second. The entire promise of the web is that a URL is a durable reference — it says “here is the canonical thing, go fetch it when you need it.” That promise is what lets us build systems on top of systems. Every meeting invite, every wiki page, every code comment, every email that cites a document relies on that promise holding.
When SharePoint breaks the promise — which it does, routinely — teams develop a defensive response. They stop linking. Instead, they attach. They paste a copy of the document into the meeting notes. They email a copy to the distribution list. They download the file and re-upload it to their own folder “in case the original moves.” Multiply this by every team, every document, every month, and within a year you have a document landscape that looks like a hoarder’s basement — dozens of near-duplicates, none of them canonical, each one owned by a different person who genuinely believes theirs is the latest.
It’s rational response. Given that SharePoint links are not reliable, hoarding copies is the locally optimal strategy. However, the result is catastrophic: information silos full of stale documents and an immense toll in lost time and miscommunication.
The identity model that a platform chooses shapes the behavior of the people using it. SharePoint chose the wrong model — one that breeds inefficiency and defensive silo-building.
The version control mirage
SharePoint technically has version control. Open a file, click the ellipsis, choose “Version history,” and you’ll see a list of saves. This sounds like what you want. It is not.
The version history in SharePoint is coarse, inconsistent across product surfaces and frankly untrustworthy. Here are the problems I’ve personally run into, repeatedly:
Coauthored Office documents roll up edits from multiple people into “a version” at intervals that are not deterministic. If Alice and Bob are editing at the same time, you may end up with one version of their joint work and inaccurate attribution. Contrast with Git: every commit is atomic, attributed and reversible.
The version history for a file in OneDrive, Teams and elsewhere varies. There is no single source of truth. If you open a file with Teams, you see one history. In SharePoint, you may see a different history — a consequence of Office 365 evolving from a constellation of separately-designed products Microsoft is still trying to stitch together.3
Restoring a prior version might overwrite the current one, rather than branching. If you discover at 4pm that something important got lost at 10am, “restore” could mean losing everything done between 10am and 4pm. Until recently, this was the default behavior — so be careful.
Confluence, again, does this properly. Every save is a version. Every version compares cleanly against any other. You see what changed, who changed it and when. You can restore a prior version as a new version, preserving full history. This is how version control is supposed to work, and it has been the standard behavior in software since RCS shipped in 1982.
Why does this matter for delivery? Because design artifacts evolve, and the history of how they evolved is often as valuable as the current state. When the security auditor asks, “When did we add this API endpoint to the threat model?” — the answer lives in the diff. When a customer says, “The contract we signed described a different data retention policy,” — the answer lives in the history. When a post-mortem asks, “When did we know about this failure mode?” — the answer lives in the version log.
A platform that can’t answer these questions reliably is a platform that is actively hostile to engineering rigor.
Teams, Teams Sites and the organizing layer
If the first two failures are about individual artifacts, this one is about the landscape those artifacts live in.
Microsoft Teams is, at heart, a chat application. When it was first released in 2017, that’s primarily what it did. Over the years, Microsoft has tried to turn Teams into a “hub for teamwork.” Marketing-speak for bolting everything else Microsoft makes onto the chat app. The Files tab in a Teams channel is a SharePoint document library wearing a trenchcoat. A “Teams Site” is a SharePoint site with a slightly different navigation chrome. Meeting recordings live in OneDrive, not in the channel. Meeting transcripts live in the meeting artifact, which sometimes appears in the channel and sometimes doesn’t. Planner tasks live in a separate product surface that is also “integrated.”
If someone in your team wants to find something, they have to know, in advance, through which product surface it was shared. Was the spec posted in a channel? Check the chat history. Attached to a meeting? Check the meeting recap. Uploaded to the Files tab? That’s SharePoint under the hood, but the folder structure might only be reachable through the Teams UI. Created as a Teams Site? Different URL. Shared in a meeting chat? That goes to OneDrive, in a folder you might not have permission to browse.
There is no single “where did we put the thing” surface. There are five or six of them, depending on how the team has been using the tools, and the mapping between “what kind of content” and “which surface” is convention rather than enforced policy.
In contrast, Confluence is the document surface. Jira is the work surface. Each is a single, distinct product doing one thing well, and the integration points between them are narrow and explicit and they work. No guessing where a document lives — it’s in Confluence. Tickets live in Jira. No impedance mismatch, no cognitive dissonance.
Teams wants to be the union of every Office 365 capability. But integration isn’t about putting everything in the same UI. It’s about making the right connections between distinct tools, so that each one stays simple and focused, and the connections carry exactly the semantics you need. Teams never understood that distinction.
Desktop is king, the browser is second-class
SharePoint and the rest of Office 365 are web-accessible, but they aren’t web-first. Their heritage is Microsoft Office — a suite designed for the desktop and perfunctorily ported to the browser. The difference is not academic.
Open a Word doc in the browser and compare it to the desktop app. The feature set diverges. Advanced formatting, compare-versions, certain macro and formula capabilities, add-ins — these are missing or degraded on the web.4
The consequences cascade. “The copy you want is on my laptop” is a phrase I hear almost every week. Co-authoring gets flakey or breaks entirely because of diverging copies. Changes sit in someone’s sync queue for hours. A document that looks current in SharePoint may be stale. Information silos reappear — not because anyone intended it, but because the tool keeps pulling work off the web and onto individual machines.
Contrast with Confluence, Jira and Miro. Every one of them is web-first by design. There’s no desktop app with a superset of features. The browser is the product. Everyone gets the same experience — Windows, Mac, Linux, iPad, phone, Chromebook — because there’s only one experience to get. One canonical home, universally accessible, identical for everyone.
This is what the web was built for. Atlassian and Google stacks lean into that. Microsoft fights it.
The ADO integration gap
This one is specific to teams that pair SharePoint with Azure DevOps for their ticket tracking and code hosting. It’s a common combo, because “we already have Microsoft” is an easy procurement story, and ADO does a lot of things adequately.
But the integration between SharePoint and ADO is thin. Thin to the point of “here is a hyperlink from the work item to the SharePoint page, good luck.” There is no live embed. There is no bidirectional status update, rich preview or shared workflow trigger. If I link to a SharePoint page from an ADO work item, you see a URL. If that URL breaks, the work item becomes an orphan.
In contrast, a Jira issue in a Confluence page renders a live, interactive issue card with issue key, title, status, assignee and priority — and that card updates when the issue does. If I embed a Jira query in a Confluence page, the page shows a table of live results — as of right now. A Confluence page can be the dashboard for a delivery effort: status pulled from Jira, specs authored inline, risks tracked in a live table, all rendering from the underlying systems of record.
You can build most of this in the Microsoft stack with enough Power Automate flows, Graph API queries, custom connectors and a patient engineer. I’ve seen it attempted. I’ve yet to see it done well enough to matter. The effort required to get SharePoint + ADO to mimic what Confluence + Jira does out of the box is roughly the effort of a mid-size integration project — a project that has to be maintained, re-tested with every platform update, and reverse-engineered when the person who built it leaves the company. That’s not an integration. That’s a liability.
Workflow is an afterthought
The last failure is workflow management — specifically the modeling and enforcement of state transitions for work items.
Jira gets this right. The workflow editor is a first-class product, with a first-class visual flow designer, transition conditions, validators, post-functions, custom statuses and permission checks. A non-engineer on the delivery team can design a workflow that enforces “a ticket cannot transition from ‘In Review’ to ‘Done’ unless the code review is merged with clean quality gates, the responsible stakeholder has reviewed the feature and all acceptance criteria are passing green.” Express it in the GUI, save it, extend with code as needed and the tool enforces it across every ticket that follows that workflow. The team controls its own process — and the workflow itself is a first-class artifact: auditable, exportable, evolvable.
ADO has “process customization.” It is possible to model custom workflows. In practice the feature is buried behind an admin gate, its conditions are a shallow subset of Jira’s, and most teams I’ve worked with never meaningfully touch it. They either live with the default — generic, not their actual process — or they reinvent the enforcement in spreadsheets, PowerBI dashboards, or human oversight routines that have to be re-explained to every new hire.
The reason this matters: workflow is the mechanism by which a team’s process becomes automatic. If your workflow tool doesn’t let you encode “we agreed code reviews are mandatory before a feature branch is merged,” then code reviews are not mandatory — they’re optional, governed only by vigilance, and skipped the moment someone is under pressure. Jira’s workflow editor is a force multiplier for team discipline, because it turns “we agreed to do this” into “the tool won’t let you skip it.” ADO gives you a significantly weaker version of that lever, and most teams don’t reach for it at all.
The cost is reliability. Teams using Jira-style workflow enforcement ship with fewer process escapes — missing reviews, missed gates, skipped steps. Teams using ADO’s default setup rely on human memory and goodwill — both fail at scale. The difference shows up in incident rates, audit findings and the quality of the artifacts the team produces.
This newsletter grows by word of mouth… I’d really, truly appreciate it if you could refer a friend. Your referrals make it worthwhile.
What all this costs the team
If you’re keeping a tally, the SharePoint/Teams/ADO stack fails on every criterion. Links don’t persist. Version control is a mirage. The organizing layer is fragmented. The browser is a second-class citizen. Integrations are absent or thin. Workflow is an afterthought.
What does this actually cost a delivery team?
It costs time. A lot of it. The 2024 Stack Overflow Developer Survey (65,000 respondents) found that 61% of developers spend more than 30 minutes every day just searching for answers — and 30% say knowledge silos hit their productivity ten or more times per week.5
It costs trust. When the documentation landscape is chaotic, people stop trusting it as a source of truth. They start relying on oral tradition — “ask Alice, she knows” — and on personal copies. Key decisions stop being recorded in a place anyone can find. Onboarding becomes a six-month apprenticeship rather than a process a new hire can self-serve. Organizational memory degrades.
It costs quality. DORA's research (2022 State of DevOps Report) found that documentation quality is one of the most powerful amplifiers of engineering performance: teams with above-average documentation quality see 12.8x the organizational performance lift from the same technical practices compared to teams with poor documentation.6
It costs morale. Engineers are, as a group, unusually sensitive to tool quality. I’ve seen engineers turn down offers, quit, or burn out over the cumulative drag of bad tooling. A team that feels its own stack is working against them never reaches its potential, however talented the individuals. Tool quality is retention strategy.
Stuck with the stack? Fight back.
If you’re committed to SharePoint, Teams and ADO for the next few years, none of the above changes that. But a handful of disciplines can reduce the damage. None will turn the Microsoft stack into Confluence — they just stop the bleeding.
Here’s six specific strategies you can follow:
