Split work along the greatest architectural separation. That line, from James Herbsleb and Rebecca Grinter's 1999 ICSE paper [R1], has justified a quarter-century of handing integration work to somebody else's team. The sentence immediately after it is the one nobody quotes, and it's the one that decides whether your integration backlog is delegable work or a trap with a nice interface.
An integration backlog is the queue of third-party API connections a product still owes its customers — the connectors, webhooks and data syncs everyone agrees matter but that never get a date attached, so they lose every sprint to work that has one.
Integration work is delegable when the contract behind it is written, tested and monitored. It is not delegable just because the interface is published.
Key takeaways
Sprint planning has the same five minutes in it every time. Someone raises the connector three customers have now asked for by name. Everyone agrees it matters. It doesn't make the sprint, because the billing rewrite has a date attached and the connector doesn't. Next session, same five minutes, same nodding.
Nobody in that room thinks the work is unimportant. In the 2024 State of SaaS Integrations survey, 84% of respondents said integrations were "very important" or a "key requirement" for their customers, and only 1% said not important [R35]. Another 62% said integrations come up in more than half of their sales conversations, and 24% said they surface in more than 90% of deals [R36]. Read that survey with its sample in view: it's vendor-run research across 100+ B2B SaaS leaders, 47% of them in partnerships and only 10% in engineering [R38]. It tells you what leaders report, not what engineers measured. On the same basis, 75% reported that a single integration takes three months or longer to build [R31]. The median allocation was six people [R32].
Three months of engineering for something that shows up in most sales calls, and it still loses. It loses because it doesn't arrive as a project with a launch date. It arrives as interrupts. The same report puts the top two pain points across the whole integration lifecycle after ship rather than during it: maintenance and monitoring, and third-party API changes [R33]. Building is the part you can plan. The rest is a pager.
Those interrupts land on teams with no room left. Chainguard's 2026 Engineering Reality Report found engineers spending just 16% of their week on writing code, designing systems and building new features [R20]. That report is 1,200 responses split evenly between engineers and tech leaders, fielded in August 2025 across the US, UK, Germany and France [R23]. Another 72% reported difficulty finding time for new features amid competing demands, and 66% said they frequently hit technical debt that affects delivery [R21]. Tooling isn't helping: 88% said tool-switching hurt their productivity, and 62% said their tools weren't fully integrated into their workflows [R22]. Vendor research again, self-reported again, but the shape is consistent across every source here.
Interrupt-driven work is also the most expensive kind to interleave. Chris Parnin and Spencer Rugaber ran an exploratory analysis of 10,000 recorded programming sessions from 86 programmers, plus a survey of 414 more. Only 10% of sessions saw a first edit within a minute of resuming, and in roughly 30% the lag before that first edit ran past 30 minutes [R43, R44]. Edit lag is a proxy for resumption, not the same construct, and the sessions come from an earlier Java tooling era. It's still the best measured data available, and it says what your calendar already says. Chalmers researchers Besker, Martini and Bosch, tracking 43 developers across six companies twice a week for seven weeks, found an average of 23% of developer time wasted on technical debt, most commonly on additional testing [R24, R25]. That's debt in general, not integration. It's still evidence for why maintenance-shaped work manages to be expensive and invisible on a burndown chart at the same time.
Now the number you were expecting, and won't get. There is no credible measured figure for the share of engineering time that goes to integration and API maintenance. Two candidates circulate. One says developers spend roughly 39% of their time designing, building and testing custom integrations; it sits on a vendor blog that cites sources for three other claims on the same page and none at all for that one [F1]. The other says a 2025 Gartner analysis put mid-market API maintenance at 18–24% of engineering capacity: attributed to Gartner with no report title, no link and no method [F2]. Don't borrow either. The absence is the finding: this work is big enough that everyone reaches for a percentage and unmeasured enough that nobody has one.
If you were designing a piece of work to hand to someone outside your team, you would design something that looks a lot like an integration.
Herbsleb and Grinter studied a telecom product development effort at a Lucent division split across sites in the UK and Germany, working from 10 interviews followed by 8 focused ones [R7]. Their recommendation is the sentence that gets quoted: "To the extent possible, assign work to different sites according to the greatest possible architectural separation in a design that is as modular as possible" [R1]. In the project they studied, the split was real. Components didn't cross sites, and each group worked on separate pieces [R6].
An integration against a third-party API is that separation in its purest form. The seam isn't one you drew in a design review and might redraw next quarter; it's a network boundary owned by a company you don't work for. The contract is published. The acceptance criteria are checkable by someone who has never seen your domain model, because "did the webhook produce the right row" has a yes or no answer. Nobody needs to attend your architecture debates to do the work. And each integration ships on its own, small-batch by construction rather than by discipline. Why batch size predicts delivery is a separate argument, made elsewhere.
That's a genuinely good case. It's also only half of what the paper says.
The architectural-separation line is the first bullet of a recommendation list. Here's the next one, verbatim: "To the extent possible, only split the development of well-understood products (or parts of products), where plans, processes, and interfaces are established and likely to be very stable. Instability will greatly increase the need for communication" [R2, R3].
Not a footnote. Not a hedge buried in the discussion section. The next item in the same list, from the same authors, on the same page.
Read together, the two clauses stop being advice about org charts and become a test about interfaces. Herbsleb and Grinter aren't saying "find a seam and hand across it". They're saying a seam is only safe to hand across when the thing on the other side of it holds still. Instability doesn't just make the handoff harder; it drags all the communication you thought you'd eliminated straight back in [R3]. Split along an interface that moves and you've built a coordination problem with extra steps.
Which is exactly why third-party integration looks so promising. A published, versioned API run by an external company is the one category of work where somebody outside your building has already committed, in public, to keeping the interface still. Your core domain will never satisfy that precondition, because you're changing it on purpose. The integration layer might.
Might.
No. The people publishing your integration contracts are, on the measured evidence, not honouring them.
Yasmin, Tian and Yang applied an automated analysis tool to 2,224 OpenAPI specifications covering 1,368 RESTful APIs from APIs.guru [R28]. Of the 251 API versions that introduced breaking changes, 87.3% had deprecated nothing at all in the previous version [R26]. No warning, no shadow period, no transitional flag. Among the APIs that did deprecate something, only 45% provided a replacement message and only 5% stated a removal time [R27]. Even the well-behaved minority mostly tells you what's going away without telling you what to use instead, or when it disappears.
The producing side of that relationship knows. Postman's 2025 State of the API surveyed over 5,700 developers, architects and executives, 73% of them working in engineering or software development [R15]. It found 60% of teams version their APIs, and only 26% use semantic versioning [R17]. The report's own summary: "most teams track changes without communicating the impact of those changes effectively" [R17]. Self-selected from Postman's own audience, so treat the level as directional. The direction isn't ambiguous.
Semantic versioning wouldn't rescue you anyway, because the convention leaks. Venturini and colleagues found that 11.7% of npm client packages and 13.9% of their releases were hit by a breaking change during non-major dependency updates [R29], and that 44% of manifesting breaking changes were introduced in minor and patch releases "which in principle should be backward compatible" [R30]. Nearly half the breakage arrives through the door marked safe.
And the surface keeps growing. Salt Security's 2025 survey of 206 API-managing respondents, blended with anonymised customer telemetry [R42], found 43% of organisations managing up to 100 APIs and 34% overseeing between 101 and 500 daily [R40], with 30% reporting 51–100% growth in API count over the past year [R41]. Small sample, security-skewed audience. But you don't need the exact number to see the shape: the count of contracts you depend on is going up, and the discipline behind them is not.
So Herbsleb and Grinter's second clause is not satisfied by default just because an interface is published. Published is not stable. Documented is not stable. Versioned is barely stable.
The most useful thing about that 1999 paper is that it isn't a prescription. It's a post-mortem.
The organisation Herbsleb and Grinter studied was well-resourced and specifying its interfaces formally. It still failed at the seam, because the specifications "lacked many essential details, such as message type, return types, and assumptions about performance" [R4]. Teams built simulators of each other's components to keep working, and the discrepancies stayed hidden until integration [R4]. Worse, developers negotiated informal refinements to the spec that were "sometimes, but not usually, recorded in the documentation. Only by examining the code could one infer the information" [R5]. The real contract lived in people's heads and in the diff. When the original developer moved on, the replacement broke agreements nobody had written down, and testers filed bugs against terms they'd never been told existed [R5].
That's the failure mode to plan for, and it tells you what to buy. The first deliverable of a delegated integration is not the integration. It's the contract. That means the executable statement of what this thing does, what the provider is assumed to return, what happens on a 429, which fields are load-bearing, and what "working" means on a Tuesday morning six months from now when nobody remembers building it. Contract tests. Monitored assertions against live responses. Versioned expectations that fail loudly when a provider quietly ships a breaking change in a patch release [R30].
This is still not standard practice. Postman found functional and integration testing each reaching 67% adoption, with the report framing advanced practices generally as niche [R19]. So the artefact that makes integration work delegable is, for a lot of teams, the artefact that doesn't exist yet.
There's an obvious objection here, and it's DORA's. The loosely-coupled-teams capability describes teams that can "complete work without needing fine-grained communication and coordination with people outside the team" [R45] and can do most of their testing on demand "without requiring an integrated test environment" [R46]. A separate integration function looks like precisely the outside-the-team dependency that capability warns about. But DORA's criterion is about coupling, not about who signs whose payslip. A team working behind a written, tested, monitored contract is the definition of loosely coupled. A team working behind an undocumented verbal agreement is not, and it makes no difference whether they sit two desks away. The 2025 DORA report, drawing on nearly 5,000 technology professionals plus over 100 hours of qualitative interviews [R48], found that teams in loosely coupled architectures with fast feedback loops see gains while those constrained by tightly coupled systems see little or none [R47]. Build the contract and you're on the right side of that line, whatever your org chart says.
A second objection sounds identical to that one and isn't. Two integration vendors argue hard against handing the integration layer away. Nango's Bri Cho: "When integrations break (and they will), you must wait for the unified API provider to prioritize and fix the issues" [R55]. Prismatic's Bru Woodring: "Unified APIs work until your customers stop being generic" [R56], with the real cost surfacing later as operational complexity [R57]. Both are correct, and both are attacking productised abstraction layers with fixed data models and vendor-controlled roadmaps. Neither is an argument against dedicated engineers working directly against the real APIs, with your contract tests, in your repository. Delegating the abstraction and delegating the capacity are different transactions, and only one parks your bug behind somebody else's product queue. The market appears to know it: 80% of surveyed companies build integrations in-house, 29% use an embedded iPaaS, 24% a unified API, and 21% already use an outsourced dev shop [R34].
Delegation has a measured cost. It's worth being precise about what that cost actually is, because this particular study gets mangled constantly.
Herbsleb and Mockus, writing in IEEE Transactions on Software Engineering in June 2003, analysed change requests in two departments of the same company. In Department A, single-site changes averaged about 5 days while multi-site changes took 12.7 days, more than 2.5 times as long, p<0.001 [R8]. Department B replicated the gap: about 7 days single-site versus 18 days distributed, again roughly 2.5 times, p<0.001 [R9].
Now the part that's usually quoted wrong. Department A's drivers of change interval ranked, most to least significant, as "number of people, diffusion, and size" across 2,227 change requests [R10]. Department B, across 4,974 change requests over the same window, ranked them "size, number of people, diffusion, and time" [R11]. The ranking did not replicate. Department B leads with size. If you've read somewhere that this study found number of people, diffusion and size to be the drivers of delay, you've read one department's result presented as the paper's conclusion.
Two things did replicate. First, in both departments, "after taking all other variables into account, whether the project was distributed did not have a significant effect on interval" [R12]. Second, the mechanism: splitting work across sites "slows the work down primarily because it requires the involvement of more people than comparable work accomplished all at one site" [R13]. The authors specifically ruled out two rival explanations, finding that neither change size nor module diffusion had a significant partial correlation with the multisite variable [R14].
Don't over-read that as permission. The raw 2.5x gap is real in both departments [R8, R9]. The analysis says distribution isn't the thing doing the damage. Headcount is. Distribution simply drags more people into each change.
That converts straight into a design rule. If you outsource integration work and the handoff means a discovery call, a spec review, an internal architect, an external engineer, a QA pass and a release manager, you've inherited the 2.5x and bought none of the upside. One owner per integration. One approval gate. The contract acting as the interface, doing the job a standing sync would otherwise do badly. Fewer hands per change is the whole mechanism, and it's available whether the hands are inside your building or not.
What travels well is work that's task-shaped, gated by approval rather than by meetings, and specified well enough to be checked asynchronously. A written contract instead of an inherited one. Units small enough to ship on their own. As few people touching each change as the work allows.
Dev On Demand is built to that shape. You get 1 dedicated AI-augmented engineer, a 3-day task cycle, daily async updates, and a task-by-task approval gate. Submit a task, matched same-day, with a 5-day first ship and a 5-day replacement guarantee. Dev On Demand runs async by design; engineering is distributed, headquartered in Manila, and timezone alignment isn't required. Single stream $3,495/mo, dual stream $6,795/mo, cancel any time, no lock-in, no notice period required.
None of that helps if you skip the first deliverable. Pick the integration backlog item that's been losing sprint planning the longest and spend a week not building it. Write down what the provider is assumed to return, which fields your product actually depends on, what happens when the rate limit trips, and what a monitored assertion would have to check to tell you it broke. That document is the thing that makes the work delegable, and 87.3% of the API versions that introduced breaking changes deprecated nothing beforehand [R26], so you're going to need it regardless of who writes the code.
The first deliverable was never the integration. It's the artefact that tells you the day it stopped working.
An integration backlog is the queue of third-party API connections a product still owes its customers: connectors, webhooks and data syncs that everyone agrees matter but that never get a date attached. In the 2024 State of SaaS Integrations survey, 84% of respondents said integrations were "very important" or a "key requirement" for their customers, and only 1% said not important [R35].
A written, tested and monitored contract makes it delegable. Herbsleb and Grinter's recommendation has two parts: assign work to different sites "according to the greatest possible architectural separation in a design that is as modular as possible" [R1], and "only split the development of well-understood products (or parts of products), where plans, processes, and interfaces are established and likely to be very stable" [R2, R3]. A published interface satisfies the first part on its own; it does not satisfy the second.
Not by default. Of the 251 API versions that introduced breaking changes in an analysis of 2,224 OpenAPI specifications covering 1,368 RESTful APIs, 87.3% had deprecated nothing at all in the previous version [R26, R28]. Among the APIs that did deprecate something, only 45% provided a replacement message and only 5% stated a removal time [R27]. In the npm ecosystem, 44% of manifesting breaking changes were introduced in minor and patch releases [R30].
Nobody knows. There is no credible measured figure for the share of engineering time that goes to integration and API maintenance. The two figures in circulation — roughly 39% of developer time on custom integrations [F1], and 18–24% of mid-market engineering capacity on API maintenance [F2] — are both unsourced, and neither should be borrowed.
Only if the handoff adds people. Herbsleb and Mockus found multi-site changes took roughly 2.5 times as long as single-site changes in both departments they studied [R8, R9]. But after taking all other variables into account, whether the project was distributed did not have a significant effect on interval [R12]; splitting work across sites "slows the work down primarily because it requires the involvement of more people than comparable work accomplished all at one site" [R13]. The design rule that follows is fewer hands per change: one owner per integration, one approval gate, and the contract doing the coordination.
