The Departments of a Business

Why departments exist at all

A single founder can hold an entire business in their head: who the customers are, what was promised to them, what the cash position looks like, who is unhappy and why. That capacity does not scale. Once a business has more than a handful of people, three problems appear that departments are the standard answer to.

The first is specialisation. Selling to a stranger and writing reliable software are different skills, learned differently, and a person who is excellent at one is not automatically competent at the other. Grouping people by the skill they practise lets each person get better at a narrower thing, and lets the organisation hire, train and evaluate against a skill rather than against a vague notion of "helping out".

The second is accountability. When everyone does a bit of everything, a failure has no owner — the unhappy customer, the missed deadline, the wrong number in a report can be explained by pointing in several directions at once. A department with a named head and a defined remit makes it possible to ask "whose job was this" and get one answer. That is not a bureaucratic nicety; it is the mechanism by which an organisation can actually learn from its mistakes, because learning requires knowing where to look.

The third is span of control. One manager can meaningfully supervise a limited number of people — the exact number depends on how routine the work is, but it is not infinite. Past that limit, either quality of supervision degrades or the manager needs to delegate a slice of the work to someone else, which is the seed of a sub-department. Departments are, among other things, a way of keeping the management load per person survivable as headcount grows.

None of this means the divisions are natural or fixed. They are a design choice, made under constraints, and different businesses draw the lines in different places for defensible reasons — which is the subject of the next few sections.

Functional, divisional and matrix structures

A functional structure groups people by the skill or discipline they practise — all engineers report up through an engineering leader, all salespeople through a sales leader, and so on, regardless of which product or region they serve. Its strength is depth: specialists learn from other specialists, standards are consistent, and career paths are clear. Its weakness shows up when a company sells more than one product or serves more than one market — a functional structure has no natural owner for "how is product B doing", because the people working on product B are scattered across functions, each reporting to a different boss with different priorities.

A divisional structure groups people by product line, customer segment or geography instead, with each division running its own marketing, sales and sometimes engineering. Its strength is exactly what the functional model lacks: a single owner per product or market who can move fast without needing sign-off from a shared function. Its weakness is duplication — three divisions each running their own small marketing team is more expensive and less consistent than one central team, and specialists in a division tend to be more isolated from peers doing the same job elsewhere, which slows their development.

A matrix structure tries to get both: a person reports to a functional manager (say, the head of design) and also to a product or programme manager for the work they are currently doing. This can work well when both dimensions genuinely need strong representation — a large engineering organisation building several products at once is a common example. It carries a real cost, though: a person with two managers can receive two different sets of priorities, and resolving that conflict consumes real management time. Matrix structures fail in practice not because the diagram is wrong but because nobody senior enough is willing to adjudicate the conflicts the diagram guarantees will occur.

Most real organisations are not purely one of these. A company might run a functional structure for its back office and money functions — one finance team, one legal team, serving everyone — while running a divisional structure for its product lines, and a light matrix for a handful of cross-cutting programmes. The right answer for any one company is not a matter of which model is fashionable but of where coordination pain will actually be highest: coordination that has to happen constantly, at speed, should sit in one team; coordination that happens occasionally can be handled by process instead of by permanent structure.

Front office, back office and middle office

A useful cut across any organisation chart, borrowed originally from financial firms but applicable more broadly, separates three layers by their relationship to the customer and to risk.

The front office is customer-facing: marketing, sales, customer success, support. Its work is judged by revenue and customer outcomes, and it tends to be the most visible and the most rewarded part of the business when things go well.

The back office does the work that makes the front office's promises real without ever touching the customer directly: accounting, IT, HR administration, facilities. It is judged on accuracy, cost and reliability rather than growth, and it is often the first place cut when budgets tighten — sometimes wisely, sometimes at the cost of controls that only prove their worth when something goes wrong.

The middle office sits between the two, doing work that supports the front office's decisions without being customer-facing itself: risk management, compliance, treasury, some of data and analytics. It exists because certain judgement calls — how much credit to extend, whether a deal structure is compliant, how much currency exposure the business can tolerate — need a function with enough independence from the sales incentive to say no.

The value of the distinction is mainly in staffing and incentive design. A back-office role rewarded on the same growth metrics as a front-office one will quietly prioritise the wrong thing; a middle-office function that reports into the part of the business it is meant to check has had its independence removed before it starts.

What changes at different sizes

The functions described in this piece exist in some form in every business, but who does them, and how formally, changes enormously with size.

At the solo operator stage, every function above is being done by one person, badly by the standards of a specialist, but done — the founder is simultaneously marketing, selling, delivering, doing the books and answering support email. The discipline at this stage is not organisational design; it is triage, and knowing which of these jobs to do properly and which to do just well enough.

At around ten people, the first real specialisation appears. Someone becomes "the person who does the books" even if they are not a qualified accountant; someone becomes "the person who talks to customers" even if their title is something else. Departments do not yet exist, but roles are starting to differentiate, and the main organisational risk is that nothing is written down — the one person who understands how invoicing works is also the only backup for two other jobs, and their departure would be a genuine crisis.

At around a hundred people, departments become real: there are named heads of sales, of engineering, of finance, each with a small team and a budget line. This is usually where the first serious coordination problems appear too, because at ten people everyone overhears everyone else's conversations and coordination happens by osmosis; at a hundred it does not, and things that used to be obvious — what the sales team promised, what engineering is actually building — now have to be deliberately communicated, in writing, on a cadence. Many companies feel this transition as a sudden and unwelcome increase in meetings and process, and some of that increase is genuinely wasteful, but a portion of it is the organisation correctly replacing informal coordination with a formal substitute because the informal version has stopped working.

At a thousand people and beyond, sub-departments proliferate, middle management becomes its own layer with its own coordination needs, and functions that were one generalist at the hundred-person stage — data, security, internal communications — become entire departments with sub-specialities. The organisational risk shifts again: the danger is no longer that nothing is written down but that so much process exists that decisions slow to match the process rather than the actual difficulty of the decision.

Centralised versus embedded functions

A recurring design choice, once an organisation is large enough to have more than one product line or business unit, is whether a given function — design, data, legal, security — sits as one central team serving everyone, or as small teams embedded inside each business unit, or some mixture.

Centralising gets consistency, shared standards, and efficient use of scarce specialists — a small central security team can cover many product lines because most of its work does not scale linearly with the number of teams it serves. It costs responsiveness: a business unit that needs a design decision has to queue behind other units' requests to the same central team, and the central team can feel remote from the day-to-day pressures any one unit faces.

Embedding gets speed and context — the embedded designer sits with the product team, understands its customers, and can turn work around quickly. It costs consistency and depth — an embedded specialist who is the only one of their discipline on a team has no peer to learn from or be checked by, and standards drift apart across units over time.

A common compromise, sometimes called a "hub and spoke" model, keeps a central team that sets standards, provides the deepest specialists, and handles work that benefits from scale, while embedding a smaller number of generalists from that discipline inside business units for day-to-day responsiveness. It is not free of cost — it requires the central team to have genuine authority over standards even when an embedded person's day-to-day manager is someone else — but it is the shape most large organisations converge on for functions like design, data and security once the embed-everything or centralise-everything extremes have each been tried and found wanting.

The "who owns this" problem and RACI-style clarity

