Common Business Analyst Pitfalls (And How To Climb Out)

I had coffee with a BA last month. Fourteen months on the job. Sharp, fast, well-liked. She told me she was "drowning in requests": sixty-plus tickets a quarter, weekends bleeding into Mondays, no end in sight.

I asked her one question: name a decision your work changed last quarter.

She couldn't. Not one. She had shipped 47 dashboards, answered 312 Slack pings, written queries that would make a senior engineer nod. And she could not name a single decision that went differently because of any of it.

That gap is the whole article. It's also the difference between the BA who gets promoted in year two and the one who's still running ad-hoc queries in year four.

Why your second year is the fork

Most BAs survive year one on raw effort. You learn the schema, you memorize the dashboards, you figure out who actually owns what. Output looks like progress because everything is new.

Year two is different. The schema isn't new anymore. The output looks the same as year one (same queries, same dashboards, same Slack threads), but now it's expected. Effort stops translating into visibility. You either compound (your work starts removing decisions from other people's plates) or you plateau (you become a faster version of the help desk).

The fork happens quietly. Most people don't notice they took the wrong path until review season, when their manager says some version of "you're doing great work, but I need to see more strategic impact." That's the manager telling you, in the politest possible language, that they can't tell what your work changed.

Here are the seven pitfalls that put you on the plateau path. Each one has a symptom you can spot in your own week, a number you can measure, and a fix you can run on Monday.

Pitfall 1: Becoming the help desk

Symptom. Your DMs look like a queue. "Quick question, can you pull X?" "Sorry to bother you, but does Y include Z?" You answer because answering is fast and saying no feels rude. Then you wonder why you can't get to the strategic project.

The number. In my experience, a BA who becomes the help desk spends 12-18 hours a week on ad-hoc requests. That's a quarter to a third of your week, every week, evaporated into questions that mostly have the same five answers.

The fix. Stop answering individual pings. Start a #analytics-help channel and route every DM there with one line: "Posting in #analytics-help so others can see the answer." Within two weeks you'll see the same five questions repeating. Build a self-serve doc or a Looker board that answers them, link to it, and watch your queue shrink.

The hard part isn't the channel. It's saying "this should be self-serve" to a VP without sounding like you're refusing work. The phrasing that works: "Happy to pull this once. To keep it from blocking your next ten asks, I'll add it to the [team dashboard] by Friday so you can grab it yourself going forward." You answered the request. You also moved the work from "your queue forever" to "your queue once."

Pitfall 2: Skipping requirements signoff

Symptom. A stakeholder describes what they want in a 20-minute call. You nod, take notes, go build it. Two weeks later they look at it and say "oh, but I also need it broken out by region" or "wait, this is monthly. I needed weekly." You rebuild. They're "almost there." You rebuild again.

The number. Each rebuild costs 4-12 hours. Three rebuild cycles on a single dashboard = a full week of your time, and the stakeholder still isn't sure they trust the numbers.

The fix. Before you write a single query, send a one-page requirements doc with three sections: Decision (what action will this work enable, and who makes it), Definition (what counts as a "lead," "active user," "churn," agreed in writing), and Done (what does this look like when it ships, with a sketch). Get a thumbs-up in writing on all three. If the stakeholder won't read a one-pager, that's your signal the request isn't serious enough to build.

The signoff doc isn't bureaucracy. It's a forcing function that turns "I want a dashboard" into "I want to decide X every Monday and need Y to do it." Ninety percent of scope creep dies in that translation.

Pitfall 3: Building dashboards before defining the decision

Symptom. You ship a dashboard. It has 14 charts, 6 filters, color-coded everything. The stakeholder says "this is amazing, thank you." Three weeks later, when you check, it's been opened twice. Both times by you.

The number. Across most BI tools, the median dashboard gets viewed fewer than 5 times a month after the first month. If "the customer loved it" doesn't match "the customer uses it," the dashboard didn't have a real decision attached.

The fix. Before you open Tableau or Looker, write one sentence at the top of your scratch doc: "This dashboard exists so that [role] can decide [action] every [cadence]." If you can't fill in all three blanks, you don't have a dashboard. You have a vague request to make a thing.

Examples that pass the test:

"This dashboard exists so the Sales VP can decide which two regions get headcount this quarter every Monday morning."
"This dashboard exists so the CS lead can decide which 5 accounts to call this week every Tuesday at 9am."

Examples that fail:

"This dashboard exists so leadership has visibility into the funnel."
"This is a marketing performance dashboard."

If the decision isn't named, the dashboard becomes wallpaper.

Pitfall 4: Over-relying on Excel exports

Symptom. You pull data into Excel because the stakeholder wants "to play with it." You build a pivot table. You add a vlookup. You email the file. Two weeks later the stakeholder shares it in a meeting and the numbers are wrong, but they're wrong in a way nobody can reproduce because they're nested in a sheet that lives in someone's Downloads folder.

The number. Excel-as-source-of-truth costs you reputation more than hours. One bad number in a board deck and your "data partner" status takes six months to rebuild.

The fix. Excel is fine for a one-shot exploration. It is not fine as a recurring report. The rule I use: if you've sent the same Excel file twice, the third version has to live in the BI tool, with the SQL committed somewhere a colleague could find it.

Rework's productivity tools and most BI platforms can replace 80% of recurring Excel exports with a scheduled report. The remaining 20% is genuine ad-hoc analysis, and that's where Excel earns its keep. Don't fight Excel. Fight Excel-as-a-pipeline.

Pitfall 5: No version control on SQL/dbt models

Symptom. You open your queries folder and find customer_metrics.sql, customer_metrics_v2.sql, customer_metrics_FINAL.sql, customer_metrics_FINAL_USE_THIS.sql, and a haunting customer_metrics_old_DO_NOT_USE.sql. None of them produce the same numbers. You don't remember which one you ran in last quarter's board deck.

The number. Time spent reconciling "why does my number not match yours" easily hits 3-5 hours a month. More if you're the analyst who has to defend the number in a leadership meeting.

The fix. Put your SQL in git. I don't care if it's a private repo, a shared dbt project, or a folder synced to a cloud drive. Version it, commit it, and stop using filenames as version control. If you're already on dbt, this is free; you just have to stop bypassing it with one-off queries in the BI tool.

A minimum viable setup for a solo BA:

ba-queries/
  models/
    revenue/
      monthly_revenue.sql
      arr_by_segment.sql
    customers/
      active_customer_definition.sql
  README.md   # what each model means, who owns each definition

Commit every change. Reference the commit hash when someone asks "where did this number come from." That habit alone shifts you from "the analyst" to "the analyst who can defend their numbers in a board meeting." Those are two different jobs and they pay differently.

Pitfall 6: Ignoring deprecation reviews

Symptom. You open Looker. You count your dashboards. There are 47. You actively maintain 9. You can name 3 from memory. The other 44 are still "live," still pulling data every morning, still showing up in the catalog when stakeholders search.

The number. Across teams I've worked with, 30-50% of dashboards haven't been opened in 90 days. They're still costing compute, still confusing new hires, still creating "wait, which one is the right one" moments in meetings.

The fix. Run a quarterly deprecation review. It takes one afternoon. Pull a usage report from your BI tool, sort by last_viewed_at, and for anything older than 90 days do one of three things:

Archive if nobody owns it.
Promote if it's the canonical version of a recurring metric (move it to a "core" folder, lock the definitions).
Merge if there are three near-duplicates that should be one.

The first time you do this you'll archive 20+ dashboards and nothing bad will happen. That's the point. The catalog gets cleaner, your queries run faster, and new hires can actually find the right dashboard without asking you.

Pitfall 7: Measuring usage without decision impact

Symptom. Your manager asks how the analytics function is doing. You say "the executive dashboard had 1,200 views last month." She nods and asks a different question.

The number. "1,200 views" is impressive until you ask: views by whom, leading to what action, with what outcome? If the answer is "I don't know, but the chart is up and to the right," you measured the wrong thing.

The fix. Switch your reporting from usage metrics to decision metrics. For your top five dashboards, name:

The decision the dashboard supports (Pitfall 3, same exercise)
The cadence of that decision (weekly, monthly, quarterly)
One example, in the last quarter, where the dashboard changed the call

That last one is the killer. If you can't name a single example where the dashboard changed a call, the dashboard is decoration. If you can name three or four across your top five, you're not a report jockey anymore. You're an analyst whose work changed money.

When review season comes, "the marketing leadership team reallocated $400K from paid social to organic in March based on the channel attribution dashboard I built" is a sentence that gets you promoted. "1,200 views" is a sentence that gets you a thank-you and the same title.

The pattern underneath

If you reread the seven pitfalls, they all share one root: optimizing for output instead of decisions.

Help-desk = output (tickets closed)
No signoff = output (build fast, build wrong)
Dashboards before decisions = output (charts shipped)
Excel exports = output (files emailed)
No version control = output (queries written, not understood)
No deprecation = output (catalog grows, never shrinks)
Usage without impact = output (views measured, not value)

Reframe the job. You are not paid to write queries, ship dashboards, or close tickets. You are paid to reduce decision latency for the business. Take decisions that used to need a meeting and make them takeable from a chart. Take decisions that used to take a week and make them takeable in a day.

Every hour of your week should map to that. If it doesn't, it's overhead, and overhead doesn't compound.

A 30-day climb-out plan

You can't fix all seven at once. Try this instead:

Week 1: Stop the bleeding. Set up your #analytics-help channel. Move every DM there. Write a one-pager template for requirements signoff. Commit to using it on the next two requests, no exceptions.

Week 2: Earn back trust. Pick your three most-viewed dashboards. For each, write the "this exists so that [role] decides [action] every [cadence]" sentence. If you can't fill it in, schedule a 20-minute conversation with the owner to find out. Update the dashboard description with the sentence.

Week 3: Clean the house. Get your SQL into a git repo, even a private one. Move at least the queries powering your top three dashboards. Run a deprecation review. List every dashboard you own, mark each as Archive / Promote / Merge.

Week 4: Show the work. Pull your last quarter and write three "decision impact" sentences. Real ones. ("X team reallocated Y based on Z analysis I shipped.") If you can't write three, that's diagnostic. Your next quarter's plan is making three real ones happen.

The Friday self-audit. Every Friday, before you log off, ask yourself three questions:

What decision did my work change this week?
What request did I take that should have been self-serve?
What's one dashboard I should archive next week?

Three minutes, three questions. The questions don't change. Your answers, over six months, will.

Closing

The BA at the start of this article, the one who couldn't name a decision her work had changed, wasn't bad at her job. She was great at it. She was exceptional at the surface job (close the ticket, ship the dashboard, answer the ping) and underwater on the actual job (remove decision latency from the business).

The pitfalls in this article aren't intelligence problems. They're attention problems. You drift into them not because you're lazy, but because the surface job feels productive in the moment and the actual job feels invisible until review season.

Pick one pitfall this week. Fix it before Friday. The promotion isn't going to come from doing more. It's going to come from doing the things that change decisions, and saying no (politely, in writing) to everything else.

Business Analyst Guide