Software vendors have started pitching “platforms” to everyone, including chambers and firms that neither write code nor intend to. The pitch borrows its vocabulary from PlatformOps — the way engineering organisations build and run internal platforms — and that vocabulary is worth understanding on its own terms, because it describes how well-run professional practices already manage their knowledge, just with better discipline. This FAQ translates the concept for firm partners, practice managers and knowledge-management leads, and flags the two places where it touches legal territory directly.
FAQ 1: What is PlatformOps, precisely?
PlatformOps is the discipline of running an organisation’s shared internal capability as a product. In an engineering company, that capability is the internal developer platform: the standard routes by which software gets built, released and operated. The “Ops” half is the point — the capability has an owner, published commitments, planned upgrades, defined support and scheduled retirements, rather than being a system somebody launched and everyone quietly avoids.
Professional services run an analogue already. Your precedent bank, your matter-opening workflow, your conflict-check process, your document-assembly templates: together these form an internal platform for delivering legal work. Whether anyone runs that platform — versus merely inheriting it — is usually the difference between firms where know-how compounds and firms where every partner rebuilds the same wheel at billable rates.
FAQ 2: Why are law firms suddenly hearing this term?
Two currents carry the vocabulary. Clients increasingly expect the delivery consistency that platforms provide: same quality, predictable turnaround, auditable process, regardless of which associate touches the matter. And the software industry sells to that expectation, which is why “platform” now appears in pitch decks for practice-management suites, document-automation tools and AI assistants alike. Understanding the engineering meaning gives firm leadership a filter: the term describes an operating commitment, not a feature list, and the filter separates products that embed your way of working from products that merely add a login.
FAQ 3: Is buying software the same as having a platform?
No, and the distinction matters commercially. The Cloud Native Computing Foundation’s widely used definition treats a platform as an integrated set of capabilities, assembled around what users actually need — which is why engineers insist platforms are optional and composable rather than imposed. Software marketed as “a platform” may be anything from a single-purpose app to a genuine integrated suite. Three questions cut through the marketing:
- Integrated or adjacent? Does the product connect to your other systems, or does it create another silo with another password?
- Composable or all-or-nothing? Can a practice group adopt the parts that help and decline the rest, or is it the whole suite or nothing?
- Committed or aspirational? Does the vendor publish support commitments, update cadences and a retirement policy — in writing?
The third question has sharpened recently: even major cloud vendors have retired well-funded portal products with little notice, so “who owns this roadmap and what happens when they lose interest” is now standard procurement diligence.
FAQ 4: What does a “golden path” mean for a practice?
Engineers use the phrase for the pre-built, supported route through common work: scaffold a service from a template, and pipeline, monitoring and controls appear automatically. The professional-services equivalent is the templated matter — the intake checklist, the standard document set, the precedent bundle that assembles itself for a routine engagement. Two properties make golden paths work, and both translate: the route must be genuinely faster than improvising, and it must be optional with consequences. A barrister who insists on drafting from scratch can do so; they simply cannot then bill the firm for the hours the template would have saved. Firms that enforce templates by diktat get formal compliance and silent workaround; firms whose templates deserve use get both consistency and goodwill.
FAQ 5: Who should own this in a firm?
A named person, with authority, for every significant piece of shared capability. The pattern from engineering is precise on this point: capabilities without owners decay silently, and decayed knowledge assets are worse than none because people trust them on false premises. In practice terms: someone senior enough to say no to partners who want private variants of the precedent bank, and junior enough to actually maintain it. Ownership is not a headcount decision — in a small firm it is a line in a job description and two hours a week. What it is never is ambient: “everyone keeps it updated” has the same success rate in chambers as it has in codebases.
FAQ 6: What should a small firm actually do?
Less than the vendors suggest, and earlier than feels comfortable on governance. The engineering community’s own guidance for small organisations is refreshingly modest: for a modest team, a well-kept wiki page listing your standard documents, templates and their owners can suffice — the discipline is the upkeep, not the tooling. Two structural boundaries apply at any size. First, do not build bespoke systems for needs the market already serves; the build-versus-buy arithmetic is unforgiving for organisations whose core business is practice, not software. Second, when the firm does create genuine internal assets — precedent banks, workflow automations, document templates — treat them as intellectual property: documented, attributed and protected. That is where the subject touches our own field; where an internal asset or template is copied or misappropriated, an intellectual property advocate can advise on ownership and enforcement before the informal sharing culture of the firm turns into a dispute.
FAQ 7: What is the most common PlatformOps failure mode?
Launch-and-leave, and its cousin, the mandate. Firms announce a new precedent system with a training session, then measure nothing and maintain no one. Usage decays, the workarounds return, and eighteen months later the system is cited as evidence that “templates don’t work here”. The engineering world’s post-mortems on identical failures converge on the same correctives: adoption must be pulled by genuine usefulness; every capability needs a named owner and published commitments; and something must be retired on schedule to prove the system is alive. A quarterly one-page review — what is maintained, what is best-effort, what is retired — is the entire ceremony required, and it is the piece firms most often skip.
One further risk deserves a sentence in every firm’s platform policy: centralised systems concentrate sensitive material, and the access controls around them are only as good as their weakest credential. Where client data and internal know-how share a system, a cyber crime practitioner can help allocate liability if access is abused or a breach occurs — a conversation best held before it is needed.
FAQ 8: Where does a firm start on Monday?
Three moves, none requiring budget approval. First, list the firm’s shared delivery assets — precedent bank, intake workflow, document templates, conflict process — and write an owner’s name against each; the gaps in that column are the finding. Second, pick the single asset with the highest friction and make one improvement its owner can complete in a fortnight, then measure whether associates actually use it. Third, put the quarterly one-page review in the calendar now: maintained, best-effort, retired, one line each. Firms that want a deeper template for the second step can borrow from the engineering habit of publishing service commitments — the FAQ above translates the vocabulary, and the practice translates the credibility.
FAQ 9: Where can one read the source discipline?
For the engineering original — internal developer platforms, golden paths, service levels and the operating model behind the vocabulary — the Ops Atlas entry on PlatformOps is a compact, credible starting point, and reading it before the next software pitch will change which questions you ask.
The summary for busy partners: a platform is not something you buy, it is something you run — and the disciplines that keep engineering platforms alive (named owners, published commitments, voluntary adoption, scheduled retirements) translate almost word for word to the knowledge assets on which a practice’s quality and margin depend. Firms that run those assets deliberately compound them; firms that improvise them annually are, in platform terms, rebuilding the same wheel at billable rates, and the vendors know it.