The single most common organisational failure is not a bad structure but an unclear one: a piece of work exists that no department is unambiguously responsible for, or — worse — that two departments both believe they own, with neither aware the other believes the same thing. Pricing is a classic example: finance believes it owns pricing because it affects margin, sales believes it owns pricing because it is negotiated in the deal, product believes it owns pricing because it reflects the value of what was built, and marketing believes it owns pricing because it appears on the website. All four have a legitimate claim, and none of them is wrong to think so — which is exactly the problem.

The standard tool for resolving this ambiguity is a RACI exercise — naming, for a given decision or piece of recurring work, who is Responsible for doing it, who is Accountable for the outcome (there should be exactly one accountable person for anything worth naming), who must be Consulted before it happens, and who merely needs to be Informed afterwards. The value of doing this exercise is not the acronym or the spreadsheet it produces; it is the conversation it forces, in which the four departments in the pricing example above have to say out loud what they each thought they owned, and someone senior enough has to decide, in writing, who actually does. Skipping the conversation and hoping the org chart resolves it by implication is how the ambiguity survives for years.

RACI-style clarity has a shelf life. A decision right allocated correctly when a company had one product and one market often stops being correct once there are three products and five markets, because the underlying question has changed shape even though its name has not. Re-running the ownership conversation deliberately, on a cadence, rather than only after a visible failure, is cheaper than waiting for the failure.

What this page is not

This page is about the organisation: the departments that exist inside a business, what each one owns, how work moves between them, how each is typically staffed and measured, and where artificial intelligence genuinely helps or falls short inside each. It is not about how to write a go-to-market strategy, a marketing plan, a sales plan, or a business plan — those are covered by sibling pages on this site, and readers looking for the content of a plan rather than the shape of the team that executes it should go there instead. Where this page discusses marketing or sales, it describes the function — its remit, its structure, its interfaces with other departments, its metrics — not the strategy it should adopt or the plan it should write. The distinction matters: a well-designed marketing department can still execute a bad marketing plan, and a brilliant plan will still fail if the department meant to run it is unclear about what it owns.

Marketing

Marketing owns awareness and demand: making sure the right people know the business exists, understand what it does, and are inclined to consider it when a relevant need arises. In most organisations it is structured around a mixture of disciplines — content, paid acquisition, product marketing, brand, events, and increasingly a data or marketing-operations function that measures the others. In a small company these are one or two generalists; in a large one they are separate teams with separate heads reporting to a chief marketing officer.

Marketing is measured, at the front end, by activity metrics — traffic, reach, engagement — and, more seriously, by how much of that activity converts into qualified pipeline that sales can act on, usually expressed as a volume of qualified leads or opportunities and a cost per one of those. The common failure mode is optimising for the metric that is easiest to move rather than the one that matters: it is far easier to generate traffic or impressions than qualified pipeline, and a marketing team under pressure to show numbers will sometimes report the former as if it were the latter.

Marketing's most important interface is with sales, and it is also the interface most likely to break. The failure has a recognisable shape: marketing hands over a lead as "qualified" using a definition sales does not agree with, sales works the lead, it goes nowhere, and each side concludes the other is bad at its job. The fix is not cleverness but agreement, written down, on what a qualified lead actually is before either side is measured against it. Marketing also interfaces with product, which supplies the substance of what is being marketed, and with communications, which shares the job of shaping how the business is perceived externally.

Where AI helps, and where it does not. AI is genuinely useful in marketing for drafting variants of copy at a pace no human team can match, summarising large volumes of customer feedback or reviews into themes, and doing early-stage audience or keyword research that a person would otherwise do manually across many tabs. It is overclaimed as a replacement for judgement about what a brand should sound like or what message will actually land with a specific audience — AI-drafted copy tends toward the generic, and a marketing team that ships it unedited produces content indistinguishable from every other business using the same tool, which defeats the purpose of a message meant to differentiate. For it to work, someone with real editorial judgement has to review and shape the output before it goes out, and the underlying facts fed into it — what the product actually does, who it is actually for — have to be current and accurate, because a fluent, confident piece of marketing copy built on a stale fact is worse than no copy at all.

Sales

Sales owns the conversion of interest into a paying commitment: qualifying who is a real prospect, running the conversation that establishes fit and value, negotiating terms, and closing. It is structured differently depending on what is being sold — a low-cost, high-volume product might have no human salespeople at all, relying on a self-serve purchase flow, while a complex, high-value sale typically has account executives supported by specialists in solutions engineering, deal desk, and sometimes a dedicated negotiation or legal-adjacent role for contract terms.

Sales is measured overwhelmingly by revenue closed against a quota, usually on a quarterly or annual cycle, and secondarily by measures of sales-cycle length and win rate. This measurement regime, while necessary, produces a predictable failure mode: a salesperson close to missing quota near the end of a period has a strong incentive to over-promise on delivery timelines or discount aggressively to close a deal now rather than well, and the cost of that decision lands on delivery, finance or customer success weeks or months later, by which time the salesperson has moved on to the next quarter's number.

Sales interfaces with marketing on the definition and handoff of qualified leads, with product on what can genuinely be promised, with legal on contract terms, and — critically, and often badly — with whichever department has to deliver on what was sold. The handoff from sales to delivery or customer success is one of the most consistently troublesome in any organisation, because the salesperson's incentives are resolved the moment the contract is signed, while the customer's experience of the business is only just beginning.

Where AI helps, and where it does not. AI is useful in sales for summarising call transcripts and extracting action items, drafting follow-up emails and proposals from a template, and flagging deals that show risk signals — long silences, stalled stages — for a manager's attention. It is overclaimed as a substitute for the relationship and trust-building that complex sales actually depend on; a prospect can generally tell when a message was generated rather than considered, and in a high-value sale that erodes exactly the trust the process is meant to build. For AI-assisted sales tooling to be worth using, the underlying customer relationship data has to be entered accurately and consistently by the sales team in the first place — a summarisation tool applied to sparse or wrong notes in the customer relationship system produces confident nonsense — and a human still has to own the actual promise made to the customer, since that promise is the thing the rest of the business is bound by.

Customer Success and Account Management

Customer success owns what happens after the sale: making sure the customer actually gets the value they were sold, renewing the relationship, and — where relevant — growing it through upsell or expansion. Account management is closely related and sometimes the same role under a different name; where they are distinguished, account management leans more toward the commercial relationship and renewal negotiation, while customer success leans more toward adoption and outcomes. In smaller companies this function may not exist separately at all, with the founder or a generalist support person filling the gap.

The function is measured by retention — how much of the existing revenue base is kept and how much is expanded, often expressed as net revenue retention — and by adoption measures specific to the product. Its most common failure mode is being under-resourced relative to sales: a business that pours effort into acquiring customers but treats keeping them as an afterthought will eventually find that its growth is entirely offset by churn, a pattern that is easy to miss quarter to quarter and devastating over a few years.

Customer success sits at the interface between sales, whose promises it has to make good on, and product, whose roadmap it should be feeding with what customers actually need. It is often the earliest and most credible source of information that a product has a real gap, precisely because its people are close enough to customers to see the gap and senior enough within the company to be believed when they report it.

Where AI helps, and where it does not. AI is useful here for spotting patterns across many accounts that a human covering a large book could not otherwise see — usage that has quietly dropped off, a cluster of accounts raising the same issue — and for drafting the routine check-in communications that a large book of accounts requires. It is overclaimed as a way to run high-value relationships without human attention; a churn-risk score is a prompt to have a conversation, not a substitute for one, and a customer who senses they are being managed entirely by an algorithm tends to conclude, correctly, that the relationship is not valued. For the pattern-spotting to be trustworthy, the underlying product usage data has to be genuinely instrumented and current, and someone has to own acting on the signal — a flagged at-risk account that nobody actually calls has produced a report, not an outcome.

