The team moves and the failure stays

“Data should be a business unit, not sit under IT.” The take arrives every week, and it arrives with a diagnosis attached. The data team is a ticket desk. It is technical and far from the decision, it builds pipelines nobody asked for and dashboards nobody opens, and it will stay that way while it reports into technology. The prescription follows: move it. Under operations, under finance, or out on its own with its own budget. The reporting line is offered as the cure.

The symptom is real. I have run central data teams, and I have had the queue the diagnosis describes: a roadmap made of other people’s requests, and platform work done with what was left. The fixes are the ones in Too many priorities, none of them yours and Giving the models away, and neither of them moved the team.

What I do not buy is the diagnosis as a blanket, or the reporting line as the cure. A reporting line is one of management’s instruments. A move helps when it changes the authority, the incentives or the capabilities that produced the failure, and changing the line alone guarantees none of them. For a central function that combines analytics and data engineering and serves several departments, I would start under technology, with the analysts in the departments’ planning and the definitions in one place, and I would move it on conditions, not on a diagnosis.

A data team is not there to produce numbers. It is there to solve the problem alongside the business, from the question before anything is built to the decision it was asked for. Supply the number and step back, and the team is a support function, whatever the org chart calls it. Nobody making the argument claims the data team decides. The inference is quieter: the team hands over the numbers, the product lead greenlights the launch, and because the output is consumed where decisions are made, the function gets filed with the people who make them. Proximity to the decision gets mistaken for ownership of it. What the team owned was the number and what it meant, and those are two kinds of work.

In front of the number is analysis: the recommendation, the alternative, the condition that would change it. That half belongs near the decision. Behind the number is engineering: code, reviews, migrations, upgrades, and pipelines that hold at two in the morning so that a number can look effortless at nine. The take puts the whole function where the first half belongs and hopes the second half survives the trip.

For the organization, the question is where to put the team and what to hold it to. For the individual, it is whether to accept a diagnosis written before anyone looked at your work.

The failure appears on both sides of the line

Consider four illustrative failures, each of which can appear under either reporting line.

The failure	Under technology	Under the business
The queue	Requests arrive as tickets, and the team is measured on closing them	Requests arrive in person from the people who sign the budget, and declining one costs more: the same queue without the ticketing system
The number nobody trusts	One warehouse nobody is allowed to change, and a BI tool bought to route around it	Three BI tools, each with its own revenue, and no agreed definition between them
Distance from the decision	Platform work that never touches strategy	Analysis commissioned after the decision, to support it
The load that fails overnight	The pipeline is restored, and nobody checks whether the reports built on it recovered	The report has an owner, and nobody is responsible for restoring its feed

The queue survives a move when the same requests still carry the same authority.

Every row has a variable that moves it, and each is something a manager sets, or asks for and is refused: what the team is measured on, who may decline a request, who owns a definition, who restores the service and checks the result. An org chart cannot make a team say no. A manager can, as often as the leader above takes the call. The reporting line decides who that leader is and what they answer for, which is what a move changes by itself, and the thing to name before moving anyone.

I have watched a central queue and weak governance fill both columns at once. Business units, citing the slowness of the central team, took the free version of a BI tool, exported the numbers from the corporate dashboards and analyzed them there. Executives cited the results, and the ghost hunt for where each number had come from ended nowhere, because the units could not read the logic inside their own tool. The queue gave the detour its reason; the missing traceability left nobody able to explain the number. That scene argues for fixing access and ownership. It does not say which reporting line would have done it.

Take the move seriously before declining it

The serious version runs like this. A reporting line sets defaults. Under an IT organization the defaults are tickets, uptime, cost and projects delivered on time, and a team held to them becomes a ticket desk by construction, whatever its manager intends. Under product engineering the defaults are releases and reliability, and the same team becomes a platform with a roadmap nobody asked for. Decisions form in planning conversations, and a team under technology hears about them when the request arrives. When the data budget competes with infrastructure and security inside one cost center, it rarely gets a hearing of its own. A technology organization that already plans around business outcomes gets credit for it in the comparison.

So I would concede the mechanism and decline the conclusion. The defaults under the business are not neutral either. They reward responsiveness and the number being right by nine, and they rarely include the practice that got it there: review, change control, the postmortem when it was not. Those risks belong in the design of the proposed arrangement as much as distance from the decision belongs in the assessment of the current one. Setting the measures on purpose is management’s work under either line. Under technology it takes the technology leader’s agreement; under a business leader it comes with the job, which is the honest version of the argument for moving.

