Short answer: every dashboard graveyard in wine is a translation failure, so the scarcest profile is the translator — one head that has done a vintage AND writes the DAX. I came up through brewing, worked across distilling and winemaking, and I’m the certified Power BI and Fabric developer; the difference isn’t that hybrids write better code, it’s that the model comes out process-true on the first pass, the KPIs match what the cellar already calculates, and the first number a winemaker checks is one they recognise. That’s where trust starts — and trust, not technology, is what winery dashboards die without.

WINERY INTELLIGENCE LIVES IN THE OVERLAPWinemakingcrush pad · fermentsbarrel hall · blendingtonnes vs litres · Brix vs pHlot genealogyBI engineeringstar schemas · DAXFabric · OneLakerefresh · governanceversion controlthetranslatordashboardsthat surviveeither circle alone produces the failure modes of the previous post — the overlap is rare, and it's where the value is
Not better code, not deeper cellar lore — the value is one head holding both, so nothing is lost in translation.

This closes the winery process-intelligence series. Part one mapped the four analytics onto cellar work; part two dissected why skilled Power BI developers still build dashboards that die a vintage later. This one is personal, because the answer to part two is a profile I happen to live: I came up through brewing, worked across distilling and winemaking, and then became the certified Power BI and Microsoft Fabric developer. This post is what that combination actually changes — and, in keeping with the house rules, what it doesn’t.

The expensive conversation that doesn’t happen

Picture the standard project: a winemaker explains the process to a BI developer through workshops and a requirements document. Every fact crosses a gap. The winemaker says “yield” and means tonnes per hectare in the vineyard or press yield in the cellar — two different numbers; the developer hears one percentage and builds it. The winemaker says “day five of the ferment” and means a point on a Brix curve, not a calendar date; the developer joins on the date. Each small mistranslation is invisible at build time and obvious at first use — and part two covered what one recognisably wrong number does to trust.

When both sides live in one head, that conversation simply doesn’t happen, because there’s no gap to lose facts across. The model comes out process-true on the first pass: lot genealogy from block to bottle as the spine because the why questions need it, with blending modelled as the many-to-many it actually is; tonnes of fruit and finished litres as separate, clearly named measures because a vintage taught me the difference; ferments plotted on Brix curves in days-from-inoculation because that’s how anyone who has pulled a sample thinks about them.

What the hybrid actually does differently

Starts in the cellar meeting, not the data warehouse. The first artefact isn’t a lakehouse architecture — it’s a list of the numbers the team already argues about: why is this block behind, did that lot stick, is the VA creeping. Those arguments are the requirements document, and you can only read them if you understand the argument.

Defines measures with their oenological semantics written down. Every KPI carries its definition — tonnes vs litres, titratable acidity vs pH, free vs total SO₂, press yield basis. Partly so the cellar recognises its numbers; mostly so the next developer can’t silently mangle them. This is what makes a dashboard maintainable after I leave, which is the real test.

Knows which numbers are measured and which are estimates. A lab panel is a measurement; an interpolated tank volume between dips is a guess wearing a measurement’s clothes. Having filled in the addition log myself, I model them differently and the dashboard says which is which — the same honesty rule that runs through collecting your data before AI.

Ships small and wins trust number by number. One page, three KPIs, checked against the lab notebook for a vintage. The cellar verifies it the way they verify a new hire — and only after it passes do we climb the analytics ladder toward harvest prediction and blend optimisation. Fabric makes this climb dramatically less painful — one copy of the data in OneLake, notebooks and Power BI reading the same tables — but the climbing order is oenological judgement, not platform feature.

Spans the three fermentations. Beer, spirit and wine look different and rhyme deeply — batch genealogy, gravity and Brix curves, blend decisions, stock ageing. Having worked all three (the long version of that story is From Brewer to Data Scientist), patterns built once port across with their assumptions checked rather than assumed — a vintage is not a brew week, and a barrel hall is not a rackhouse, however alike the schemas look.

Why this matters beyond one career

The point of this post is not “hire me” — it’s that wine’s dashboard graveyard is a translation problem, and translation problems have exactly three fixes: put a translator in the room (pair a winemaker with the developer for the life of the project, not a two-workshop cameo); train the trade (give winemakers and cellar masters real modelling discipline — often faster than teaching a developer the intuition of ten vintages); or grow hybrids deliberately (the path is now well-lit — the Winemaking & AI track exists precisely because more people should walk it). Any of the three beats the default, which is hoping a requirements document can carry what it has never once carried.

Where this breaks

The honest section, pointed at myself. One head doesn’t scale — a hybrid is a bottleneck and a bus-factor of one unless they document semantics and grow others, which is why everything above insists on written definitions. Hybrid bias is real — my brewing-and-distilling instinct can lead me to over-trust gravity-curve thinking where a winemaker would weight aroma, phenolics and tasting; a winery’s own custom deserves to be modelled on its terms, and the cellar is right about its own process even when my instinct disagrees. The certification matters as much as the cellar time — domain people who skip the engineering discipline build the lovable, unmaintainable hairball from part two, and I hold the certifications because the discipline half is not optional. And sometimes you don’t need the hybrid — a DTC or club dashboard is just a sales dashboard; the overlap profile is scarce, so spend it where the translation is actually hard: on the process side, where the dashboards keep dying.

The bottom line

Winery dashboards die of translation failure, and the cure is getting oenological knowledge and BI engineering into the same room — or the same head. The hybrid’s edge isn’t cleverness; it’s that nothing is lost in translation: the model is process-true, the KPIs carry their winemaking definitions, the estimates are labelled as estimates, and the first number the cellar checks is one they recognise. That’s how trust starts, and trust is the entire game. The tools have never been better — Fabric finally puts the whole ladder on one platform — but the overlap is still the scarce resource. If you’re a winemaker or cellar master eyeing the data side: the industry doesn’t just have room for you. It’s short of you.

Frequently asked questions

Why does a BI developer with winemaking experience build better winery dashboards? Because the failure points are all translation failures. Someone who has done a vintage knows tonnes of fruit from finished litres; someone who has run ferments knows why time is days on skins and curve shape, not calendar dates; someone who has pulled barrel samples defines yield and acidity the way oenology defines them. The data model comes out process-true on the first pass, and the cellar recognises its own numbers — which is where trust, and therefore usage, comes from.

Can a winery train its own people in Power BI instead of hiring developers? Sometimes — and it often beats the reverse. Teaching a winemaker or cellar master solid modelling discipline (star schemas, measure design, version control) is frequently faster than teaching a developer the intuition of ten vintages. The risk is the lovable unmaintainable hairball: domain people with no engineering discipline build dashboards that die when they change cellars. The discipline has to come with the domain knowledge.

What should a hybrid winemaker-BI developer actually do differently? Start in the cellar meeting, not the data warehouse: find the numbers the team already argues about, model lot genealogy from block to bottle as the spine, define every measure with its oenological semantics written down, and ship one small dashboard that matches the lab notebook before building anything ambitious. Trust is won number by number, vintage by vintage.