You have signed off on Fabric, you have a budget that covers three or four people, and the business has already been promised something visible by the end of the quarter. The question you are actually asking is not “what does a Fabric team look like” in the abstract. It is: who do I hire first, so the next three hires are not wasted?
This comes up in almost every conversation we have with heads of data and programme managers at the moment. It is worth answering properly, because the order you hire in determines whether your second and third hires spend their first six months building or re-building.
What we are seeing in the market, and what it does not tell you
Over a recent 60 day window we recorded 201 market-intelligence signals in the Fabric and data stream, linked to 201 distinct company records. A signal is a recorded observation, not a verified live vacancy, and these records should not be read as 201 separate hiring decisions or 201 funded programmes. What they are useful for is shape.
Two things stand out in that shape. First, the role titles in those records skew heavily towards Data Engineer, Senior Data Engineer, Data Analyst and Senior Data Analyst. Architecture and governance titles are far less visible. Second, Fabric is rarely named on its own. Power BI, Databricks, Azure Data Factory and broader Azure data tooling appear alongside it constantly, with concentrations in New South Wales and Victoria and in financial services, IT services and consulting.
The interpretation, and it is an interpretation rather than an observation: a lot of organisations are hiring hands before they have hired a head. They are buying delivery capacity into an environment where the platform decisions, the Databricks-versus-Fabric boundary and the governance model have not been settled. That is the expensive version of this project.
Hire the person who sets the shape first
If you only get one hire right, make it the person who decides how the platform is going to work. Call it a data platform architect, a lead data engineer with architecture scope, or a principal engineer. The title matters less than the mandate.
This person needs to make a short list of decisions in their first eight weeks, and those decisions will constrain everything your later hires do:
- Where the lakehouse sits, and which workloads stay in an existing Azure or Databricks estate rather than moving.
- The medallion structure and what “gold” actually means for your reporting layer.
- Capacity sizing and who gets to spin up what, because Fabric capacity is a cost control problem as much as a technical one.
- Workspace and domain design, which is the part that quietly determines whether governance is possible later.
- Semantic model ownership, especially if you already have a sprawl of Power BI content built by the business.
You do not need this person forever at that seniority. You do need them before you have three engineers building pipelines into a structure nobody has agreed on.
Then engineering, then analytics
Hire two: a senior data engineer who has actually migrated or built in Fabric, and a mid-level engineer who can take the patterns and repeat them. Resist the temptation to hire two seniors. The work splits badly and you will pay twice for the same pattern-setting.
Analytics comes third, not first. The pressure to hire an analyst early is understandable because an analyst produces something people can see. But an analyst sitting on top of an unfinished platform will build direct-query reports against raw sources to keep stakeholders happy, and those become the shadow architecture you spend next year unpicking. If you need visible output early, borrow it from an existing Power BI capability rather than making a permanent hire to fill the gap. We wrote more about how that capability is priced and structured in our Power BI recruitment guide for data leaders.
What to ask when you interview
Fabric is young enough that “five years of Fabric experience” does not exist. Candidates know this, which is why CVs have been rewritten to put Fabric at the top of a skills list that is mostly Azure Data Factory and Synapse. That is not dishonest, and the underlying skills often transfer well. You just need to test for the difference.
Questions that separate the two quickly:
- “Walk me through a Fabric capacity you have had to size or troubleshoot. What was throttling and what did you change?” Someone who has run Fabric in anger has a story here. Someone who has only prototyped does not.
- “When would you tell me not to use Fabric?” A good architect will name Databricks, an existing Synapse investment or a streaming requirement without hesitation. Anyone who says Fabric is always the answer is selling.
- “How do you handle source control and deployment across workspaces?” Deployment pipelines, Git integration and environment promotion are where hobby projects and production work part company.
- “Show me how you would model this for a semantic layer, not just land it.” Plenty of engineers can move data. Fewer can shape it so the reporting layer stays sane.
- “What did you inherit that was wrong, and what did you do about it?” Most Fabric work in Australia right now is migration, not greenfield.
Ask for a working session rather than a whiteboard. Thirty minutes with a small dataset and a real question tells you more than an hour of discussion.
Permanent or contract
Our usual recommendation: contract the shaping, permanently hire the running.
The architecture and migration phase is finite, intense and benefits from someone who has done it three times elsewhere. That is a contract profile, and in Sydney and Melbourne you can usually find it inside a few weeks. The engineers who maintain, extend and support the platform afterwards should be permanent, because the institutional knowledge of your source systems is worth more over time than Fabric expertise alone.
The mistake we see most often is the reverse: a permanent architect hired for a twelve month transformation who has nothing at that level to do in month fourteen, and a contract engineering team whose knowledge walks out when the budget cycle turns.
One more practical point. Governance roles rarely appear in the records we track, and they are almost never funded at the start. Decide now who owns data quality, access and lineage, even if it is a part of someone’s existing job. Fabric makes it very easy to create workspaces and very hard to clean them up.
A sensible first quarter
Weeks one to four: brief and interview for the architecture or lead engineering hire, with a defined eight week decision mandate written into the role. Weeks three to eight: that person starts, and you run the senior engineer process in parallel using their input on the shortlist. Weeks eight to twelve: second engineer, and a first conversation about analytics ownership. Avoid approving any new Power BI content against raw sources during this period unless you have agreed a date to retire it.
If you want a second opinion on the sequencing before you post anything, that is the kind of conversation we have most weeks. Our Microsoft Fabric recruitment practice and our broader Data and AI recruitment work across Australia and New Zealand are built around getting the first hire right rather than filling four seats quickly. There is more detail on how we structure these teams in our piece on building the Fabric capability your data strategy needs.
Candidates in this space can register through our Talent Portal, which we are continuing to build out to improve matching and give clients better visibility of pipeline. If you are planning Fabric hiring for this quarter and want to pressure-test the order, get in touch and we will give you a straight view of what is realistic on your timeline.