Category: Perspectives

What "Department-Level Output" Actually Means

Claims about artificial intelligence doing the work of hundreds of people have become a genre unto themselves, and most of them deserve the skepticism they get. When a vendor says their platform delivers "the output of a 900-person team," the reasonable response is to ask what that actually means — and whether it's a meaningful statement or marketing arithmetic. We use language like this about our own platform, so we owe an honest account of what we mean by it. This piece is that account. It examines what "department-level output" actually refers to, why the comparison is useful despite its limits, where the claim would be misleading if taken too literally, and what an honest version of it looks like.

Where these numbers come from

When someone claims a platform produces the output of a large team, the number is almost always a comparison of throughput on a defined body of work, not a claim that the platform is equivalent to that many humans in every respect. The logic runs like this. Consider the full scope of work involved in building and operating an enterprise data estate — every pipeline built and maintained, every model designed and updated, every governance check enforced, every operational issue resolved, continuously, across a large and complex environment. Now estimate how many people, working conventionally, it would take to do all of that work at the pace and consistency the platform achieves. That estimate is where a figure like "900 FTE" comes from: it's the human headcount that would be required to match the platform's throughput on that specific body of work. This is a legitimate comparison as far as it goes. It's answering a real question — "how much work is this system doing, expressed in terms people can grasp?" — and headcount-equivalence is a natural unit for that. But it's crucial to be precise about what it does and doesn't claim.

What the comparison legitimately captures

There are real, defensible reasons the comparison holds for the work it describes. Continuity multiplies output. A human works a fraction of the hours in a day and takes time off. An agent operates continuously. On work that benefits from being done around the clock — monitoring, maintenance, ongoing operations — the effective throughput difference is large, and it's real, not rhetorical. A system that never stops genuinely does the work of many people who do. Consistency eliminates rework. A significant portion of human data-team effort goes into dealing with variation — reconciling inconsistently built pipelines, relearning undocumented logic, fixing things that were done differently by different people. Agent operation produces uniformity that eliminates much of this overhead. Output isn't just faster; it's cleaner, which compounds the effective difference. Parallelism scales. Agents can execute many streams of standardizable work simultaneously in a way a human team, bounded by coordination overhead and individual attention, cannot. On parallelizable work, this genuinely multiplies throughput. For the specific body of work these characteristics apply to — the continuous, consistent, parallelizable execution of data operations — a large headcount-equivalence figure isn't hype. It's a reasonable description of a real throughput difference.

Where it would be misleading

Honesty requires being equally clear about what the comparison does not mean, because taken literally in the wrong way, it misleads. It doesn't mean the platform replaces 900 specific people's judgment. A large fraction of what makes a great data professional valuable is judgment — architectural decisions, novel problem-solving, understanding business context, knowing what not to build. The platform doesn't do 900 people's worth of judgment. It does a large team's worth of execution, while a small number of senior practitioners supply the judgment. Conflating throughput-equivalence with judgment-equivalence would be dishonest. It doesn't mean any 900-person team could be swapped out. The comparison describes a body of standardizable, continuous, operational work. It's not a claim that the platform equals 900 people across every function — strategy, stakeholder relationships, genuinely creative or exploratory work. Those aren't what the number refers to. It's an estimate, not a measurement. Headcount-equivalence figures are inherently approximate. The honest framing treats them as illustrative of scale, not as precise accounting. Anyone presenting such a number as a hard, audited fact is overclaiming. The claim is meaningful when it's understood as "this platform's throughput on continuous, standardizable data operations is equivalent to what a large team would produce." It's misleading when it's stretched into "this platform is equivalent to 900 people in every respect." We mean the former.

Why the comparison is still worth making

