u/Brighter_rocks

KPI card, 5 seconds to load. Performance Analyzer confirms ~5,200ms. The measure behind it:

Completed Transactions Revenue =
CALCULATE(
  SUM('Transactions'[Revenue]),
  'TransactionState'[State] = "Completed"
)

So what's happening?

The fact table has one row per product - TransactionID repeats. The state table has one row per state change - TransactionID repeats there too. Neither side is unique, so the relationship is many-to-many.

The storage engine can't do a direct lookup. It builds a cross-product intermediate table first, then filters it. With 500K transactions and 2M state records that intermediate result is enormous. No segment-level filtering either - full table scan on every evaluation. Each slicer on the page forces the engine to resolve the join from scratch.

Performance Analyzer: 4,800ms in the Storage Engine, 400ms in the Formula Engine. 92% of the time is spent scanning and joining, not executing DAX. 47 SE queries for two lines of code.

The fix is a bridge table with one row per TransactionID - clean unique key on both sides, direct lookup, no cross-product. The measure doesn't change at all.

Other model decisions that degrade everything

• High cardinality columns in fact tables - email addresses, URLs, natural keys destroy compression. Surrogate integer keys compress significantly better and are faster on every scan
• Wide fact tables with unreferenced columns - columns that serve no report purpose still consume memory and participate in scans
• Mixed-grain fact tables - forces DAX to navigate relationships that shouldn't exist
• Calculated columns in DAX where Power Query could do the work - not compressed the same way imported columns are

Every CALCULATE, FILTER, and RELATED call translates to storage engine operations - segment scans, hash joins, lookups. The model determines how many. Two lines of DAX can generate 47 SE queries if the model requires navigating a bad join.

When to stop tuning DAX and look at the model

• DAX rewrites cut less than 20% off query time
• Server timings show high SE time relative to FE time
• Simple measures are slow across the board - not just one
• Performance drops significantly when row count increases modestly

A well-written measure on a bad model is still slow. A mediocre measure on a clean model is usually fast enough.

The average is almost always a lie.

Most executive dashboards are built around aggregates because they're clean and fit in a card visual. But a system that's sometimes excellent and sometimes terrible and a stable system look identical at the aggregate level. Predictability is often worth more to the business than a high average - especially in logistics, support, fintech, infrastructure.

Example. Two systems, same average delivery time: 4.2 days. One is consistent. The other swings between 1 day and 9 days. The mean is identical. The customer experience is not.

Support tickets, churn, escalations - these come from the tail, not the mean. The customer who waited 9 days doesn't care that average is 4.2.

Mean response time: 220ms. Fine. P95: 1,400ms. That's 5% of requests over a second - enough to breach SLA, invisible in the KPI card.

Average order value: $85 across all regions. Histogram shows two clusters - $40 and $130 - with nothing in between. Two customer segments averaged into one number that represents neither.

Variance is also an early warning. The mean stays stable while the distribution spreads - by the time the average moves, the problem is already established.

• Mean = what usually happens
• P95/P99 = what your worst-case users experience
• Distribution shape = whether your "average user" actually exists
• Variance = how much operational uncertainty you're carrying

The trust problem everybody talks about has a corporate version too. It shows up as data. Different parts of the organization operating on different versions of reality, and nobody officially owns the discrepancy

This used to be annoying. Now it's getting worse.

The 2026 Human Edge report connects it to something bigger: a broad collapse of trust - in institutions, in employers, in information generally. Inside companies that shows up as exactly this. Everyone has their own version of the truth. Nobody has authority over it.

Which puts analysts in a strange position. Not a bad one - a strange one.

The person who can walk into that meeting with one number, explain exactly where it came from and why the other numbers are wrong, and make everyone leave with the same figure in their head - that person is not doing technical work anymore. They're doing something the organization desperately needs and very rarely has.

A few things that actually matter here:

If the board deck doesn't match the ops dashboard, it doesn't matter which one is right. Trust is already gone. Owning that reconciliation before the meeting happens is the job.

In low-trust environments data gets weaponized. Teams pick the metrics that support their case. The analyst who's been consistently right about small things for two years is the only one in the room whose number doesn't get challenged.

External data is getting noisier - AI-generated content, incentivized research, misinformation. Clean internal data is becoming genuinely scarce. If yours is trustworthy, that's not infrastructure. That's an asset

My honest impression is: the market is flooded with people who learned tools, but there’s still a shortage of people who can operate independently

Most conversations about AI and the future of work focus on what tools are coming. Far fewer talk about who you'll be sitting across the table from when you try to explain what those tools produced.

By 2030, over 25% of the workforce in developed countries will be older than 55. At the same time, companies are racing to embed AI into every workflow. That means analysts will increasingly operate in teams with a massive spread — colleagues who grew up debugging code alongside colleagues who learned Excel in a training seminar in 2003. Same meeting, completely different mental models of what data can and can't do.

