12.11.26

Who Should I Hire for a Microsoft Fabric Implementation Project?

Microsoft Fabric migrations are landing on data leaders' desks faster than most hiring processes can adapt, and the roles look deceptively similar to old-world BI and data engineering positions on paper. They aren't. Below, we answer the questions we get asked most often when a Head of BI or Head of Data starts building out a Fabric implementation team — drawn from what we actually screen for on Fabric and Power BI mandates.

Core Skills and Role Requirements

What technical skills should I require for a Microsoft Fabric data engineer?

A Fabric data engineer needs hands-on experience building pipelines and orchestration inside Fabric itself, not just adjacent Azure tools. In our screenings, strong candidates describe pipeline building using either Fabric notebooks or Azure Data Factory, with orchestration layered on top, and can speak concretely about troubleshooting when a source file doesn't land on schedule. Look for candidates who can describe hands-on ETL and transformation work spanning disparate sources — Excel, SharePoint, SQL, Databricks tables — brought together into a single model, rather than candidates who only know how to consume clean data. Many strong Fabric engineers don't hold a formal "data engineer" certification at all; what matters more is a long track record of transformation work under that title.

Do I need to require medallion architecture experience specifically?

Yes — medallion architecture is the default pattern for Fabric implementations and should be a standard screening question. Candidates should be able to explain the bronze, silver, gold structure unprompted: raw data landing in bronze, cleaned and de-identified data in silver, and curated, aggregated data in gold for reporting consumption. One consultant we screened described this precisely using a web analytics example — raw click data in bronze, de-identified user behaviour in silver, and aggregated hourly conversion metrics in gold. This isn't an optional nice-to-have skill; multiple candidates across different implementations independently described medallion architecture as the standard way Fabric lakehouses are structured. If a candidate can't explain why gold-layer data is the only layer end users should touch, that's a red flag worth probing further.

What should I look for in a Fabric-focused Power BI lead?

A Fabric Power BI lead needs end-to-end ownership experience — from stakeholder requirements gathering through to semantic model design and dashboard delivery. One candidate we screened described implementing an entire Power BI infrastructure from scratch at a major financial services firm, including taking requirements, building the semantic model, sourcing data from multiple systems, and creating gold and silver data layers in Fabric for reporting consumption. Lead-level candidates should also be comfortable defining a BI vision across a wider programme and establishing BI profiles, not just building individual reports. Genuine lead-level hires also bring stakeholder engagement experience — sitting with business stakeholders to gather requirements, planning development and deployment, and mentoring junior BI consultants.

Should Fabric hires also have Power BI certification?

Certification is a useful signal but should never substitute for a live conversation about medallion architecture and BI consumption patterns. We've screened Fabric candidates who hold Power BI certification alongside a strong practical grasp of medallion architecture and end-to-end implementation. Others we've placed have no formal data engineering qualification at all, relying instead on nearly two decades of hands-on ETL and transformation experience. The certification tells you someone has studied the platform; the screening conversation tells you whether they've actually built with it under real constraints.

Screening for Real Fabric Experience vs. CV Keywords

How do I tell the difference between someone who's actually implemented Fabric and someone who's just listed it on their CV?

Genuine Fabric experience shows up in the specifics of how someone describes a project, not just the tools they name. Ask about a real scenario — for example, how they'd handle a missing source file in a scheduled pipeline — and listen for whether they can describe copying forward from the previous bronze load or a similar concrete recovery mechanism. We've seen candidates describe using Fabric since its public preview and delivering some of the first production projects once it reached general availability, which is the kind of detail that separates practitioners from CV name-droppers. Ask them to walk through a specific project end to end — sourcing, transformation layer by layer, and final consumption in Power BI — rather than accepting a list of tool names as evidence of depth.

What does strong end-to-end Fabric and Power BI experience actually look like in practice?

Strong end-to-end experience combines Fabric-side data engineering with Power BI-side visualisation on the same project. One candidate we screened described a logistics use case where postcode data, previously managed manually in Excel and mapped by region, was pulled in via a postcode API, split into structured regions inside Fabric, and visualised as an interactive UK map in Power BI showing order volumes and delivery failures by region. This is the pattern worth probing for: can the candidate describe a project where they built the pipeline and also delivered the report that stakeholders — in that case, a head of operations — actually used to make decisions.

