Chapter 3 of 7

Balance Business + Tech

Technical depth was never the problem. Knowing which room you’re in, and switching inside it, is the actual skill.

Reading time: 9 minutes

Key takeaways

• Technical depth was never the problem. Knowing which room you are in, and switching registers inside it, is the actual skill
• Fabric consultants drift toward tech only for predictable reasons: the platform rewards depth, clients struggle to articulate the business question, and technical wins are provable today while business value is not
• The habit shows up as four observable behaviors: translating architecture into cost, speed, or risk sentences, asking who owns the P&L impact before designing, stating trade offs out loud, and treating silence as a red flag rather than consent
• Workspace design (capacity splits, workspace splits, and Dev/Nonprod/Prod structure) is the clearest worked example of translating a technical decision into a business one in the same room
• Balance is a two way translation. Pushing back on a bad business ask is still part of the habit, not an exception to it

I never let a technical decision leave the room without its business sentence attached.

Early in my Fabric career, I built what I still think is one of the cleanest semantic models I have ever shipped: properly normalized, DAX measures that were a joy to maintain, a refresh strategy tuned to the second. The client thanked me, signed off, and never opened the report again. Nobody had asked what decision it was supposed to support. I had optimized the model and forgotten the meeting.

That is the trap. Fabric hands you a lot of genuinely interesting levers: capacity sizing, DirectLake vs Import, OneLake shortcuts, dataflows vs pipelines, and it is easy to fall in love with the lever instead of the outcome it is supposed to produce. Clients often cannot articulate the business question cleanly, so retreating into the technical one feels safer. It is also easier to defend in a demo: elegance is provable today, business value is not provable for months. Balance means resisting that pull on purpose, every time, not just when someone in the room happens to ask the right question.

Technical Depth Isn’t the Problem, Timing Is

Being technically strong has never been the issue. The issue is knowing which room you’re in.

I have had the “you’re too technical” feedback myself, and for a long time I heard it as an insult to the work. It isn’t. Nobody has ever complained that a consultant understood DirectLake refresh internals too well. What they are actually saying is: you gave me the DAX when I needed the decision, or worse, you gave me the decision speak in a room full of engineers who needed the DAX. Depth isn’t the fault. Deploying it in the wrong register, to the wrong audience, at the wrong moment, is.

And it is not a one time read either. The same stakeholder who wants the business framing in a steering committee will often want, and respect you more for giving them, the technical detail in a 1:1 working session an hour later. This isn’t “know your audience” as a static label you assign once. It is a live switch you operate session by session, sometimes sentence by sentence, for the same person.

The signals that tell you which mode you’re in

1. Who’s in the room, and who are they reporting to next? If the person across the table is about to walk into another meeting and relay what you said, ask what they need to be able to repeat. If they need to say “it’ll be live but a day behind” to their board, that’s the sentence you owe them, not the refresh architecture that produces it.
2. The verbs they use in their own questions. “Why is this slow?” is a technical question, answer it technically. “Why does finance keep complaining?” is a business question wearing a technical costume, answer it with cause and consequence, not query plans.
3. Silence vs follow up questions. If you go deep and get blank nods, you’ve overshot. If you stay high level and get “wait, why does that add latency?”, that’s an invitation, take it.
4. Meeting type as a default setting, not a rule. Steering committees default to business framing, design reviews default to technical framing. Use the meeting type as a starting assumption, but hold it loosely.
5. The cost of guessing wrong is asymmetric, so default up, not down. Lead with the business sentence and have the technical detail ready the moment it’s requested. Going business first and diving deep on request reads as responsive. Going technical first and being told to “back up and explain that simply” reads as having missed the room.

Technical depth is the asset. Reading the room is the skill that decides whether that asset gets used or gets in the way. The consultants who get called “too technical” usually aren’t over skilled, they’re under switching. The fix isn’t to dial down the expertise; it’s to get faster and more deliberate about which register you’re speaking in, and to treat that as a decision you make continuously, not once per client.

Knowing the signal is half the habit. Here’s what putting it into words actually sounds like, moment by moment.

Why Fabric Consultants Specifically Drift Toward Tech Only

This isn’t a character flaw. It’s a pull built into the tools and the role, and naming it honestly is more useful than pretending good consultants are simply immune to it.

The platform rewards depth, not translation

