When organisations adopt AI, they plan for the first-order effects: new tools, new skills, new models. They almost never plan for the second-order effects: how AI reshapes the relationships between people, the boundaries between teams, and the nature of the work itself.
The first-order effects are visible and manageable. The second-order effects are where the real disruption happens, and they catch organisations off guard because they were not in the adoption plan.
The disappearing boundary between analytics and engineering
The traditional data team structure has a clean separation. Data engineers build pipelines. Data analysts build reports. Data scientists build models. The boundaries are defined by tools, skills, and organisational reporting lines.
AI tools blur every one of these boundaries. When an analyst can write a Python script that calls an LLM to transform data, they are doing engineering work. When an engineer uses an AI assistant to generate a visualisation, they are doing analytics work. When a data scientist fine-tunes a model that replaces a hand-built rule system, they are doing work that used to belong to both engineering and analytics.
This is not a problem in theory. In practice, it creates organisational friction. Who owns the AI-assisted data transformation: the analyst who prompted it or the engineer whose pipeline it runs in? Who is responsible when an AI-generated report has an error: the person who reviewed it or the tool that produced it? These questions sound bureaucratic until someone has to answer them during an incident.
The rise and problem of the “full-stack” data person
AI tools enable individuals to do work that previously required a team. A single person with an AI coding assistant can build a pipeline, train a model, create a dashboard, and write the documentation. This has given rise to the idea of the “full-stack data person”: one person who can do everything.
The appeal is obvious: fewer handoffs, faster delivery, lower headcount. The reality is more complicated.
Full-stack capability enabled by AI tools is real but shallow. The person can produce all the artifacts, but they may not understand the infrastructure the pipeline runs on, the statistical assumptions the model makes, or the business context the dashboard should reflect. They can do everything at a surface level. They cannot do everything at a depth level.
The organisational risk is that teams restructure around the full-stack ideal and lose the depth that comes from specialisation. When everyone is responsible for everything, nobody is responsible for anything in particular. The data quality function dissolves because “everyone does data quality.” The platform function dissolves because “everyone manages their own infrastructure.” The result is a team that moves fast and produces systems that nobody deeply understands.
How reporting lines are shifting
The second-order effect on reporting lines is subtler but significant. As AI tools make individual contributors more productive, the span of control for managers changes. A manager who oversaw six people doing manual data work might now oversee three people doing AI-assisted data work. But the complexity of what those three people produce has not decreased. It has increased, because AI-assisted work is harder to review and harder to debug.
This creates a management challenge. Managers need to evaluate work they may not fully understand. They need to set quality standards for outputs that were partly generated by a tool. They need to allocate work across a team whose individual capabilities are changing rapidly as the tools improve.
We have seen organisations respond to this in two ways. Some add a technical review layer: senior engineers who review AI-assisted work before it ships. This works but creates a bottleneck. Others shift to outcome-based management: instead of reviewing the work, they review the results. This works but requires robust monitoring, because you are trusting the process without inspecting the artifacts.
The collaboration pattern that actually works
The teams we have seen navigate these second-order effects well share a common pattern. They do not reorganise around AI. They reorganise around outcomes.
Instead of “data engineering team” and “analytics team,” they form around business domains: revenue data, customer data, product data. Within each domain team, people have different specialisations, but the team owns the outcome end-to-end. If an AI tool means one person can do work that used to require two, the team adapts without a reorganisation.
The key enabler is shared ownership of data quality. When the team owns the outcome, they own the quality. There is no handoff to a separate QA function. There is no “the pipeline team will fix it.” The team that builds the AI-assisted transformation is the team that monitors its output and fixes it when it breaks.
This does not require a specific team size or structure. It requires a specific mindset: the team is accountable for the result, not the activity. AI tools change the activity. The accountability does not change.
What leaders should watch for
If you are leading a data team through an AI adoption, the second-order effects to watch for are not technical. They are organisational.
Watch for role confusion. When AI tools blur the boundaries between roles, people need clarity about what they are accountable for, even if the boundaries of what they do are expanding. Ambiguity about accountability is the fastest path to finger-pointing when something goes wrong.
Watch for depth erosion. When AI tools make it easy to do everything at a surface level, make sure your team still has people who go deep on the things that matter. You need someone who understands the data model, someone who understands the infrastructure, and someone who understands the business context. These may be the same person on a small team, but they must be present.
Watch for the review gap. When AI generates work, the temptation is to review it less carefully because “the tool produced it.” Resist this. AI-generated work needs the same review rigour as human-generated work, because the failure modes are different, not lesser.
The organisations that handle AI adoption well are not the ones that plan for every second-order effect. They are the ones that stay alert to the organisational changes as they emerge and adapt before the friction becomes dysfunction.