Given all these caveats, why use the language at all? Because it communicates something true and important that's otherwise hard to convey: the scale of the throughput difference between agent-operated infrastructure and a conventional human-run data operation. If we simply said "our platform is efficient," that's true but uninformative — every vendor says that. The headcount comparison, properly understood, conveys the magnitude of the difference in a unit people intuitively grasp. It's the difference between "faster" and "an order-of-magnitude difference in throughput on the operational work." The latter is worth saying, and headcount-equivalence is an honest way to say it, as long as the caveats travel with it. The comparison also usefully reframes the buyer's question. Instead of "how many consultants will I need and what will they cost," the relevant question becomes "what throughput does this platform deliver, and what does the supervision layer cost." That's a better question, and the headcount framing helps get there.

What the honest version sounds like

Here's how we'd state it without any marketing inflation: Our platform, operated by proprietary agents and supervised by senior practitioners, executes the continuous, standardizable work of building and running an enterprise data estate at a throughput that would require a large team — on the order of a department — to match conventionally. It does this because it operates continuously, with machine consistency, in parallel, across the operational work of the data lifecycle. It does not replace the judgment of that many people. A small number of senior practitioners supply the architecture, standards, and accountability. What the platform replaces is the headcount that operational execution would otherwise demand — which is most of the headcount, because most of the headcount in a conventional data operation is doing exactly that kind of continuous, standardizable execution. That's the honest claim. It's a strong claim — a genuine order-of-magnitude difference in operational throughput — precisely because it's bounded to what's actually true.

The bottom line

"Department-level output" and figures like "900 FTE" are meaningful when understood correctly: they describe the throughput of an agent-operated platform on the continuous, standardizable, parallelizable work of running a data estate, expressed in a unit people can grasp. That throughput difference is real, driven by continuity, consistency, and parallelism. The claim becomes misleading only when stretched beyond that — into judgment-equivalence, or universal headcount replacement, or precise accounting. The honest version is bounded: a large team's worth of execution, supervised by a small number of practitioners supplying the judgment. Understood that way, the comparison isn't hype. It's the clearest available way to describe a genuinely large difference in what the platform does versus how data operations have traditionally been staffed.
Dobler Data Solutions delivers department-level output through agent-operated infrastructure — machine execution at scale, human judgment where it matters. See how we deliver.

Why We Walked Away from the Billable-Hour Model

For most of the professional services world, the billable hour is simply how things are done. You have a problem, a firm assigns people to it, and you pay for their time. It's so standard that few clients stop to ask whether it's the right way to buy the thing they actually want. We did stop to ask, and the answer led us to rebuild our entire business around a different model. This is an honest account of why. Not a marketing pitch dressed as a manifesto, but a straightforward explanation of what's wrong with the billable hour for data work specifically, what we replaced it with, and what that change means for the clients we serve.

The billable hour rewards the wrong things

The core problem with the billable hour is an incentive misalignment that everyone in the industry knows about and few talk about plainly: the firm is paid for time spent, but the client wants outcomes achieved. Those are not the same thing, and where they diverge, the billable hour pulls in the wrong direction. Consider what the model rewards. A firm bills more when work takes longer. It bills more when a problem requires more people. It bills more when a solution is complex enough to require ongoing involvement. None of these are things a client wants. Clients want problems solved quickly, with the fewest resources, in ways that don't require perpetual dependence. The billable hour makes the firm's revenue move opposite to the client's interest. This doesn't mean consultants are acting in bad faith — most are genuinely trying to serve their clients well. It means they're doing so against the grain of their own compensation model, relying on professionalism to overcome an incentive structure that pushes the other way. That's a fragile foundation, and it produces predictable distortions: engagements that stretch, scopes that expand, solutions that keep the firm involved.

In data work, the misalignment is especially sharp