Customer Support

Support owns the resolution of problems customers actually have: answering questions, fixing what is broken, and escalating what cannot be fixed at the front line. It is usually structured in tiers — a first line handling common, well-understood issues, with escalation to specialists or engineering for anything unusual — and is one of the functions most amenable to being partly self-service through documentation and automated triage.

Support is measured on speed — time to first response, time to resolution — and on customer satisfaction with the interaction. Its common failure mode is being treated as a cost centre to be minimised rather than a source of information about what is actually wrong with the product, which leads to under-staffing, long queues, and a support team that closes tickets to hit a speed metric without actually resolving the underlying problem, which then reappears as a repeat contact.

Support's most important interface is with product and engineering: a support team that surfaces the same bug or confusion repeatedly is doing free, high-quality user research, and a product organisation that does not have a working channel to receive that information is wasting it. Support also interfaces with customer success on accounts showing a pattern of unresolved frustration that puts renewal at risk.

Where AI helps, and where it does not. AI is one of the clearer wins in support today: triaging and routing incoming tickets, drafting first-pass responses to common questions for a human to review and send, and powering a self-service search or chat layer that resolves simple, well-documented issues without human involvement at all. It is overclaimed for anything outside that well-documented territory — a novel or emotionally charged issue handled by an automated system that cannot deviate from its script tends to escalate the customer's frustration rather than resolve it, and a customer who has been given a wrong or unhelpful automated answer with confidence is often worse off than one who was told honestly that a human would get back to them. For the automation to be safe, the documentation it draws on has to be accurate and current, there has to be a low-friction path to a human for anything the system is not confident about, and someone has to own reviewing where the automated layer is getting it wrong, rather than assuming a low ticket-deflection number means the system is working when it may mean customers gave up.

Partnerships and Business Development

Partnerships owns relationships with other organisations that extend the business's reach or capability without the cost of building it alone — reseller and referral relationships, technology integrations, co-marketing arrangements, and in some businesses genuine joint ventures. Business development is closely related and sometimes used interchangeably, though where distinguished it leans more toward evaluating and structuring new revenue-generating relationships of any kind, including some that look more like sales.

The function is measured by revenue or qualified reach sourced through partners, which is a harder number to pin down than direct sales revenue because attribution across an intermediary is inherently fuzzier. Its common failure mode is a portfolio of signed partnerships that produce a press release but no material revenue, because a partnership was pursued for its appearance of validation rather than because both sides had a genuine, structured incentive to make it work.

Partnerships interfaces with sales, since a partner-sourced deal usually still needs to be closed through the sales process and the two functions need clear rules for who gets credit; with legal, on the contracts that structure the relationship; and with product, when a partnership involves a technical integration that has to be built and maintained.

Where AI helps, and where it does not. AI is useful for identifying candidate partners from public information at a scale a small team could not otherwise research, and for drafting the initial outreach and partnership proposal documents. It is overclaimed as a way to manage the actual relationship, which in this function is closer to an ongoing negotiation between two organisations with imperfectly aligned incentives than to a repeatable process — the judgement calls involved in keeping a partnership productive as circumstances change do not reduce well to a pattern a system can learn. For the research use case to be reliable, someone still has to verify that a promising-looking candidate is genuinely viable before real time is invested, since a plausible-sounding partner profile generated from thin public information can be wrong in ways that only a human familiarity with the market would catch.

Product Management

Product management owns the decision of what gets built and why: translating customer needs, market opportunity and business strategy into a roadmap that engineering can execute against. It typically sits between the commercial functions, which supply demand signal, and engineering, which supplies delivery capacity, and its authority is usually more persuasive than directive — a good product manager gets a roadmap built by building consensus, not by issuing orders to an engineering team that does not report to them.

It is measured, imperfectly, by whether shipped features are actually adopted and whether the roadmap is delivered against its stated timeline, though both measures are contested — adoption can be slow for reasons unrelated to the feature's merit, and roadmap slippage is sometimes the correct response to new information rather than a failure. The common failure mode is a roadmap driven entirely by the loudest recent customer request or the most senior internal opinion, rather than by a defensible view of what will move the business forward, because product management's authority is soft and easily overridden by whoever pushes hardest.

Its interfaces are dense: with sales and customer success on what customers are actually asking for, with design on how a solution should work, with engineering on what is feasible and at what cost, and with data on what the numbers actually show about usage and demand.

Where AI helps, and where it does not. AI is useful for synthesising large volumes of customer feedback, support tickets and interview notes into candidate themes, and for drafting the specification documents that communicate a decision once it has been made. It is overclaimed as a way to decide what to build — prioritisation is fundamentally a judgement call about trade-offs the business cares about, informed by information a system can help surface but cannot itself weigh, and a roadmap generated by pattern-matching against what similar products have done tends to produce a bland, derivative plan rather than a differentiated one. For the synthesis work to be trustworthy, the underlying feedback has to be genuinely representative rather than a sample of whoever happened to be loudest, and a named product manager still has to own the resulting call and be answerable for it.

Design and UX

Design owns whether what gets built can actually be used: the workflows, layouts and visual language that determine whether a customer can accomplish what the product is meant to let them do, and whether the experience holds together across a whole product rather than as a set of disconnected screens. It usually splits into product design, focused on individual flows and interfaces, and a research function that tests whether those flows actually work for real users, though in smaller organisations one person does both.

Design is measured by usability outcomes — task completion, error rates, and findings from usability testing that get resolved rather than filed away — which are harder to reduce to a single number than a sales figure, and this makes design's contribution easy to under-value relative to more legible functions. Its common failure mode is being brought into a project too late, after the underlying decisions have already been made by product and engineering, at which point design's role shrinks to cosmetic polish rather than shaping the thing itself.

Design's interfaces are mainly with product, on what problem is being solved, and engineering, on what is actually feasible to build and at what cost — a design that looks right on screen but is prohibitively expensive to implement is not, in a practical sense, a good design.

Where AI helps, and where it does not. AI is useful for generating rapid visual variations to explore a direction, drafting the first pass of interface copy, and summarising research sessions into themes. It is overclaimed as a substitute for actually watching a real person struggle with a real interface — usability problems are frequently subtle and specific to context in ways that a system trained on general patterns will not surface, and a design produced entirely from generated suggestions without real user contact tends to look plausible while missing the actual friction users experience. For the acceleration to be worth using, someone still has to test the result with real users before shipping it broadly, and a named designer has to own the coherence of the whole experience, which a tool generating pieces in isolation cannot be responsible for.

Engineering

Engineering owns the actual construction and operation of the product: writing the software, maintaining the systems it runs on, and keeping it reliable as usage grows. It typically organises into teams aligned to a product area or a layer of the system, with a parallel discipline of platform or infrastructure engineering that maintains the shared foundation everyone else builds on, and a site-reliability or operations function focused specifically on keeping systems running under load.

It is measured on reliability — uptime, incident frequency — and on delivery — how often working software reaches production, and how many defects escape into it. The common failure mode is the accumulation of technical debt: shortcuts taken under deadline pressure that make the system harder to change later, which is invisible in any short-term metric and only shows up, expensively, months or years afterward when a seemingly simple change takes far longer than it should.

