Your org chart and your data platform are one system

In my last article, AI is the thin layer, I made the case that the data foundations underneath AI are a lot of the work required to make it operate properly. That's still true. But good data on a broken org chart still fails, even with the best technology.

Conway's Law says your system ends up looking like your org chart, whatever the architecture diagram on the wall says. Sixty years old, still true. It doesn't care how clean your lakehouse is. The trap is treating this as a platform problem when it's a culture, people and roles problem wearing a platform's clothes. 

The fix isn't a suite of tools to work around the problem, it's understanding that the roles themselves are doing genuinely different jobs than they did two years ago. The right tools still help, they just don't fix a structural problem on their own.

The trap 

I see it regularly. An organisation buys the platform, hires a Head of AI, and assumes the org will catch up on its own. It doesn't. Deloitte's numbers say the same thing at scale: 81% of execs say they can deploy and govern AI today, but nearly 75% admit the operating model itself has to change in the next 12 to 18 months to sustain that. Only 1% say no operating model change is needed at all.

Data leaders know the org has to move. Many haven't moved it, and haven't worked out how.

The roles that decides whether this works

Take two roles: the data product owner and the data engineer. What they're accountable for looks nothing like it did two years ago.

The data product owner. I've said before, borrowing from data mesh thinking, that someone has to own a data product, define its interface, and be accountable for its quality. Without that, you have a lake with no lifeguard.

AI exacerbates that problem rather than replacing it:

• Ownership stops being a delivery milestone and becomes continuous. Models drift. Data drifts. Someone has to be watching after go-live.
  
  
• Data accuracy used to mean the data. Now it includes the model's behaviour too. A wrong answer looks the same to a business user whether the data was bad or the model was.
  
  
• The job used to mean checking deterministic data quality reports: same input, same output, pass or fail. That definition of quality has expanded. It now has to cover the model's behaviour too, and that behaviour is probabilistic. The same input won't always give the same answer, so validation can't be a one-off gate any more. It has to be continuous, the same way the data itself needs continuous watching.

My honest opinion: this is usually the most under-invested role in most data and AI programmes I see. Everyone budgets for an architect, engineers and the platform. Almost nobody budgets properly for this role, then wonders why nothing has an owner six months in, and the data has quietly drifted with no one watching.

The data engineer. The job is moving from writing pipelines to writing specifications that an agent then builds against. Spec-driven development: write the intent, the constraints, and the acceptance criteria once, let the agent implement, validate automatically at every step. The engineer still owns the modelling and the judgement calls. The agent does the typing.

It’s the same point about design and code generally, which I highlighted in my previous article. It lifts the floor. Your least experienced data engineer starts producing work that reflects your best one's standards, because everyone is working from the same spec.

The skill that matters most now isn't a new framework. It's writing a spec precise enough that an agent can't misread it. Some engineers are already good at this, prompting and specification come naturally to them. Others aren't, and that gap gets overlooked because there's an assumption that technical people will just pick it up. AI isn't a new version of a technology people already know. It's a more fundamental shift than that, and treating the skill gap as trivial is a mistake.

The fix

Do the data work and the org work together, not in sequence. Fund the data product owner role properly, as a continuous job, not a project role that ends at go-live. Most organisations already have someone doing this work, or someone with the skills to, just without the title, the tools, or the mandate to do it properly. Get your data engineers writing specs an agent can't misinterpret, not just prompts. Don't let the org chart design your platform by accident, because Conway's Law will do it for you whether you plan for it or not.

That's why at Red Badger, we build these roles and expectations into our data platform work from the start, and we always scope cultural and organisational impact alongside the technology, not as an afterthought.

If you want to know whether Conway's Law is quietly designing your platform for you, ask yourself these:

• Have we actually planned for the cultural and organisational change the platform requires, not just the technical one?

• Have we defined the data product owner role for where we're going, or just mapped it to an existing set of responsibilities?

• Are we changing how our engineering teams actually work, or will the platform just end up mirroring how they've always worked?

• Have we considered how users will interact with the platform in the future, not how they do today?