The best version of the move is not analysts without engineers. It is the whole function, engineers and on-call included, under a leader whose remit is the whole organization rather than one department’s case, with a budget of its own, capable engineering management, funded access to the shared technology services it still needs, and accountability for bringing the analysis into planning. That version can work. It is a different proposition from putting the team inside one operating department, where that department’s priorities carry more weight than anyone else’s.

What the move costs depends on what it separates. Review, release, security and incident support continue across a reporting line the way every shared service does: on an agreement with a named owner on each side and a budget line for the capacity. Without the agreement the moved team is a customer with no priority; without the budget line, a customer with no service. A regulated company adds to the estimate the controls the new arrangement actually changes, and no others. Price those lines before counting the new budget as a gain.

What sits behind the number is engineering

Helping a business decide is technical work, and the org chart question is where the technical work runs best.

A number a product lead can greenlight a launch on is the visible end of a production system: a pipeline reviewed before it merged, a migration rehearsed before it ran, a test that failed overnight and paged someone, and a definition held in code with an owner’s name on it. The discipline lives where it is managed, funded and expected, which is not every IT organization and is rarely the business side of the house. A team carries good habits across a move and loses them with the first round of turnover, when the replacements are hired by someone who does not interview for habits that are invisible while they work. Staying under technology does not protect them either, once the technology leader stops paying for them.

Where the systems that record the business are run by the same technology leader, a field change on one side and the model change it forces on the other are one priority call instead of a negotiation. Where those systems are vendor-run or owned by product, that advantage is gone and the engineering argument stands alone.

A pipeline can also deliver accurate data into a bad comparison. The choice of population, the assumptions and the uncertainty around a result need a competent analytical review of their own, and whichever line houses the combined function has to develop and assess that craft alongside the engineering. Reliable delivery discharges half the obligation.

The test of a new reporting line is whether the leader at the top of it will fund the engineering behind the number before the first outage.

Give the business the definitions and keep the analysis independent

The proximity the diagnosis wants is real, and the arrangement gets it without spending the engineering or the independence.

The pattern I have used is the one in Building a data function from zero, with the center under technology: analysts join it for governance, standards and tooling, and spend their week in the department they serve, in its planning and on its strategy, from the goal to the assessment afterward of whether the work helped. What that case leaves unsaid is who reviews them. The person who writes their performance review sits in the center, with no stake in the department’s case, because an analyst belongs to whoever does. The department’s view of whether the work was useful goes into that review, and so does the center’s view of the analysis. Where a department hires business analysts of its own, their analysis is the department’s, labeled as such, and built on the same definitions. Reconcile the inputs and the definitions before the decision, and put any remaining difference of interpretation, with its reasons, in front of the decision owner. Agreement on the facts should leave room for disagreement about what to do.

Three decision rights hold the arrangement up. The data leader proposes the capacity plan with the business owners, including the platform work their priorities depend on; the technology leader approves it, and the leader both technology and the business units report to settles the conflicts they cannot. The data leader delivers within that plan and declines work outside it. A named business owner settles each shared definition, and the owner of the process that records bad data corrects it at the source, because a pipeline repair cannot fix a process that records the wrong thing.

What stays independent is the data team’s analysis. A stakeholder who owns a strategy has a reason to want the number to favor it, and a team that answers to that stakeholder inherits the reason. Central reporting reduces the pressure to defend one department’s case, and a central function under a business leader can have the same protection. It makes nobody neutral: a technology leader has a platform investment to defend, an analyst has a previous recommendation to protect, and the data people who helped shape a strategy want it to succeed. Under either line, independence is the right to show the assumptions, publish an unwelcome finding, recommend a different course, and take pressure to suppress any of that to someone outside the disputed strategy.

The seat in the room is the last piece, and here the argument for moving has a point. The first seat is given, not earned. A reporting line is one way to give it; a standing invitation to the planning cycle is another: cheaper, revocable, and it puts the team in the plan but not in the budget. What keeps the seat after the first quarter is trust, and trust is the record: what the last three recommendations resolved, including the one that said to stay the course.

Move the team when three things are true at once

The conditions need stating, or the default keeps every team. I would move it when the current arrangement has blocked necessary work after the ask was made plainly; when the leader who would receive the team has committed to changing that constraint, with a plan to keep funding the change; and when the receiving arrangement can sustain the engineering and the independent analysis at a cost worth paying. The prompts to run that test are concrete: the measures asked for and, a planning cycle later, still the inherited ones; the budget fight lost twice with the record in hand; a business leader who will fund the engineering line when the technology leader will not. Each is a reason to review the arrangement rather than a verdict on it. A lost budget fight proves frustration, and the request still has to be tested against the business needs it competed with.

