Short answer: every dashboard graveyard in this industry is a translation failure, so the scarcest profile is the translator — one head that has done a warehouse return AND writes the DAX. I’ve been the brewer, worked the distilling and winemaking side, 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 floor already calculates, and the first number an operator checks is one they recognise. That’s where trust starts — and trust, not technology, is what production dashboards die without.
This closes the process-intelligence series. Part one mapped the four analytics onto distillery work; part two dissected why skilled Power BI developers still build dashboards that die on the production floor. 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 domain expert explains the process to a BI developer through workshops and a requirements document. Every fact crosses a gap. The distiller says “yield” and means litres of pure alcohol per tonne at the industry definition; the developer hears a percentage and builds one. The brewer says “day three of fermentation” and means seventy-two hours from pitch; the developer joins on a calendar 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: batch genealogy as the spine because the why questions need it; bulk litres and LPA as separate, clearly named measures because a warehouse return taught me the difference the hard way; fermentation curves plotted in hours-from-pitch because that’s how anyone who has ever pulled a gravity sample thinks about them.
What the hybrid actually does differently
Starts in the morning 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 every morning. Those arguments are the requirements document, and you can only read them if you understand the argument.
Defines measures with their industry semantics written down. Every KPI in the model carries its IBD-grade definition — what’s included, what moisture basis, which litres. Partly so operators recognise their 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 regauge is a measurement; an interpolated monthly stock figure is a guess wearing a measurement’s clothes. Having filled in the 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 whiteboard for a month. The floor verifies it the way they verify a new colleague — and only after it passes do we climb the analytics ladder toward prediction and prescription. 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 domain judgement, not platform feature.
Spans the three fermentations. Beer, spirit and wine look different and rhyme deeply — batch genealogy, gravity 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 mash week, and a solera is not a rackhouse.
Why this matters beyond one career
The point of this post is not “hire me” — it’s that the industry’s dashboard graveyard is a translation problem, and translation problems have exactly three fixes: put a translator in the room (pair a process person with the developer for the life of the project, not a two-workshop cameo); train the trade (give brewers and distillers real modelling discipline — often faster than teaching a developer ten years of process intuition); or grow hybrids deliberately (the path is now well-lit — the Brewing Science & 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 — I reach for the KPIs of my training; a different distillery’s custom deserves to be modelled on its own terms, and the floor is right about its own process even when my instinct disagrees. The certification matters as much as the brewing — 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 sales dashboard in a drinks company 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
Production dashboards in breweries, distilleries and wineries die of translation failure, and the cure is getting process 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 industry definitions, the estimates are labelled as estimates, and the first number the floor 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 brewer, distiller or winemaker 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 brewing or distilling experience build better production dashboards? Because the failure points are all translation failures. Someone who has done a warehouse return knows bulk litres from litres of pure alcohol; someone who has run fermentations knows why time is measured in hours from pitch, not calendar dates; someone who has stood at the spirit safe defines yield the way the industry defines it. The data model comes out process-true on the first pass, and operators recognise their own numbers — which is where trust, and therefore usage, comes from.
Can a distillery just train its own people in Power BI instead of hiring developers? Sometimes — and it often beats the reverse. Teaching a process person solid modelling discipline (star schemas, measure design, version control) is frequently faster than teaching a developer ten years of process intuition. The risk is the lovable unmaintainable hairball: domain people with no engineering discipline build dashboards that die when they change jobs. The discipline has to come with the domain knowledge.
What should a hybrid brewer-distiller-BI developer actually do differently? Start in the morning meeting, not the data warehouse: find the numbers the team already argues about, model the batch genealogy as the spine, define every measure with its industry semantics written down, and ship one small dashboard that matches the whiteboard before building anything ambitious. Trust is won number by number.