This is less a technology problem than a communication one. And it's one analysts are particularly exposed to, because their job is literally to produce outputs that other people use to make decisions.

A few things worth thinking about here:

The person who understands the output is rarely the person making the decision. In mixed-seniority teams, the final call often sits with someone who has deep institutional knowledge and limited AI fluency. That's not a problem to solve - it's a dynamic to design around. The analyst who figures out how to make their work legible to that person without dumbing it down is the one whose work actually gets used.

AI literacy is not evenly distributed, and assuming it is will wreck your credibility. Dropping a model output into a meeting without context doesn't just confuse people - it creates distrust. "I don't understand this" very quickly becomes "I don't trust this." The translation layer isn't optional.

Knowing who actually influences decisions matters more than the org chart. In age-diverse teams, informal authority often sits with experienced people who've seen enough cycles to be skeptical of new tools. Getting them curious rather than defensive about AI-assisted analysis is a real skill - and mostly it comes down to starting with the business question, not the methodology.

The analysts who thrive in this environment won't necessarily be the most technically advanced. They'll be the ones who can walk into a room with a 58-year-old VP and a 24-year-old associate, read the room correctly, and explain the same finding in two completely different ways without making either person feel talked down to.

That's not soft. That's the job

It starts fine:

Store Count = DISTINCTCOUNT(Facts[StoreID])

Then a fix. Then a fix for the fix. Six months later there's a comment block that starts with "DO NOT CHANGE THIS" and nobody knows why.

Totals misbehaving is almost always a relationship problem - many-to-many with no bridge table. Add the bridge and the ISINSCOPE hack goes away. Measures filtering things they shouldn't need to filter is an ETL problem - if the fact table was clean, the measure wouldn't need to know about active records or deduplication at all.

If a measure needs to figure out which visual it's in before it can calculate anything, that's the model not doing its job.

Other stuff that belongs upstream

Mixed-grain fact table - split it at ETL, not with IF(ISINSCOPE(...))

No date dimension - add one. Stop calculating date logic inside measures

Attribute in the wrong table - move it in Power Query, don't LOOKUPVALUE it at query time on every row

Aggregation that belongs at the source - pre-aggregate at the warehouse, not in a measure that recalculates on every render

Multiple versions of the same measure for different visuals - the model isn't providing consistent structure

How to spot it

• New requirements keep modifying existing measures instead of adding new ones
• A simple question needs 30 lines to answer correctly
• You can't explain what a measure does without also explaining which visual it was built for

Every workaround makes the next one harder. The person who wrote those comment blocks is gone, and now nobody knows why the overrides exist. Documentation doesn't fix that.

10 simple measures is easier to maintain for 3 years than 4 complex ones.

For decades, a bachelor's degree was the most reliable signal an employer could get. It didn't necessarily mean you were smart or capable - it meant you were capable enough to finish something hard, follow through, and operate in structured environments. That signal carried weight.

It's not carrying the same weight anymore.

The 2026 Human Edge report buries this finding without much fanfare, but it's worth sitting with: the employment advantage of a degree has eroded to a 30-year low. A combination of AI tools, skills-based hiring, and project-based work has made credentials less legible as a proxy for actual ability. Companies increasingly care what you can do in the next sprint, not what institution you attended six years ago.

For data analysts, this is a strange moment. The field spent years building academic legitimacy - statistics degrees, comp sci minors, master's programs in data science. And now the credential ladder is wobbling for everyone. If a degree no longer differentiates you, something else has to. And unlike fields where prestige still travels through institutions, analytics is one of the few areas where your actual output is usually visible and verifiable.

Which means analysts are weirdly well-positioned to adapt - if they treat their work as a portfolio rather than a job history.

A few things that seem to actually be filling the credential gap right now:

Work that lives somewhere public. An analysis posted somewhere, a write-up of a problem you solved, a dashboard someone can actually click through. Anything that lets a hiring manager evaluate your thinking directly instead of inferring it from a degree. In analytics specifically, the gap between "I know how to do this" and "here's proof I've done it" is smaller than in almost any other field.

Domain expertise, not just technical skills. Not "I know SQL and Python" - everyone knows SQL and Python. But "I've spent three years modeling retention in B2B SaaS" or "I know how e-commerce attribution actually breaks in practice" - that's specific enough to be useful and hard to fake.

Visibility inside a community. The analysts who get referred for interesting work aren't always the most credentialed. They're the ones who show up consistently in the places where the work gets discussed - a Slack group, a newsletter, a subreddit, a conference they've spoken at once.

The shift isn't that education stopped mattering. It's that the credential alone stopped being enough to carry you. The good news for analysts is that this field has always rewarded people who could show their work. Now the rest of the market is catching up to that logic

BI people often complain that business teams see them as “dashboard monkeys”. But if we’re completely honest, BI teams sometimes create this perception themselves.

Expample 1: Stakeholder: “Can you send me campaign performance data?” BI: sends CSV export.