A team does not have to be failing for the comparison to be worth making; a new remit can put most of its dependencies with a business leader who will fund the engineering, and the same comparison chooses the home for a new function.

Size changes the arithmetic, not the test. A small team at an early company has fewer established dependencies to separate, and still has reliability, continuity and analytical judgment to protect. A large function may have enough engineers to run its own on-call and review, or may keep the shared services under written commitments. Enough people to move establishes that a move is feasible; the improvement still has to justify the cost.

Or split it, which is where many large organizations land: platform engineering stays with engineering as a service, analytics becomes a function of its own under a leader whose stake is the whole plan, and the definitions keep their named business owners. It buys an analytics leader with an enterprise remit and a platform held to a service level instead of a relationship. It costs two backlogs and a boundary through every definition change, and its failure mode is the analytics function queued behind the platform roadmap: the original queue with a new name.

Check the record before you accept the diagnosis

Not every data team is the one in the diagnosis. Some sit inside the corporate strategy, understand the problem before they build anything, and bring a solution and an alternative to the decision instead of the number as asked. The diagnosis is written as if it describes everyone.

Whether it describes yours is settled not by where you sit but by the record in Count the decisions, not the dashboards: which decisions the team’s work was part of last quarter, what it recommended, what was decided, and what happened. Include what the evidence resolved: good analysis can confirm the planned course, prevent an unnecessary change, or establish that the evidence is not there yet, and a recommendation that was ignored goes in the record as ignored. Read that contribution beside whether the data stayed dependable: correct enough for its use, available when needed, restored when it failed. Some teams under technology can show both. Some under an operating department can too. Others have a record of requests fulfilled and little evidence that any of it helped anyone decide. The same record, kept by one person about their own work, answers it for that person. A strong record rebuts the claim that technology reporting prevents useful work; whether the current arrangement is the best one available takes the comparison above.

If the record is thin, begin with what is within your reach: ask for the decision before building the chart, make the recommendation explicit, keep the log. Authority to decline work is a separate matter. Ask the manager to agree the team’s remit and to back a refusal that follows from it. A refusal overruled without a change in priorities tells you something about the arrangement, and writing the constraint down is what makes it possible to address.

The blanket diagnosis has a cost for the people it describes. It teaches a team that its position is structural and the fix is someone else’s, and a team that believes that waits for a reorganization before improving anything. Treating every constraint as a failure of initiative has a cost too: it asks people to exercise authority they have never been given. The record separates the two.

A diagnosis with no exceptions is a diagram with no failure mode: if there is no data team it does not describe, it is not describing yours.

What it costs

The arrangement is a trade. The price lands on four parties, and the default carries one risk of its own.

The technology leader carries a measure the business produces. Held to what its analysis contributed and whether its data stayed dependable, a data team under technology answers to someone whose other teams are measured on uptime and delivery, and that leader defends a budget line on evidence the business owners write down, which some quarters is thin. The answer is a business sponsor for the platform’s budget, found before the thin quarter, and finding one is the leader’s work.

The business gives up command of a team it pays for. The business owners help set the priorities and judge usefulness, and they cannot move every request to the front or suppress a finding they dislike. The same limit binds the technology leader when the analysis challenges a technology investment. The first unwelcome number lands on someone senior, who has to take it, and someone above the dispute has to stand behind the team’s right to publish it, in public, the first few times.

The team carries the proof. A team that claims to help the business decide keeps the record of which decisions, what it contributed and what the evidence resolved, and makes the engineering visible while it is working. The record is what stands between the team and the next diagnosis, and no request queue ever asks for it.

The analysts pay in career path. Under technology they sit on an engineering ladder that ends in engineering, and the business files them as IT. The center owes them a ladder that ends somewhere else, one that recognizes analytical judgment, domain understanding and the quality of a recommendation, and has to build it. Without one, the center’s promise to value the analysis has little force at review time.

Some teams that stay should have moved. The conditions above are a judgment, and the technology leader, best placed to make it, has a reason to keep the team. Have someone outside the current reporting chain challenge the comparison, with the record in hand, and put the decision with whoever can authorize both arrangements. An annual review is the backstop; a credible proposal does not wait for it.

The take will be back next week, with the same diagnosis and the same prescription. Read it for the symptom, which is usually right. Then look at what the team is measured on, who may tell it no, who owns the definition, and who was awake at two. Move the team when the new line changes one of those and the price has been counted. Otherwise the team moves and the failure stays.