Engineering's interfaces are with product, on what to build, with design, on how it should work, and with security, on whether what is built is safe — a relationship that works best when security is involved early rather than as a gate at the end that finds problems too late and too expensively to fix cleanly.

Where AI helps, and where it does not. This is one of the areas where AI assistance is most mature: generating draft code from a specification, suggesting fixes for well-understood bugs, writing routine tests, and explaining unfamiliar code to a developer working in it for the first time. It is overclaimed as a way to remove the need for experienced engineering judgement — generated code can be fluent and syntactically correct while containing subtle logical errors, security weaknesses, or architectural choices that will not scale, and a team that ships such code without genuine review is trading a slower, visible cost for a faster, invisible one. For the acceleration to be safe, the codebase's existing tests and review process have to actually be rigorous enough to catch what the tool gets wrong, and a named engineer has to take responsibility for what is merged, in the same way they would for code they wrote themselves — "the tool suggested it" is not an acceptable answer when something breaks in production.

Data and Analytics

This function owns turning what happens in the business into something that can be measured and reasoned about: building the pipelines that collect and clean data, the reporting that makes it visible, and increasingly the more advanced modelling that predicts or classifies. It typically splits into data engineering, which builds and maintains the pipelines and infrastructure, and analytics or data science, which uses that infrastructure to answer specific business questions.

It is measured less by a single output metric than by whether decisions across the business are actually being made with reliable data behind them, and by the underlying quality of that data — its completeness, accuracy and timeliness. The common failure mode is investing heavily in dashboards and models while the underlying data feeding them is inconsistent or wrong, producing outputs that look authoritative and are not, which is arguably worse than having no data function at all because it creates false confidence.

Data's interfaces reach almost every other department, since every function increasingly wants its own reporting and its own models, which makes prioritisation — whose request gets served first — one of this function's genuine and recurring management problems.

Where AI helps, and where it does not. AI is useful for accelerating exploratory analysis, drafting queries from a plain-language question, and detecting anomalies in a data stream that a human monitoring it manually would likely miss. It is overclaimed as a substitute for the unglamorous work of establishing what the data actually means and whether it can be trusted — a model built on data with an unrecognised bias or gap will produce fluent, wrong answers with the same confidence as fluent, right ones, and there is no way to tell the difference from the output alone. For any of this to be safe, the underlying data quality work has to happen first and continuously, and a named person has to own validating a model's outputs against reality before decisions are made on them, rather than treating a plausible-looking number as settled fact.

IT and Internal Systems

IT owns the tools and infrastructure that the rest of the organisation depends on to do its own job: laptops, internal software, networks, and the systems that keep people able to work at all. In a small company this might be one contractor; in a larger one it is a full department with sub-specialities in service desk, systems administration, and the procurement of internal software.

It is measured on uptime and on how quickly reported problems get resolved, both of which are unglamorous but genuinely consequential — a business where email or the core internal system is frequently down loses productivity in a way that rarely shows up cleanly in any other department's metrics, which makes IT easy to under-invest in until a failure makes the cost visible all at once.

IT's interfaces are broad but mostly reactive — it serves every other department's requests — with a particularly important relationship to security, since much of what IT manages (devices, access, networks) is also the surface security has to defend.

Where AI helps, and where it does not. AI is useful for triaging and routing help-desk tickets, drafting first-pass responses to common requests, and detecting unusual patterns in system usage that might indicate a problem forming. It is overclaimed as a way to eliminate the service desk entirely — many IT requests involve context specific to one person's setup that a general system has no way to know, and an automated response that misses that context wastes more time than it saves by sending the person down the wrong path. For the automation to help rather than frustrate, there has to be a fast, easy path to an actual person when the automated response does not fit, and someone has to be reviewing where the automated layer is failing rather than assuming silence means success.

Information Security

Security owns the question of whether someone could break in, steal data, or disrupt operations, and whether the business would know if they tried. It typically covers a mix of defensive engineering (hardening systems), detection and response (watching for and reacting to incidents), and governance (setting the policies everyone else is expected to follow).

It is measured by incidents detected and how quickly vulnerabilities are patched once known, both of which are awkward metrics because the function's real success — the attack that never happened — is invisible by definition, which makes security, like IT, chronically vulnerable to being under-resourced during good times and then scrambled for during a crisis.

Security's interfaces reach engineering, where it needs to be involved early rather than as a late gate, IT, whose infrastructure it depends on and helps protect, and increasingly compliance, since a growing share of security's requirements now come from external regulation rather than internal judgement alone.

Where AI helps, and where it does not. AI is genuinely useful for triaging the very large volume of security alerts most systems generate, most of which are false positives, and for spotting patterns across logs that a human reviewing them manually would not have the throughput to catch. It is overclaimed as a way to automate the response to a genuine incident — the decisions involved in containing an actual breach (what to isolate, what to disclose, in what order, to whom) carry legal and reputational weight that has to sit with an accountable human, and an automated system acting on an incident without review risks making the situation worse, for instance by isolating a system in a way that destroys evidence needed later. Security is also a domain where the attacking side is actively using the same class of tools to generate more convincing phishing and social-engineering attempts, which means the function has to defend against AI-assisted attacks even as it adopts AI-assisted defence — a genuinely two-sided arms race rather than a one-directional productivity gain. For the detection tools to be trustworthy, they need continuous tuning against the organisation's actual environment, and a named, on-call human has to own the decision to act on any serious alert.

Finance: FP&A versus Accounting

Financial planning and analysis (FP&A) owns forward-looking questions: what will happen to cash, revenue and margin under a given plan, and what a proposed decision — a new hire, a new market, a pricing change — would do to those numbers. It is forecasting and modelling work, forward-facing and inherently uncertain, distinct from accounting's job of recording what has already happened. In a small company one person, sometimes the founder, does both; in a larger one FP&A is a distinct team reporting to a chief financial officer, working closely with but organisationally separate from the accounting team.

FP&A is measured on forecast accuracy and on how closely actual spending tracks the budget it set. Its common failure mode is a forecast that is technically sophisticated but built on assumptions nobody outside finance actually agreed to, so that when reality diverges from it — as it usually does — the business discovers the disagreement only after the fact, at the point of maximum cost.

FP&A's interfaces reach every department that spends money, since its forecast is only as good as the assumptions fed into it by sales about pipeline, by product about delivery timing, and by operations about cost. A forecast built in isolation from those inputs is a finance team's fiction, however well modelled.

Where AI helps, and where it does not. AI is useful for building and stress-testing scenarios quickly once the underlying assumptions are agreed, and for summarising variance between forecast and actuals into plain language a non-finance audience can follow. It is overclaimed as a way to produce a trustworthy forecast without the underlying business conversation about assumptions — a model can extrapolate a trend with great technical polish while being wrong about the one thing that actually matters, which is whether the assumption behind the trend still holds. This is a domain where a confidently wrong number is genuinely costly, since decisions about hiring and spending get made on the strength of it: nothing here should be treated as financial advice, and any forecast or model that will inform a material decision should be reviewed by a qualified finance professional before it is acted on, with AI used to accelerate the mechanics of the analysis, never to substitute for that review.

Accounting and Bookkeeping

Accounting owns the historical record: recording transactions accurately, closing the books on a regular cycle, and producing financial statements that are correct and, where required, auditable. It is one of the oldest and most standardised business functions, governed by established accounting principles that leave comparatively little room for the informal judgement calls more common elsewhere in a business.

