Tool-belt series · Problem shaping · For people who build
The hard part of building things at work was never the code — you can vibe your way through code. The hard part is that people describe problems in the language of their frustration, not in the language of what to build. This is a catalogue of the shapes underneath: what people actually say, what it really is, what to build, and how to do a scrappy version this afternoon instead of a proper version next quarter.
There are maybe sixteen problems in a business. You'll meet them over and over in different costumes — different department, different system, different vocabulary, same underlying shape. Once you can name the shape, you already know roughly what to build, and the building is the part you're good at.
Use it two ways: read it once to load the patterns into your head, then come back to it when someone corners you at a desk and you want to sound like you've seen this before. You have. It just had a different name last time.
The most expensive mistake is building the thing someone asked for instead of the thing they need. These six questions take four minutes and save weeks. Ask them in this order — the order matters, because Q1 changes the answer to everything else.
Not "what do you need" — that gets you their proposed solution. A specific recent story gets you the actual problem, the workaround they've built, and who else touches it. Always start here.
The answer is often "I copy three numbers into a slide." Then you're not building a report — you're building three numbers. Enormous amounts of work get avoided by this question.
This is the latency question, and people always overstate it. "Real time" usually means "before my 9am meeting." Daily is dramatically cheaper to build than streaming, and honesty here is worth days of your life.
If three teams do the same manual thing, you're not solving one person's problem, you're solving a company problem — which changes the priority, the design, and how much support you'll get for doing it properly.
Surfaces the real risk and the real value. "We restated a board number" is a different project from "I was mildly annoyed." It also tells you what your solution has to protect against.
Your scoping question. Their answer is your first release. Everything else is the backlog — and now it's their prioritisation, not your guess.
Sixteen shapes, grouped by what they're fundamentally about. Each one gives you the sentence people actually say, what's really going on, what to build, and the scrappy version you could have working before you go home.
I export this every month and email it round.
A manual distribution problem, and usually also an undocumented transformation problem — because between the export and the email, they do things. Filtering, renaming, a lookup they keep in another tab. That hidden work is the actual scope.
Recreate their final output as one table in a lakehouse or a view, and get it to them once. If it matches, you've validated the logic before automating anything.
Model it into gold, build a small report or a subscribed export, schedule it, and alert on failure. Retire the manual export deliberately — with them watching.
It's too much data for Excel now.
The classic on-ramp — and the easiest win you'll ever get, because the pain is already acute and they've already given up. They don't need a platform strategy, they need the file to open.
Land the data as a Delta table and point them at the SQL endpoint from Excel. Same tool they know, no row limit. Takes an hour and looks like magic.
Proper gold-layer model plus a semantic model so the aggregations are done for them, and they stop pulling millions of rows to sum one column.
Can you just add a column?
Sometimes it's just a column. Often it's a question they can't answer and a column is their guess at the fix. Ask what they'd do with it — the answer frequently reveals a measure, a different grain, or an entirely different report.
If it's genuinely a column and it's already in the source, add it. Small requests answered fast are how you earn the right to say "let's talk" on big ones.
If it's a new grain or a new source, treat it as its own small project with its own conversation. Don't smuggle it in as a tweak.
These two systems don't agree and nobody knows which is right.
A reconciliation problem, and it's the most valuable pattern in this entire page because it's the one people actively fear. The deliverable is not "which one is right" — it's a repeatable, explainable difference. Once the gap is itemised and each line has a reason, the argument stops.
Pull both sides into one place, join on the key, and produce a difference table with the ten biggest gaps. Show it to them. The reasons will start pouring out of them unprompted.
A scheduled reconciliation with categorised difference reasons (timing, mapping, missing, genuine), a tolerance threshold, and an alert when the unexplained portion exceeds it.
Nobody trusts the numbers.
Usually not accuracy — usually ambiguity. Four reports say "revenue" and mean four things, so people quietly stop believing all of them. The fix is definition and provenance, not more validation.
Take the three most argued-about measures and write one sentence each: what's included, what's excluded, as-of when. Circulate it. Watch the arguments change shape immediately.
One certified semantic model as the definition of record, endorsement so people can see which one to trust, lineage so they can see where it came from, and retirement of the duplicates.
This number looks wrong but I can't prove it.
A lineage and drill-through problem. They can see the total but not the rows behind it, so they can't self-serve the answer and have to ask you — which is why you keep getting asked.
Give them one drill-through page or a saved query that returns the underlying rows for any given total. Their next three questions answer themselves.
Keep a bronze layer so you can always show the raw as-arrived record, plus the load timestamp and source. The ability to say "here's exactly what we received" ends most disputes.
The data's a mess.
A data quality problem that nobody has ever quantified. "A mess" is a feeling. Your job is to turn it into a count — because a count can be tracked, targeted and fixed, and a feeling can't.
Write one query that counts the issues: nulls in key fields, duplicate keys, orphan references, values outside a sane range. Report it as a table. That table is now the project.
Quality checks as a scheduled step between bronze and silver, with a trend over time and an alert when a threshold breaks. Bad data stops silently, loudly.
We only found out a week later.
A detection problem, not a reporting problem. A dashboard doesn't solve it — a dashboard requires someone to look. The fix pushes to them: a rule and a message.
One threshold, one alert into Teams or email. Genuinely an hour's work, and it changes how people experience your team.
Rules on a stream or a refreshed table, with severity levels, an owner per alert, and enough context in the message to act without opening anything.
It broke and nobody noticed.
Pipeline observability — and specifically the nastiest version, where it didn't fail loudly, it succeeded with nothing in it. Silent partial failure is the one that reaches a board pack.
Add a failure notification to your most important pipeline, plus a row-count check that fails deliberately if the load is suspiciously small.
A run log table (what ran, when, how many rows, how long), a small monitoring page over it, and freshness expectations per table so "stale" is detectable.
We need this in real time.
Usually a latency mismatch, not a streaming requirement. Ask what decision changes if they see it now versus in an hour. If nothing changes, they don't want real time — they want fresh, which is far cheaper.
Increase the refresh frequency and see if the complaint stops. Often it does, and you just saved a quarter of engineering.
If a decision genuinely changes in seconds — operational monitoring, fraud, capacity — then it's a real streaming case and worth building as one.
Can we predict what next quarter looks like?
Nine times in ten: they want a trend, not a model. "Predict" is how non-technical people say "help me see where this is going." A well-built trend with seasonality beats a black box they won't trust.
Plot the history properly — same period last year, rolling average, and the run rate. Show it to them. Frequently that is the answer.
If there's a real forecast case, start with something explainable and measure it against actuals openly. A forecast nobody can interrogate gets ignored the first time it's wrong.
I need to be able to slice this myself.
A self-service modelling problem. They're not asking for a report, they're asking to stop asking you. That's a compliment and an opportunity — it's also the thing that scales your influence past your own hours.
Give them a clean table with sensible names and let them pivot it in Excel. Then watch which slices they actually use.
A star-schema semantic model with named measures and friendly field names. What you observed them doing manually becomes the dimensions.
We keep getting asked the same question.
A question-answering problem, and the newest pattern here. If the same handful of questions arrive weekly, that's a data agent or a well-named model — but only if the underlying data is modelled well. Agents expose bad modelling ruthlessly.
Write the top ten questions down. Half will be answerable from one existing table — make that table findable and say so.
A data agent over a clean gold layer, tested against those ten questions, with the failures fed back as modelling and naming fixes.
The mapping lives in Dave's spreadsheet.
Unmastered reference data — and a bus-factor risk wearing a spreadsheet costume. Cost-centre mappings, account groupings, entity hierarchies. It's small data with enormous blast radius.
Get a copy into a governed table and point a pipeline at it. Even reading from Dave's file on a schedule beats a copy pasted quarterly from memory.
A small write-back app or governed table with an owner, change history, and validation — so a bad mapping is caught at entry, not at close.
We do this by hand every close.
A process automation problem. Careful here: manual steps often encode judgement that nobody wrote down. Automating the mechanics is great; automating away the judgement quietly is how you get an error nobody catches.
Watch them do it once and write down every step, marking each as mechanical or judgement. That document is valuable on its own, whatever you build.
Automate the mechanical steps; keep the judgement steps as an explicit human approval in the flow. Faster and still signed off.
Only one person knows how to do this.
A bus-factor problem, and it's rarely presented as a request — you'll usually spot it yourself. It's also the easiest way to be genuinely useful without anyone having asked, which makes it disproportionately good for your reputation.
Sit with them and document it while they do it. One page. The act of writing it down usually surfaces two steps even they had forgotten.
Move the logic into version-controlled, scheduled, monitored code — so the knowledge lives in a repo instead of a person, and can be reviewed.
The question you'll be asked in the corridor is "how long would that take?" Being roughly right, fast, is a genuine professional skill — and these are the factors that actually drive the answer.
| Factor | Cheap when… | Expensive when… |
|---|---|---|
| Source access | Already in the lake, or shortcut-able | New system, new credentials, security review |
| Grain | Matches something you already model | New grain — new fact table, new conversations |
| Latency | Daily or weekly is genuinely fine | Sub-minute, and it must be right |
| Write-back | Read-only | Humans typing values — validation, audit, permissions |
| Consumers | One team who'll tell you when it's wrong | Executives, or anything external-facing |
| Correctness bar | Directionally right is useful | It's going in a statutory return |
Not because it's all they deserve — because it's the fastest way to find out you misunderstood. A rough version in front of someone on day one generates more useful correction than three weeks of careful specification. For a vibe coder this is your native advantage: you can get to a wrong thing quickly, and wrong things in front of users are how right things get built.
Just be explicit that it's scrappy, and be equally explicit about what "proper" would add. The failure mode isn't building it fast — it's letting a prototype quietly become production because nobody said out loud that it wasn't.
Becoming the person who builds things means becoming the person everyone asks. Reputation is built as much on what you decline well as on what you deliver.