Fabric hands you a genuinely large surface area of interesting technical decisions: F-SKU sizing, DirectLake vs Import vs DirectQuery, dataflows vs pipelines, OneLake shortcuts, capacity smoothing. Every one of these has a “correct” answer you can defend with a benchmark. None of them come with a business sentence attached by default; you have to add that yourself, and it’s extra work the tooling never asks for. It’s much easier to solve the problem the platform put in front of you than the problem the client actually has.

Clients often can’t articulate the business question cleanly, so the technical one is the easier exit

Ask a stakeholder what decision a dashboard needs to support and you’ll frequently get “just show me the numbers.” That’s not laziness on their part; most people aren’t fluent in translating their own workflow into a data requirement. Faced with that vagueness, retreating into the technical question (“how do I refresh this efficiently”) feels like progress. It is progress, just not necessarily on the thing that matters.

Technical wins are provable today; business value isn’t provable for months

A well tuned semantic model demos beautifully in the room. You can show the query plan, the refresh time, the DAX doing something clever. Business value, did this actually change a decision, did it save the cost it was supposed to, often can’t be shown until a quarter or two later, if it’s measured at all. Consultants, like anyone, gravitate toward the feedback loop that’s immediate and positive. The demo claps. The business outcome doesn’t show up until you’re three engagements away.

Technical language is a safer place to hide uncertainty

If you’re not sure what the business actually needs, going deep on architecture lets you sound authoritative without committing to an answer that could be wrong. “It depends on your DirectLake fallback behavior” is a true, technically defensible sentence that can also be a way of not answering “will this be fast enough for the board meeting.” The depth isn’t dishonest, but it can become a comfortable place to stand instead of a harder, more exposed business conversation.

The people who hired you often reward it, at least at first

Early in an engagement, technical competence is what gets you the trust to keep talking. Sponsors want to know you’re credible before they’ll hand you the messier, more political business context. So the habit of leading with depth gets positively reinforced in week one, and if you don’t consciously shift gears afterward, it just keeps running long after it’s stopped being what’s needed.

None of this makes tech only drift a mistake to be ashamed of. It makes it predictable, which is exactly why it’s worth building the habit on purpose, rather than assuming awareness alone will fix it.

The Habit in Practice: Observable Behaviors

Balance isn’t a mindset you either have or don’t. It shows up as specific, repeatable things a consultant does in the room. Here are four I try to run on every engagement.

1. Translates every architectural choice into a cost, speed, or risk sentence before presenting it

I don’t bring an architecture decision into a room without its business translation already attached, not as a follow up if someone asks, but built into the sentence itself.

“DirectQuery keeps this live, but adds 2 to 3 seconds per interaction. Import is instant, but finance is looking at yesterday’s numbers.”

If I can’t compress the trade off into one sentence like that, I’m not ready to present it. I’m still solving the technical problem, not the client’s problem.

2. Asks who owns the P&L impact of the report before choosing the technical approach

Before I pick a refresh strategy, a semantic model shape, or a capacity tier, I want to know whose budget or bonus moves if this report is wrong or late, not as background colour, but as an input to the design. A report that feeds a monthly board pack has a different tolerance for staleness than one an ops team refreshes hourly to catch fraud. I ask this question before I touch the architecture, because asking after just turns the answer into a justification for a decision I already made.

3. States trade offs out loud rather than picking silently and hoping nobody asks

Every non trivial technical decision has more than one defensible answer, and it’s tempting to just pick the one you like and move on, especially when the client wouldn’t know the difference. I say the trade off out loud instead, even when nobody asked:

“I can do this the fast way or the right way. Here’s what each one costs you.”

This does two things: it forces me to actually know the trade off rather than defaulting on autopilot, and it puts the risk decision where it belongs, with the person who owns the consequences, not with me quietly.

4. Treats stakeholder silence as a red flag, not consent

Silence is the most dangerous signal in this work, because it’s easy to read as agreement when it’s usually just absence of understanding. The decisions most likely to pass in silence are the ones that sound purely technical or purely administrative, which is exactly why they need to be forced into the open, not left to slide.

A good example is capacity design vs workspace design, two decisions that get bundled together and nodded through as “IT stuff,” but that carry very different risks:

• Capacity is a performance and cost risk. Undersize it and reports slow down or throttle under load; oversize it and you’re paying for headroom nobody uses. This is the risk of not enough, or too much, engine.
• Workspace design, how many workspaces, who has access, what’s dev/test/prod, how permissions and lineage are structured, is a governance and sprawl risk. Get this wrong and six months later nobody can say who owns what, duplicate semantic models spring up because nobody could find the “real” one, and access controls become unenforceable because the boundaries were never designed, just accumulated.