It is measured by how quickly the books close each period and by the absence of findings when the records are reviewed or audited. Its common failure mode, especially in smaller businesses, is treating bookkeeping as an afterthought handled sporadically rather than continuously, which produces a backlog that makes the eventual close slower, more error-prone, and harder to trust.

Accounting's interfaces reach every department that generates a transaction — sales contracts, procurement purchases, payroll from HR — and its accuracy depends entirely on those other departments providing correct and timely information, which makes accounting one of the clearest examples of a function whose output quality is capped by inputs it does not control.

Where AI helps, and where it does not. AI is genuinely useful for categorising transactions, reconciling records against bank statements, and flagging entries that look anomalous against historical patterns for a human to check. It is overclaimed as a replacement for a qualified accountant's judgement on anything involving genuine ambiguity — how to treat an unusual transaction, what a particular accounting standard requires in an edge case — where getting it wrong has real consequences for tax filings, audits and legal standing. This is not a domain for improvisation: nothing here should be read as accounting or tax advice, and a qualified accountant should review anything that will appear in a filed financial statement or a tax return, with automation used for the volume work of categorisation and reconciliation, subject to that professional's sign-off.

Treasury

Treasury owns cash and financial risk at the level of the whole organisation: making sure cash is available where and when it is needed, managing banking relationships, and — in businesses that operate across currencies or borrow money — managing foreign exchange and interest rate exposure. In a small company this is a sliver of the founder's or finance lead's attention; in a large one it is a distinct team with real technical specialism.

It is measured by liquidity headroom — is there enough cash available to meet obligations with a margin for the unexpected — and by the cost of whatever capital the business uses. Its common failure mode is being invisible until it fails: a business can run for years without treasury discipline mattering, until a cash crunch or a currency move that was not hedged suddenly makes it matter a great deal, at which point the lack of preparation is expensive and hard to reverse quickly.

Treasury's interfaces are mainly with FP&A, whose forecast it needs to plan liquidity against, and with any department signing contracts with currency or payment-timing implications.

Where AI helps, and where it does not. AI can help with monitoring cash positions across many accounts and flagging deviations from expected patterns, and with modelling the effect of different scenarios on liquidity. It is overclaimed as a way to automate treasury decisions themselves — decisions about hedging, borrowing or moving cash carry real financial risk and often legal and counterparty considerations that a qualified treasury or finance professional needs to weigh; this is another area where the cost of a confidently wrong automated suggestion is high enough that professional judgement, not automation, should make the actual call.

Procurement and Vendor Management

Procurement owns how the business buys things: selecting vendors, negotiating terms, and managing the ongoing relationship and performance of suppliers the business depends on. In a small company this is handled ad hoc by whoever needs the thing being bought; in a larger one it is a dedicated function with negotiating leverage and standard processes for vendor evaluation.

It is measured on cost savings achieved and on vendor performance against agreed terms. Its common failure mode is optimising purely for the lowest price on a given purchase while under-weighting the total cost and risk of a vendor relationship that turns out to be unreliable, badly supported, or difficult to exit — the cheapest option is not always the cheapest once the full relationship is accounted for.

Procurement's interfaces reach whichever department is requesting a purchase, and, increasingly, security and compliance, since a new vendor — especially one handling data — often needs a security and compliance review before a contract is signed, a step that is easy to skip under time pressure and expensive to regret later.

Where AI helps, and where it does not. AI is useful for summarising vendor proposals and contracts to surface key terms quickly, and for benchmarking a quoted price or set of terms against what the market or the organisation's own history suggests is reasonable. It is overclaimed as a substitute for actually vetting a vendor's reliability and security posture, which usually requires direct verification — references, audits, direct questions — that a summarisation tool cannot perform on its own. For the summarisation to be safe rather than misleading, someone still has to read the actual contract before signing it, since a summary that omits one unfavourable clause because it seemed minor can be the clause that matters most later.

Legal

Legal owns identifying and managing the business's exposure: drafting and reviewing contracts, advising on regulatory questions, handling disputes, and protecting intellectual property. In a small company this is typically an external law firm engaged as needed; in a larger one there is an in-house team, often still supplemented by outside counsel for specialised or high-stakes matters.

It is measured on contract turnaround time and on disputes avoided or resolved favourably, both somewhat awkward metrics because legal's best work is often invisible — the dispute that never happened because a contract term was correctly negotiated in advance leaves no trace to point to. Its common failure mode is being brought in too late, after a deal or decision has already been effectively made, at which point legal's role narrows to damage control rather than shaping the decision itself.

Legal's interfaces reach nearly every department — sales on contract terms, HR on employment matters, product on intellectual property and regulatory questions, security on incident response and disclosure obligations — which makes it one of the busiest cross-cutting functions in any organisation past a certain size.

Where AI helps, and where it does not. AI is useful for a first-pass review of routine contracts against a standard playbook, flagging clauses that deviate from what the business normally accepts, and summarising lengthy documents to orient a lawyer before they read the full text. It is overclaimed as a substitute for actual legal advice — the interpretation of how a law or regulation applies to a specific, novel situation is exactly the kind of judgement call where a fluent, wrong answer is dangerous precisely because it sounds authoritative, and legal obligations vary by jurisdiction in ways a general-purpose tool cannot be assumed to know precisely or currently. Nothing in this document, or in any AI-generated draft, should be treated as legal advice; qualified counsel should review anything with real legal consequence, and the tools here should be understood as accelerating the paperwork of legal work, not replacing the professional judgement behind it.

Compliance and Risk

Compliance owns making sure the business operates within the rules that apply to it — industry-specific regulation, data protection law, financial reporting requirements — and risk management more broadly owns identifying and mitigating the things that could seriously damage the business, whether or not they are governed by an explicit rule. In a small company this is often folded into legal or finance; in a regulated industry it is frequently one of the largest functions in the company.

It is measured by findings closed and, most seriously, by the absence of regulatory incidents. Its common failure mode is treating compliance as a box-ticking exercise disconnected from how the business actually operates, producing policies that look complete on paper and are routinely ignored in practice because they were never designed with real workflows in mind.

Compliance's interfaces reach nearly everywhere a regulated activity happens — finance on financial reporting rules, HR on employment law, security on data protection, product on any regulated feature — and its authority depends heavily on genuine senior backing, since a compliance team without the standing to say no to a profitable but risky decision is not actually performing its function.

Where AI helps, and where it does not. AI is useful for monitoring large volumes of communications or transactions for patterns that match known risk indicators, and for keeping track of regulatory obligations across multiple jurisdictions, which is a genuinely large volume problem for any business operating in more than a few. It is overclaimed as a source of compliance judgement itself — whether a specific situation actually violates a specific regulation is a legal question that depends on precise facts and current law, and a wrong answer here can carry serious regulatory and legal consequences. This is squarely a domain where professional advice is required rather than optional: AI tools can help surface what needs review, but a qualified compliance or legal professional must make the actual determination, and the organisation needs a clear, human accountability chain for every compliance decision that could plausibly be scrutinised later.

Internal Audit

Internal audit owns checking whether the organisation's controls — the processes meant to prevent error, fraud or regulatory breach — actually work as designed, independent of the departments being checked. It typically reports to an audit committee or the board rather than to management, specifically so that its findings are not filtered by the people whose work is being reviewed.

