What Skills Do You Need on Your Team to Run a Data Lakehouse?

The lakehouse project has a clear owner while it is being built. The harder question, and the one that decides whether the investment lasts, comes at go-live: who runs it now. A platform nobody owns degrades — pipelines break and are not fixed, the model drifts, definitions fork, and within a year the business is back to spreadsheets with an expensive lakehouse gathering dust.

Two myths distort the answer. Vendors imply you need a large team of specialists — data engineers, scientists, architects — which frightens mid-market businesses out of building at all. And optimists imply the platform runs itself, which is how it degrades. The truth is in between: fewer people than the vendor implies, more ownership than the optimist admits.

What you actually need is a small set of capabilities and, above all, clear ownership. The roles that matter are not the exotic ones on the architecture diagram.

The first essential capability is a data platform engineer — the person who keeps the pipelines running and the platform healthy. When a source changes, a load fails, or a new data source needs connecting, this is who handles it. On a Microsoft estate, this is Fabric, Data Factory, OneLake and the pipeline layer — and importantly, these are Microsoft skills your existing IT or BI team may already have or can readily build.

This does not have to be a dedicated hire in a mid-market business. It is often an existing IT or BI person who takes on the platform as part of their remit, supported by training and by a partner for the harder problems. The key is that someone owns pipeline health and platform maintenance as a named responsibility, not that you have hired a data-engineering specialist.

The failure mode is nobody owning it — the pipelines built by the project team break after handover and there is no one whose job it is to fix them. Assigning that ownership is more important than the seniority of the person who holds it.

The second capability is ownership of the semantic model and the reporting on top of it. This is the person who keeps the governed model trustworthy — who owns the measure definitions (OEE, OTIF, margin), applies changes properly rather than letting analysts fork them, manages row-level security and the report estate, and is the point of accountability for "is this number right."

This is a Power BI and modelling skill, and again it is often an existing BI analyst elevated to own the governed model rather than a new specialist. The shift is from building lots of reports to stewarding one governed model that everything reads from — a different discipline, but a learnable one for a capable BI person.

This role is what prevents the slow drift back to chaos: without a model owner, every analyst builds their own version of margin and the governed model erodes. With one, the model stays the single source of truth long after go-live.

The third capability is the one most often missed, and it is not a technical role at all: a named business data owner for each domain. This is the operations or finance leader who owns what the numbers mean and what the priorities are — who decides how OTIF is defined for the business, which data problems matter most, and whether a new requirement is worth building.

Without this, the technical team makes business decisions by default — defining metrics in a vacuum, prioritising by whoever shouts loudest — and the platform drifts from what the business actually needs. The business data owner keeps the lakehouse aligned to operations, because they own the meaning and the priorities that the engineers and the model owner then implement.

This role cannot be outsourced and does not require technical skill; it requires business authority and engagement. It is the ownership half of "more ownership than the optimist admits" — and it is where mid-market lakehouse investments most often quietly fail, not for lack of engineering but for lack of a business owner.

For a mid-market business, the gap is usually not the business owner or the everyday platform maintenance — it is the specialist depth for the harder problems and the senior data leadership to set direction. Hiring a full-time senior data architect or a chief data officer is often more than the business needs or can justify.

This is where a fractional model fits: a fractional data consultant or fractional Chief Data Officer provides the senior direction, the architecture decisions, and the specialist support for the hard problems, part-time, alongside your internal platform engineer and model owner who handle the day-to-day. The business gets senior capability without a senior full-time cost, and the internal team is supported rather than left to sink or swim.

The combination that works for most mid-market businesses is: internal ownership of platform, model and business definitions, plus fractional senior and specialist support. That covers the capability without the headcount the vendor implied you would need.

Running a data lakehouse needs three capabilities and a lot less exotic headcount than the vendor diagram suggests: a platform engineer (often an existing IT/BI person) to keep it healthy, a semantic-model owner to keep the governed model trustworthy, and a named business data owner per domain to own definitions and priorities. On a Microsoft estate the first two are largely existing skills; the third is business authority, not technical skill.

What cannot be skipped is ownership. The platform degrades not for lack of a data-science team but for lack of someone whose job it is to own each layer. And what does not need to be hired full-time is senior direction and specialist depth — a fractional model covers that alongside the internal owners.

So the honest answer to "what skills do I need" is: fewer specialists than you fear, more ownership than you expect, and a fractional partner for the senior gap. That is a team a mid-market business can actually field — which is the point of building on a governed platform in the first place.