Is Databricks experience relevant when hiring for a Fabric project, or are these separate skill sets?

Databricks and Fabric experience are highly transferable, and candidates with both should be treated as a strong signal rather than a distraction. We've screened data architects who describe Fabric, Databricks, and Snowflake as fundamentally similar warehouse solutions, with the same underlying skills — including PySpark-based notebook transformation — applying across all three. One candidate described using Databricks for a machine learning project, setting up data pipelines that fed models directly, alongside separate experience in Fabric. If your Fabric migration is running alongside legacy Databricks workloads, prioritise candidates who've worked across both rather than insisting on Fabric-only CVs.

Cloud-Agnostic Hiring for Microsoft Ecosystem Projects

Fabric sits inside the Microsoft ecosystem, but the strongest implementation teams we've screened rarely stay confined to it.

Does a Fabric implementation really require Microsoft-only specialists, or should I be open to candidates with AWS/GCP backgrounds?

Fabric implementation teams benefit from candidates who are equally comfortable across Microsoft and non-Microsoft cloud platforms. We've screened data architects who describe themselves as equally experienced in Microsoft and AWS environments, bringing that breadth directly into Fabric and Databricks project work. On one active mandate, a consultancy building out an investment management transformation team explicitly wanted data engineers and architects with cross-platform experience, not narrow Microsoft specialists, because the underlying migration touched multiple platforms. Ruling out strong AWS or GCP-background candidates purely because a role sits on Fabric narrows your shortlist without improving quality — the underlying architecture skills (medallion layering, semantic modelling, pipeline orchestration) transfer directly.

What roles typically make up a Fabric implementation project team?

A typical Fabric implementation team combines data engineers, data architects, data analysts, and a lead BI resource, often supplied through a consultancy rather than hired individually. On one live mandate, an investment management client needed a full project team of data engineers, data architects, and data analysts to oversee a large-scale transformation and migration programme starting in a defined month. Separately, we've placed dedicated Lead BI hires responsible for the gold layer specifically — owning reporting and analytics delivery through Power BI and Fabric, bridging architecture, engineering, and C-suite stakeholders, with junior Power BI developers or analysts reporting into them. Decide upfront whether you need a single senior generalist or a layered team with a lead sitting above junior developers — the screening bar differs significantly between the two.

How senior does a Fabric solutions architect need to be, and what should differentiate them from a hands-on engineer?

A genuine Fabric solutions architect operates at the design level — defining strategic vision, data requirements, and the overall tech stack — while handing detailed build work to engineers. One architect we screened described combining Dynamics, Azure Synapse, and Fabric to build a downstream reporting solution with a medallion-structured data warehouse feeding Power BI, while explicitly noting they weren't looking for a senior engineer-type role because their contribution was architecture and design, not day-to-day development. When screening for this seniority level, ask candidates to distinguish their own architectural decisions from the engineering execution — strong architects will describe handing off SQL querying and detailed build work to engineers rather than claiming to do it all themselves.

What contractual and rate factors should I expect when hiring Fabric specialists?

IR35 status and day rate expectations vary significantly by role seniority and mandate type on Fabric projects. Outside IR35 day rates for Fabric and Power BI specialists we've screened have sat around £550, with inside IR35 rates running higher, in the £630–£650 range. Most Fabric contract roles we place are outside IR35, typically remote with occasional in-office days each month, though this varies depending on the industry and whether the role carries lead or mentoring responsibilities. Build IR35 status into your job spec early, since it materially affects both the rate you'll pay and the pool of specialists willing to engage.

What should I take away when building a Fabric hiring shortlist?

Prioritise candidates who can explain medallion architecture, semantic modelling, and end-to-end delivery in their own words rather than those who simply list Fabric on a CV. Test for cross-platform fluency — genuine Fabric strength often sits alongside Databricks, Snowflake, or AWS experience — because that breadth is what lets a hire adapt as your architecture evolves. Match seniority to the actual project need: a hands-on engineer, a Power BI lead with stakeholder-facing responsibility, or an architect who designs and delegates are three different hires with three different screening bars. We screen every Fabric and Power BI candidate against these exact patterns before they reach your shortlist — get in touch to talk through your project team requirements.