It is measured by control failures found and by how thoroughly they are remediated once identified, a metric that rewards honest, rigorous discovery rather than a clean-looking report, which is a genuinely unusual incentive structure compared to most departments covered in this piece.

Internal audit's interfaces reach every department it reviews, and its independence is the whole point — an audit function that reports into the operations it audits, or whose findings can be quietly softened by the department under review, has had its usefulness removed regardless of how the org chart labels it.

Where AI helps, and where it does not. AI is useful for sampling and reviewing large volumes of transactions or records for patterns that suggest a control is not working as intended, at a scale a manual sample-based audit would not otherwise reach. It is overclaimed as a way to certify that a control is sound — the judgement about whether a detected anomaly represents a genuine control failure, an acceptable exception, or a false signal is precisely the kind of contextual call a qualified auditor has to make, and an audit function that outsources that judgement to a tool has stopped being independent in the sense that matters, because it has deferred the actual finding to something nobody in the room can be held accountable for. For AI-assisted sampling to be worth using, its outputs need to be treated as leads for a human auditor to investigate, not as findings in themselves.

Human Resources and People Operations

HR owns the health of the employment relationship at scale: policy, employee relations, benefits administration, and increasingly a broader "people operations" remit focused on making the day-to-day experience of working at the company function well. In a small company this is a part-time responsibility of a founder or office manager; in a larger one it is a full department with specialised sub-functions.

It is measured on engagement, attrition, and how quickly employee issues get resolved, all of which are lagging and somewhat soft indicators — a serious problem can be brewing for months before it shows up in any of these numbers. Its common failure mode is being treated purely as an administrative function handling paperwork, disconnected from the strategic conversations about headcount and organisational design that actually determine what HR will later be asked to administer.

HR's interfaces reach every department, since every department has people in it, and its most delicate interface is with legal, on anything involving discipline, termination, or a workplace dispute, where the two functions need to work closely and the sequencing of who is consulted when genuinely matters.

Where AI helps, and where it does not. AI is useful for summarising employee survey results into themes, drafting routine policy communications, and helping HR teams keep track of a large and complex set of compliance obligations that vary by location. It is overclaimed, and should be approached with real caution, anywhere it touches decisions about individual people — performance assessment, disciplinary matters, and anything that could disproportionately affect people of a particular background carries genuine risk of embedding bias that is hard to detect from the output alone, and several jurisdictions now specifically regulate the use of automated tools in employment decisions. Nothing here should be read as employment law advice, and any use of an automated tool that materially affects an individual employee's treatment should be reviewed by qualified HR and legal professionals, with a named human accountable for the decision and able to explain the basis for it if challenged.

Talent Acquisition

Talent acquisition owns hiring: sourcing candidates, running the interview and selection process, and closing offers. In a small company this is done by whoever is hiring at the time; in a larger one it is a dedicated recruiting function, sometimes with specialists by role type or seniority.

It is measured on time to fill open roles and, more importantly if harder to measure well, on the quality of the people actually hired, judged retrospectively by how they perform once in the role. Its common failure mode is optimising for speed to the detriment of fit, filling a role quickly with someone who does not work out, which costs far more in the medium term than the time saved in the short term.

Talent acquisition's interfaces are with the hiring manager in whichever department has the open role, and with HR on offer terms and onboarding.

Where AI helps, and where it does not. AI is useful for drafting job descriptions, doing an initial pass of resume screening against clearly defined criteria, and scheduling the logistics of an interview process. It should be approached with particular caution in candidate screening and assessment: automated screening tools have a documented history of encoding and amplifying bias present in historical hiring data — for instance systematically disadvantaging candidates by gender, ethnicity, age or disability where the training data reflected past patterns of who was hired — and this is an area of active regulatory attention in a number of jurisdictions, with some explicitly requiring disclosure or audit of automated hiring tools. For an AI-assisted screening step to be used responsibly, the criteria it screens against need to be defined and justified independently of the tool, its outcomes need to be regularly audited for disparate impact across protected characteristics, a human needs to review edge cases and any rejection the tool would produce, and the organisation needs to be able to explain, to a regulator or a candidate, why a particular decision was made. This is a domain where the honest answer is often that a qualified employment lawyer should be consulted before deploying automated screening at all, not after a problem surfaces.

Learning and Development

L&D owns building the capability of the existing workforce: onboarding, skills training, and leadership development. In a small company there is essentially no dedicated function and learning happens informally; in a larger one it is a distinct team, sometimes reporting into HR and sometimes standing alone.

It is measured by completion rates of training programmes and, where done well, by actual capability assessments rather than mere attendance. Its common failure mode is producing training that is completed to satisfy a compliance requirement without changing what anyone actually does differently afterward, which is a widely recognised problem in the field and a reason many training investments show disappointing returns.

L&D's interfaces are with every department it trains, and with talent acquisition on defining what skills the organisation needs to build internally versus hire for externally.

Where AI helps, and where it does not. AI is useful for generating first drafts of training material, personalising the pace or sequence of a learning path to an individual's demonstrated gaps, and answering routine questions during onboarding. It is overclaimed as a substitute for the harder work of actually changing behaviour, which usually requires practice, feedback and reinforcement over time that a generated module alone does not provide — a well-produced automated course can be completed in full and change nothing about how someone does their job the next day. For it to genuinely build capability, the content still needs a subject-matter expert's review for accuracy, and the organisation needs a way of checking, beyond completion, whether the training actually changed observable behaviour or output.

Operations

Operations is the broadest and least precisely defined function on this list, and its exact scope varies more by company than any other — in general it owns making the day-to-day machine of the business run smoothly, covering whatever cross-cutting execution work does not have a more specific home elsewhere. In a services business this might mean scheduling and resource allocation; in a physical goods business it overlaps heavily with supply chain and manufacturing, covered separately below.

It is measured on throughput and cost per unit of output, adapted to whatever the business actually produces. Its common failure mode is scope creep in the opposite direction from most other functions — because operations' remit is defined by exclusion, it tends to accumulate whatever nobody else clearly owns, which can leave it stretched across too many unrelated responsibilities to do any of them particularly well.

Operations' interfaces are wide by nature, touching whichever function is generating the day-to-day work it coordinates.