These are genuinely separate conversations with separate owners. Capacity usually sits with whoever owns cost and performance SLAs; workspace design sits with whoever owns governance and access risk. I don’t let them get compressed into one nodded through “yes, sounds good” in a single meeting. I ask each stakeholder group directly: “If we get workspace sprawl in eight months and three teams have built their own copy of this model, whose problem is that?” If nobody answers that clearly, I don’t proceed on the assumption that silence meant “we’ve thought about it.”

The thread across all four: none of these behaviors are about being less technical. They’re about refusing to let a technical decision travel alone. Every choice gets paired with who it affects, what it costs, and an actual answer from someone who owns the consequence, before it gets built.

A Worked Fabric Example: Workspace Design

This is where balance stops being a philosophy and becomes a diagram. Workspace design is one of the most consequential decisions in a Fabric estate, and it’s routinely nodded through as “just how we organize things,” which is exactly the silence flagged above. Here’s how I actually work through it, and how I present it so both a platform engineer and a sponsor walk away understanding the same decision.

The technical reasoning

There are two separate axes people conflate, and untangling them is most of the job.

Decision	What it governs	Split when
Capacity	Compute isolation and cost attribution	Workloads have genuinely different performance SLAs (an exec dashboard that must never be slow shouldn’t share an F-SKU with a nightly data science batch job); you need clean cost chargeback to different business units; a workload has a track record of noisy neighbour behaviour, such as a runaway dataflow refresh throttling everyone else on the same capacity
Workspace	Ownership, access, and lifecycle	Security boundaries differ (different RLS requirements, different sensitivity of data); team or domain ownership differs (finance and supply chain shouldn’t co-own a workspace just because they’re on the same capacity); a discrete project or use case needs its own lifecycle so it can eventually be decommissioned cleanly rather than becoming permanent clutter in a shared workspace

If none of the conditions in the capacity row apply, splitting capacity just multiplies admin overhead and licensing cost for no isolation benefit you actually needed.

Dev, Nonprod, and Prod design

Each stage gets its own workspace, connected via Fabric deployment pipelines, not manually rebuilt. Access tightens as you move right: broad edit access in Dev, controlled promotion gates into Nonprod for testing (including RLS and performance validation), and Prod restricted to a small number of publishers with everything else read only, promoted only through the pipeline. Connections and parameters (source database, capacity assignment) are parameterized per stage so the same semantic model can be promoted without manual rewiring. That parameterization is usually the single biggest thing that separates a clean promotion process from a fragile one.

The business reasoning, in the same room

To a sponsor, I don’t lead with any of the above. I say something closer to:

“We’re going to give Finance and Supply Chain their own separate spaces so a mistake or a slow report in one team never affects the other, and so we can tell you exactly what each team’s reporting is costing you. And we’re going to build this the way you build software: a place to build, a place to test, a place that’s live, so nothing reaches your board pack that hasn’t been checked first.”

That one paragraph is the entire technical section above, translated. The engineer in the room hears “capacity isolation, RLS boundaries, deployment pipeline gating” and nods because the substance is all there. The sponsor hears “blast radius control, cost transparency, and quality gates before it reaches me” and nods because that’s what they actually needed to approve. Same decision, two audiences, one conversation. That’s the whole habit in one worked example.

The Overcorrection Warning

None of this is licence to simply defer to whatever the business asks for. Balance is a two way translation, not a one way surrender, and it’s worth being blunt about that, because “listen to the business more” is advice that’s easy to overdo.

If a stakeholder asks for a fast dashboard on a data model I already know has duplicate keys, no lineage, or an RLS gap, saying yes without comment isn’t balance, it’s avoidance wearing balance’s clothes. The habit isn’t “give them what they ask for translated nicely.” It’s “give them the real trade off, including the one they didn’t ask about.” Sometimes the business sentence is uncomfortable:

“I can have this live Friday. If the numbers are wrong in the board pack, the fix costs you a week and costs me your trust in the room, not just my time.”

Saying that clearly, and meaning it, is still the habit. Pushing back is part of the translation, not an exception to it.

Close With a Practice

Before I finalize any architecture decision, I write two sentences: what it costs the business, and what it costs the platform. If I can’t write both, I’m not done.

That’s the whole habit, reduced to a ritual you can actually run. Not a mindset to aspire to, not a value to hold: a specific thing you do, every time, before a decision leaves your desk. Depth got you into the room. This is what keeps you useful once you’re in it.