The billable hour's problems apply to professional services broadly, but data work makes them acute for a specific reason: so much of the value is in things that recur and compound, and the billable hour is bad at both. Data infrastructure isn't a one-time deliverable. Pipelines need maintaining, models need updating, governance needs enforcing, and the whole thing needs operating continuously. Under a billable-hour model, all of that ongoing work is more billable hours — which means the firm's incentive is for your data operation to keep requiring their people indefinitely. The better aligned outcome — infrastructure that runs itself and needs minimal ongoing human intervention — is precisely the outcome the billable hour disincentivizes. There's also the knowledge problem. Under the staffing model, expertise lives in the people assigned to your account. When they roll off, the knowledge goes with them, and the next engagement starts partly from scratch — more hours, relearning what was already learned. The model has no mechanism for making expertise durable, because durable expertise would reduce billable hours. For data work specifically, then, the billable hour doesn't just misalign incentives at the margin. It actively works against the two things that matter most: infrastructure that becomes self-sufficient, and expertise that compounds rather than resets.

What we replaced it with

We rebuilt the business around a platform model, and the shift is more fundamental than a pricing change. It's a change in what we're actually selling. Under the billable hour, we sold hours — the time of people doing data work. Under the platform model, we sell a capability: a data platform, operated by proprietary agents and supervised by senior practitioners, that builds and runs your data infrastructure as a durable, self-maintaining system. This changes our incentives at the root. We're no longer paid more when work takes longer or requires more people, because we're not selling time. We're providing a platform that delivers outcomes, and our interest is in that platform being efficient, self-sufficient, and effective — because that's what makes it valuable and what makes clients stay. Efficiency stops being something we have to resist for revenue's sake and becomes something we're rewarded for. The knowledge problem dissolves too. Because the platform's capability is encoded in the system rather than carried in the heads of assigned individuals, expertise is durable by construction. There's no roll-off, no relearning, no reset. The platform gets better over time; it doesn't start over each engagement.

What this means for clients

The abstract argument matters less than the concrete difference clients experience, so here's what actually changes. Our incentives point the same direction as yours. We want your data infrastructure to be efficient and self-sufficient, because that's what a good platform is. You no longer have to rely on our professionalism to overcome our compensation model — the model itself is aligned. You're buying a durable capability, not a temporary arrangement. The platform doesn't roll off. The knowledge doesn't leave. What we build keeps running and keeps improving, rather than needing to be re-established with each new engagement. The economics are different. Because we're not selling hours, your cost isn't tied to how long work takes or how many people it requires. You get platform economics — capability that scales without a proportional scaling of cost — rather than a bill that grows with every hour and every headcount. We stand behind outcomes. When you sell hours, you're accountable for effort. When you sell a platform, you're accountable for whether it works. That's a higher bar, and it's the right one.

The honest caveats

Walking away from the billable hour isn't a costless purity play, and it's worth being straight about the tradeoffs. The platform model requires genuine platform maturity to deliver on its promises. It's easy to rebrand a staffing business with new language; it's hard to actually build a platform that operates infrastructure rather than just helping people operate it. Clients are right to test the claim — to ask what the platform actually does versus what people do, and whether the "platform" is real or a marketing layer over the same old hours. The model also isn't a fit for every kind of work. Genuinely bespoke, one-off, exploratory work — where the value really is in a smart person spending time on a novel problem — can be better served by paying for that time. We're not claiming the billable hour is wrong for everything. We're claiming it's wrong for the recurring, operational, compounding work that makes up the bulk of enterprise data infrastructure — which is the work we do.

The bottom line

The billable hour rewards time spent, but clients want outcomes achieved, and in data work — where value recurs, compounds, and should tend toward self-sufficiency — that misalignment is especially damaging. It disincentivizes exactly the outcomes clients most want: infrastructure that runs itself and expertise that compounds. We walked away from it because we didn't want to spend our business relying on professionalism to overcome our own incentives. The platform model aligns what we're rewarded for with what our clients actually want: efficient, durable, self-maintaining data infrastructure, backed by accountability for outcomes rather than for hours. That alignment is the whole reason we made the change.
Dobler Data Solutions is an AI-native data platform — we sell durable capability, not billable hours. Read our story.