Where AI helps, and where it does not. AI is useful for forecasting demand and resource needs from historical patterns, and for optimising scheduling and routing problems that have a large number of variables a human would struggle to weigh simultaneously. It is overclaimed as a way to handle genuine exceptions — real operations are full of one-off disruptions (a key supplier's sudden failure, an unusual customer request) that a system trained on historical patterns has, by definition, not seen before, and an operations team that over-relies on an optimisation tool for the routine case can be caught flat-footed by the exception it was never built to handle. For the optimisation to be trustworthy, someone needs to understand roughly how it reaches its recommendations well enough to sanity-check them, rather than treating the output as beyond question because it came from a system.

Supply Chain and Logistics

This function owns the physical movement of goods: sourcing materials or products, managing inventory, and getting things to where they need to be on time. It is a substantial and specialised function in any business that deals in physical goods, and largely absent in pure services businesses.

It is measured on-time delivery and inventory turns — how efficiently stock moves rather than sitting as unproductive cost. Its common failure mode is optimising too aggressively for low inventory in normal times, which leaves no buffer against the disruptions that periodically and predictably occur, turning a minor supply hiccup into a major stockout.

Its interfaces are with sales and demand planning, on what needs to be available and when, and with procurement, on sourcing terms.

Where AI helps, and where it does not. AI is useful for demand forecasting from historical sales and seasonal patterns, and for optimising routing and warehouse layout. It is overclaimed as a way to handle genuinely novel disruption — a model trained on years of stable historical patterns has no basis for anticipating an event outside that history, and supply chains are recurrently disrupted by exactly such events. For forecasting tools to be worth using, the organisation needs a deliberate process for recognising when current conditions have departed from the historical pattern the model was trained on, and a human with real judgement needs to own the response when they have.

Manufacturing or Service Delivery

This function owns actually producing what the business sells, to a defined standard, whether that is a physical product coming off a line or a service being delivered to a client. Its internal structure varies enormously by industry, but its core responsibility is consistent: turning inputs into the thing the customer was promised, reliably.

It is measured by yield and defect rate in manufacturing, or service level and consistency in a delivery context. Its common failure mode is a quality problem that goes undetected until it reaches the customer, because the checks that would have caught it earlier were skipped or under-resourced, usually under cost or schedule pressure.

Its interfaces are with supply chain on inputs, with sales on what was promised, and with quality or compliance functions on the standards it must meet.

Where AI helps, and where it does not. AI is useful in manufacturing contexts for visual inspection systems that flag likely defects for human confirmation, and in service delivery for checking output against a defined quality standard at a consistency a purely manual review might not sustain over a long shift. It is overclaimed as a way to remove human inspection entirely — an automated inspection system trained on known defect patterns can miss a genuinely novel failure mode, and a business that removes its human backstop on the strength of a system's historical accuracy is exposed exactly when something unprecedented occurs. For the automation to be trustworthy, its error rate needs to be actually measured against ground truth on an ongoing basis, not assumed from initial testing, and a human review step needs to remain in place for anything the system flags as borderline.

Facilities and Workplace

Facilities owns the physical (and increasingly virtual) workplace: office space, equipment, safety, and the practical infrastructure that lets people actually do their work. In a distributed or remote-first company this function shrinks in physical scope but does not disappear — it becomes more about the tools and stipends that support a home working environment.

It is measured on cost per seat and on the rate of safety or facilities-related incidents. Its common failure mode is being cut to a bare minimum during cost pressure in ways that are individually small but collectively degrade the day-to-day experience of work, a form of cost saving that rarely shows up as a line item worth defending but is felt by everyone.

Its interfaces are with IT, since much of the modern workplace is a mix of physical and digital infrastructure, and with HR on the overall employee experience.

Where AI helps, and where it does not. AI is useful for predictive maintenance — flagging equipment likely to fail before it does, based on usage patterns — and for optimising space utilisation from occupancy data. It is overclaimed for anything involving genuine safety judgement, where the cost of a missed signal is a person being hurt, and automated systems here should be treated as one input to a human safety process, never as the process itself. For predictive maintenance to be worth the investment, the underlying sensor data needs to be reliable, and there needs to be a clear, resourced process for actually acting on a flagged prediction rather than letting it sit in a dashboard.

Communications and Public Relations

Communications owns how the business is perceived externally and how it speaks with one voice — media relations, public statements, crisis response, and often internal communications as well, ensuring employees hear important news accurately and on time rather than through rumour. In a small company this is an occasional responsibility of a founder; in a larger one, especially a public-facing or regulated one, it is a specialised and senior function.

It is measured on the quality and accuracy of media coverage and on the consistency of the business's messaging across channels, both of which are judgement-based rather than cleanly numeric. Its common failure mode is being excluded from a decision until it is already public, at which point communications' job shrinks to reactive damage control rather than shaping how the news is understood from the outset.

Its interfaces reach leadership broadly, and specifically legal, since a public statement can carry legal exposure, and HR, on internal communications about sensitive workforce matters.

Where AI helps, and where it does not. AI is useful for drafting first versions of routine communications and for monitoring media and social coverage at a volume a small team could not track manually. It is overclaimed for crisis communication specifically, where tone, timing and precise wording carry consequences that a generated draft, however fluent, has no way of weighing — a genuine crisis statement needs a senior human who understands the full, often politically sensitive context to approve every word before it goes out. For routine communications, a human still needs to check factual accuracy in any generated draft, since a fluent but factually wrong public statement can cause exactly the kind of reputational harm the function exists to prevent.

How work actually crosses departmental lines

Every department section above named its interfaces individually; it is worth looking at the pattern across all of them together, because the same failure shape recurs with remarkable consistency. A handoff breaks when the sending department's definition of "done" does not match the receiving department's definition of "ready" — marketing calls a lead qualified by a criterion sales does not accept; sales calls a deal closed on terms delivery cannot actually meet; support calls an issue a "known bug" that product has not actually triaged or prioritised; finance calls a forecast final before the departments whose numbers feed it have actually confirmed their assumptions. In every case, the breakage is not really about competence in either department — it is about two departments operating on different, unstated definitions of the same word.

The fix, boringly, is the same in every case: an explicit, written definition of the handoff criteria, agreed by both sides before either is measured against it, revisited when either side's circumstances change enough that the old definition stops fitting. This is unglamorous work and it is chronically under-invested in, because building the thing on either side of the handoff feels more like real progress than agreeing on the definition between them — which is exactly why the same handoffs keep breaking in organisation after organisation, regardless of how good the individual departments are.

The shared data layer and why department-by-department AI stalls

A pattern visible across nearly every department section above is that AI tools work well when they operate on data that is accurate, current, and genuinely representative, and produce confident nonsense when they do not. Taken individually, each department's data quality problem looks like that department's problem to fix. Taken together, a more important pattern emerges: the same customer, the same product usage, the same transaction, is recorded slightly differently in the sales system, the support system, the product analytics system and the finance system, and no single department has the authority or the incentive to reconcile the differences.

This is why many organisations find that AI adoption inside one department — a support chatbot, a sales-summary tool, a finance-forecasting model — delivers a real but modest improvement, while the larger promise of an organisation-wide AI-assisted view of the business stalls. The tools are not the constraint; the absence of a shared, reconciled view of the underlying facts is. Building that shared layer — a genuinely unified, trustworthy record of the customer, the product and the transaction that every department's tools can draw on — is unglamorous infrastructure work, usually owned jointly by data and IT, and it is a prerequisite for cross-department AI use cases in a way that is easy to underestimate until an organisation tries to build one of those use cases and discovers the data underneath cannot support it.

Process ownership and internal service levels

A department chart names who owns which function; it does not by itself name who owns an end-to-end process that crosses several functions — order-to-cash, hire-to-retire, procure-to-pay, and similar chains that pass through many hands. Without an explicit process owner, each department optimises its own segment of the process without anyone accountable for the whole, and the total experience — how long it actually takes a customer to go from signing a contract to receiving working service, say — can be poor even when every individual department hits its own metric.

Some organisations address this by naming an explicit process owner, separate from any single department head, whose job is the end-to-end metric rather than any one segment of it, and who has the standing to ask each department to change how it does its segment in service of the whole. Others use internal service-level agreements between departments — a defined, agreed standard for how quickly one department will respond to a request from another — as a lighter-weight substitute. Either approach requires the same underlying willingness that a RACI exercise requires: naming, explicitly, that a gap exists and that someone specific is going to be accountable for closing it, rather than hoping the sum of well-run departments adds up to a well-run process.

Shared-services and centres of excellence

Building on the centralised-versus-embedded discussion in part one, larger organisations often formalise a hybrid as a "shared services" function — a central team that provides a common service (payroll processing, a help desk, standard contract templates) to every business unit under a service-level agreement, freeing individual units from duplicating that capability themselves. A related but distinct pattern, a "centre of excellence", is less about executing routine transactional work and more about holding and disseminating deep expertise in a discipline — setting standards, training others, and handling the hardest cases personally, while day-to-day execution stays embedded in the business units.

Both patterns aim at the same goal as the hub-and-spoke model discussed earlier: capturing the efficiency and consistency of centralisation without losing all the responsiveness of embedding. Both also carry the same risk, that the central function becomes a bottleneck if it is under-resourced relative to the demand every business unit places on it, and both require genuine, ongoing negotiation about scope — which decisions the centre makes, which it merely advises on, and which are left entirely to the business unit.

What an "AI-assisted organisation" plausibly looks like

Set against how AI is often marketed — as something close to an autonomous replacement for entire functions — the pattern across every department examined above is more modest and more specific. In every function, the tools are currently strongest at drafting, summarising, classifying and flagging: producing a first version of something, condensing a large volume of material into a form a person can act on quickly, sorting items into categories, or surfacing an anomaly for attention. In no function examined here is an unsupervised AI decision, made without a named accountable human reviewing it, currently a sound practice — and in the money, legal, compliance and hiring functions specifically, it is not merely unwise but potentially unlawful or professionally negligent, which is why those sections above are written with explicit caution and pointers to professional advice.

A plausible, sober description of an "AI-assisted organisation" today, then, is one where most departments have adopted tools that speed up their most repetitive drafting and summarising work, where a smaller number of well-instrumented departments (support, and parts of engineering and data) have gone further into semi-automated classification and routing, and where every one of those uses sits behind a named human who is accountable for the output and who reviews it before it has a consequence outside the tool. That is a real and valuable state to reach. It is considerably less dramatic than the version often described in vendor marketing, and readers should be sceptical of any claim, including implicitly this one, that goes further than the evidence in a given function actually supports.

Where a system may act versus where it may only draft

A useful discipline, applicable in any department, is to be explicit about which of two modes a given AI use case sits in. In the draft mode, the system produces an output — a piece of text, a categorisation, a recommendation — that a human reviews and decides whether to use, and nothing happens in the world until that human acts. In the act mode, the system's output directly causes something to happen — an email is sent, a ticket is closed, a transaction is processed — without a human in the loop at the moment it happens.

The two modes carry very different risk profiles, and the sections above show a consistent pattern: draft mode is broadly safe to expand once the underlying data quality is good enough, because a human remains the last check before any consequence occurs. Act mode is only safe in narrow, well-bounded, low-stakes situations — a self-service support answer to a well-documented question, a routed ticket, an automatically flagged anomaly — and becomes progressively riskier as the stakes of getting it wrong rise, which is exactly why act-mode automation is more mature in support and IT than in finance, legal or hiring. An organisation designing a new AI use case should be able to say, explicitly, which mode it is building, and should not let a use case drift from draft into act without a deliberate decision to accept the higher risk that shift carries.

Governance, audit trails, and accountability

Every department section above named a human who has to remain accountable for an AI-assisted output. That accountability is only real if it is possible, after the fact, to reconstruct what happened: what the system was given, what it produced, who reviewed it, and what they decided. Without that trail, "a named human is accountable" is an aspiration rather than a fact, because there is no way to check it was honoured when something goes wrong.

This is not a novel problem — it is the same discipline internal audit and compliance already apply to any consequential business process — and the practical answer is the same: keep a record, proportionate to the stakes of the decision, of what the AI tool contributed and what the human did with it. For a marketing copy draft, that might be nothing more than normal version history. For a hiring screening decision, a finance forecast used to raise capital, or a compliance determination, it should be a deliberate, retained record sufficient to answer a regulator's, an auditor's, or a court's question about how the decision was actually made. Organisations that treat this as an afterthought discover the gap exactly when they can least afford to — during an audit, a dispute, or a regulatory inquiry — rather than when it was cheap to build in from the start.

The change-management problem

Across every department examined in this piece, the binding constraint on getting real value from AI tools is rarely the capability of the tool itself and much more often whether people actually change how they work to use it well. A drafting tool that produces a good first version of a document is worthless if the people who would use it do not trust it enough to try, or trust it so much they stop reviewing its output, or simply forget it exists a month after the initial announcement because their day-to-day habits never actually changed.

This is an old organisational problem wearing a new label. It responds to the same interventions any change effort responds to: a credible reason the change matters to the people being asked to adopt it, not just to the organisation; visible, senior use of the new way of working rather than a mandate issued from a distance; enough training that people are competent with the new tool rather than merely aware of it; and a feedback channel that lets early problems surface and get fixed rather than being quietly worked around. Organisations that skip these steps and simply issue a new tool tend to see a burst of initial curiosity followed by a return to the old way of working, at which point the investment in the tool itself is wasted regardless of how capable it was.

How to sequence adoption across an organisation

Given the pattern across every department above — draft and summarise are broadly safe and useful now, classify and flag are useful in well-instrumented functions, and act and decide need a longer runway of accumulated trust, data quality and governance — a sensible sequence for an organisation adopting AI across its departments follows roughly the same shape everywhere, adapted to what each department's data and stakes actually look like.

Start with the lowest-stakes, highest-volume drafting and summarising tasks in whichever department has the cleanest underlying data — commonly support ticket triage, marketing copy drafting, or code assistance in engineering — because these functions show a visible benefit quickly and the cost of an occasional bad output is low and easily caught by the existing human review step. Use that early, visible success to build the organisational habit of reviewing AI output critically rather than accepting it uncritically, which is itself the skill the later, higher-stakes adoption will depend on. Only then extend into classification and flagging in functions with good instrumentation — data anomaly detection, security alert triage, HR survey analysis — where the tool's job is to direct human attention rather than to decide anything itself. Treat the money, legal, compliance and hiring functions as a distinct, slower track throughout, where every new use case is reviewed by the relevant professional discipline before it touches anything consequential, and where the appropriate pace of adoption is set by that professional judgement, not by enthusiasm elsewhere in the business. Build the shared data layer discussed earlier in parallel with all of this, because without it the individual department wins will not compound into anything larger.

What genuinely does not automate

Running through every department in this piece is a consistent residue of work that current tools do not do well, and there is no strong reason in the evidence reviewed here to expect that to change on any predictable timetable. Negotiation between parties with genuinely opposed interests — a sales deal, a partnership, a union discussion — depends on reading a specific person's position and adjusting in real time in a way that has resisted automation. Judgement under genuine ambiguity, where the right answer depends on weighing values or trade-offs the organisation cares about rather than pattern-matching against precedent, remains a human responsibility, visible clearly in product prioritisation, legal interpretation, and financial risk decisions throughout this piece. Accountability itself — the fact that a specific, named person answers for a decision and can explain the reasoning behind it to a colleague, a customer, a regulator or a court — cannot be delegated to a system, because a system cannot be held to account in the way that matters; it can only be pointed at as the tool a human used. And trust-building relationships — the customer relationship a good salesperson or account manager builds, the safety a good manager creates for a difficult conversation, the credibility a communications leader has in a genuine crisis — remain, on the evidence of every department examined here, a distinctly human capability that a fluent generated message does not substitute for, however well it is drafted.