WOW!

Now the stakeholder has: another spreadsheet, another version of the metric, another manually built report.

Two weeks later everybody asks why numbers don’t match across dashboards. Well, because nobody stopped to ask: “What are you actually trying to decide?”

Example 2: Business: “We need to understand why retention dropped.” BI: starts explaining joins, dbt models, refresh logic, attribution definitions, filter behavior.

But nobody answers the real business question.

A lot of BI communication is technically accurate - but its the accuracy that hides analyst from business problem.

Example 3: Stakeholder: “Can we visualize how revenue changed from last quarter?”

BI: “Technically Power BI/Tableau doesn’t support this natively…”

What could actually work:

Option 1: stacked bar with a running total column - builds in 20 minutes, works for most stakeholders, no custom visuals needed

Option 2: custom visual from AppSource - looks exactly like a waterfall, takes a couple of hours, harder to maintain when the data model changes

That's the answer. Two options, tradeoffs stated, stakeholder picks. The "not supported natively" part is irrelevant to them.

New workforce research predicts that mandatory return-to-office policies will become "virtually unenforceable" by the early 2030s - because climate disruptions and geopolitical instability will make centralized offices logistically impossible. The distributed work era isn't ending. It's just on a very awkward pause.

Which means the people quietly building remote-ready skills and habits right now are positioning themselves better than they probably realize.

The logic in the report is straightforward: extreme heat events, flooding, and supply chain disruptions are already forcing ad hoc remote arrangements across industries. Geopolitical instability is making certain office locations genuinely risky. Companies that invested heavily in "return to office" infrastructure are going to find themselves holding a very expensive assumption. And knowledge workers - analysts, developers, strategists - are the most natural candidates for distributed work when that shift accelerates again.

A few things worth thinking about if you're in this space:

Your async communication skills matter more than your in-person presence. The people who thrive in distributed teams aren't just comfortable working alone - they write clearly, document decisions, and don't create bottlenecks that require a meeting to resolve.

Building a strong external reputation now is cheap insurance. When the office isn't the default, visibility inside your company becomes harder to maintain. People who have a presence outside it - a portfolio, a community, a track record that lives somewhere other than internal Slack - have more options.

Remote infrastructure is a skill. Knowing how to run a distributed project, across time zones, with clear ownership and minimal coordination overhead, is genuinely hard. The people who've figured it out will be in demand when the next wave of distributed work hits.

The companies currently fighting hardest for RTO aren't winning a culture war. They're burning goodwill on a policy that the next decade will quietly retire anyway

The 2026 Human Edge report is pretty direct about it: blind automation is the wrong path and will lead to business failures, and very quiclek.

Most AI failures aren't dramatic. The model doesn't go rogue. It just produces something slightly wrong, nobody catches it, and that error compounds through a pipeline until it's a real problem - a bad forecast, a flawed report, a decision built on garbage data. The failure is the missing human who would have noticed.

Which is why the role actually gaining value right now isn't "prompt engineer." It's the person with enough domain expertise to sense when an output doesn't smell right, even before they can explain why.

A few things that genuinely help here:

Knowing which errors to expect from which systems. LLMs hallucinate. Recommendation models amplify existing bias. Forecasting models quietly drift when the underlying data changes. These aren't random failures - they're predictable ones.

Domain depth over tool fluency. The people who catch AI mistakes aren't always the best at using AI. They're the ones who know the subject matter well enough to notice when something is off.

The companies that will struggle aren't the slow adopters. They're the ones moving fast while hollowing out the human expertise that made their outputs trustworthy. By the time they realize it, that institutional knowledge is already gone

A new global workforce report found that 39% of core job skills will change by 2030 - and the fastest-growing ones aren't technical. They're complex problem-solving, intuition, cognitive flexibility, and creativity. The things we used to dismiss as "soft skills" or "pre-industrial" are becoming the actual competitive edge in an AI-saturated market.

Think about what that means. The last two years were dominated by anxiety about Python, SQL, and whether your job title would survive the next model release. Meanwhile, the skills that are quietly becoming irreplaceable are the ones algorithms still can't fake: genuine curiosity, the ability to reframe a problem, knowing what question to ask before you run the analysis.

The report is pretty direct about why: true AI literacy won't mean less thinking. It will require more. Someone still has to decide what the output means, whether to trust it, and what to do when it's confidently wrong. That someone needs judgment - not just prompts.

The people who spent 2023 and 2024 optimizing for tool fluency may have been solving the wrong problem entirely.

I’ve just read the Gartner report on AI & Data predictions for 2026 (maybe i shouldnt have) and honestly… it feels a bit schizophrenic.

Like everyone is out there colonizing the future - AI agents, autonomous decisioning, fully data-driven orgs - while in my company we still can’t fix basic master data.

We’re talking about self-healing systems, but our product hierarchies are still broken and no one trusts the numbers.

Feels like we’re skipping a few steps.