Two different problems that sound identical
A dashboard solves a presentation problem: the number exists, it is correct, and getting it in front of people is slow or manual. A data engineer solves a plumbing problem: the number does not exist reliably, or it exists in four systems that disagree, and no amount of visualization will fix that. Both problems arrive in the same sentence from the same person, and the cost difference between them is roughly tenfold. Almost every unhappy analytics engagement we are asked to look at began with someone confidently buying the wrong one.
The error runs in both directions, and they fail differently. Buying a dashboard when you had a plumbing problem produces a beautiful, fast, widely-viewed wrong number, and the wrongness is now everybody's, which is worse than before. Hiring an engineer when you had a presentation problem produces three months of infrastructure to serve a report an analyst could have built in a week, and the sponsor loses patience before anything visible ships.
You are probably here because
- Someone asked for a dashboard and you are not sure that is really the ask
- You have a quote for a reporting tool and a quote for three months of engineering
- A monthly report takes two people three days and you want that back
- You bought the tool, it is live, and nobody trusts what it shows
The test in the next section settles it in about an hour, using people you already employ.
The test that settles it in an afternoon
Pick the number that matters most. Ask the person who currently produces it to make it for last month while you watch, and time it. Then ask four questions, in this order.
Can they produce it at all? If nobody can build the number by hand from the source systems, no tool will build it either. A dashboard displays what a query returns; if the query cannot be written because the data is not there, is not joinable, or is not recorded, you have an engineering problem before you have a reporting one.
How long does it take? Under an hour and it is a presentation problem: automate the presentation and move on. Half a day or more, especially if it involves exporting from several systems and matching things up by hand, and the work is happening because the underlying data is not connected. Connecting it is engineering.
Is the manual answer trusted? If the person who makes it says it is right and the rest of the leadership team agrees, the number is sound and you are automating something that works. If two people produce different answers, you have a definition or a data problem, and building a dashboard now just picks one side of an unresolved argument and publishes it.
How many systems did they open? One system is nearly always a presentation problem. Two is usually still manageable in a reporting tool. Three or more, especially when matching records across them requires judgment — the same customer named two ways, an order that becomes an invoice under a different identifier — and you are in engineering territory whether you wanted to be or not.
| What you observe | What it is | What to buy |
|---|---|---|
| One system, correct number, slow to distribute | Presentation | A reporting tool and a few days of setup |
| Two systems, one manual match, number trusted | Mostly presentation | A small amount of modeling under the tool |
| Three or more systems matched by hand each month | Plumbing | A data engineer, then a dashboard |
| Two competent people, two different answers | Definitions | An afternoon of writing, before anything else |
| Nobody can produce it by hand at all | Collection | Change the source system first |
| The number is right but a month late | Process | Scheduling and alerting, not a new tool |
The last row catches more companies than expected. A monthly figure that is correct but arrives on the twentieth is not a data problem at all; it is a close process, and the fix is upstream in finance or operations. A dashboard pointed at data that only lands on the twentieth will be empty until the twentieth, which surprises people who assumed the tool would make it earlier.
A dashboard is the right answer more often than vendors admit
There is a strong professional bias in this industry toward finding the deeper problem, and it is worth naming, because we have it too. Engineers see a manual report and think about the platform it implies. Frequently the honest answer is that a competent analyst with the reporting tool you already own can produce the thing in a week, for a few thousand dollars, and it will serve for two years.
That is a genuinely good outcome, and it is the recommendation whenever the number is trusted, comes from one or two systems, and the pain is distribution rather than correctness. It also has a property that big builds do not: you find out within two weeks whether anyone actually looks at it. A surprising number of urgently-requested reports go unopened after the first month, and discovering that for six thousand dollars rather than a hundred and sixty is a good trade.
The signals that point to engineering
None of these on its own settles it. Three or more together and the plumbing is the real work, and buying a reporting tool first will waste the tool's first year.
Signals that the work is engineering, not presentation — our weighting
How strongly each signal predicts that a reporting tool alone will not be enough. Our judgment from diagnostic work, not a survey.
The third row is the one non-technical buyers most often miss, and it is unrecoverable if left too long. Many operational systems store only the current state: a deal shows its status today, and last quarter's status is simply gone. If you want to know how the pipeline looked in March, something has to have been capturing it since March. No tool can reconstruct that later. If historical trend is on your list, capturing history is urgent in a way nothing else here is.
What a data engineer does that a tool cannot
Gets the data out reliably, on a schedule, and tells you when it fails. Every source has its own quirks: an API with rate limits, a database you must not slow down during business hours, a vendor that emails a file that is sometimes late and occasionally malformed. Handling that predictably is most of the job, and it is the part reporting tools are worst at.
Decides what is the same thing. The customer in the CRM, the account in billing and the organization in the support tool are one company with three names and no shared identifier. Someone has to decide the matching rules, handle what does not match, and make the decisions reviewable rather than buried.
Keeps history the source systems throw away. Snapshots, change tracking, and the ability to answer what a figure looked like on a past date rather than only what it is now.
Makes the thing survive change. Tests that catch a load that ran but produced half the rows, alerting that reaches a person, and code written so the next engineer can read it. This is the difference between a platform that is fine in year two and one that quietly stops being trusted.
What each costs and how long it takes
| Option | Typical cost | Elapsed time | Best when |
|---|---|---|---|
| Reports in a tool you own Analyst work, no new infrastructure | $3,000–$15,000 | 1–3 weeks | Number trusted, one or two systems |
| Modeling under the existing tool Clean tables, defined metrics, scheduled | $15,000–$45,000 | 3–6 weeks | Two or three systems, mostly trusted |
| A first data platform Loads, model, tests, reports | $45,000–$150,000 | 8–16 weeks | Three or more systems, manual matching |
| A full-time data engineer Salary plus overhead | $150,000–$220,000 a year | 3–6 months to hire | Ongoing demand, someone to manage them |
Those assume senior engineers at US rates, which for this work generally run $150 to $250 an hour however they are billed. The hiring row deserves a caution that has nothing to do with money: a single data hire is a single point of failure, they will design the platform they know rather than the one you need, and if nobody in the company can evaluate their work, you will not find out for a year. If you hire one, arrange for someone outside to review the design early. That is a two-day engagement and it is the cheapest insurance in this article.
The middle path most companies at this size need
The two options are usually presented as opposites and the answer is usually between them: a modest amount of engineering underneath the reporting tool you already have. Land the data from each system into one place on a schedule. Build a small number of clean, well-named tables that mean what the business says they mean. Point the existing tool at those. Nobody buys a new platform, nobody hires, and the report stops being rebuilt by hand.
Three to six weeks of one engineer covers this for most companies with two or three sources, and it has an underrated property: it makes the later decision cheap. If you outgrow it, the clean tables are exactly what a bigger platform would need anyway, so nothing is thrown away. Starting here is rarely the wrong move, which is not true of either extreme.
Not sure which one you have?
Email the number you care about, the systems it comes from, and how long it takes someone to produce today to contact@precisionfederal.com. You get a written answer on which of the four options fits and roughly what it would take, in one business day. No charge and no meeting.
contact@precisionfederal.comThe third answer nobody offers you
Sometimes neither is the right hire, because the actual need is an analyst — someone who can ask the business what decision the number supports, write the query, and explain the result to a skeptical executive. Engineers build the road. Analysts drive on it and come back with something useful. Companies routinely hire an engineer, get excellent plumbing, and discover nobody is asking questions of it.
A quick way to tell: if your existing reports get looked at and generate follow-up questions nobody has time to answer, you need analyst capacity. If your reports are correct, timely and ignored, you have a management problem and no hire fixes it. If people want reports that cannot currently be built, that is engineering. The three are distinguishable in a single conversation with the people who use the numbers, and that conversation is almost never held before the budget is set.
Sequencing, when you need more than one
The order that wastes the least money
Step two is out of order deliberately. Capturing history is the only item on the list that gets more expensive the longer you wait, because the data you did not capture in March cannot be recovered in June. Everything else can wait a quarter with no penalty. If you do nothing else this month, find out which of your systems overwrite their own state and start keeping snapshots.
How to brief whichever you hire
- The decision the number supports, not just the number
- Who produces it today and how long it takes them
- Every system it touches, including the spreadsheet on someone's laptop
- Whether history matters, and how far back
- Who is allowed to see it, if that varies by person
- How fresh it has to be — daily by 8 a.m. is a different job from within the hour
- What you will compare the result against to decide it is right
The last item is the one that separates a good engagement from an argument. Name the existing number the new one will be reconciled against, before work starts. Without it, delivery becomes a debate about whose figure is correct, held at the end, with the invoice already issued.
Mistakes we get called in to unwind
- Buying the reporting tool first, then discovering the data behind it does not join
- Hiring an engineer with nobody to direct them, and getting infrastructure without reports
- Automating a monthly report that nobody had read in a year
- Skipping history capture, then needing a trend nobody can reconstruct
- Pointing dashboards straight at the production database and slowing the business at month end
- Treating a definitions disagreement as a tooling gap and buying software to settle it
- Shipping without reconciling against the number people already use
Bottom line
Ask whether the number exists, whether it is trusted, how long it takes to make and how many systems it crosses. One system, trusted, an hour of work: buy the report and be happy. Three systems matched by hand, or two people who disagree: no dashboard will help you, and buying one will spread the problem further and faster. Most companies between twenty and three hundred people land in the middle and need a few weeks of engineering under the tool they already own, which is the cheapest move available and the one nobody sells hard, because it is small.
Objections and edge cases
Our reporting tool claims it can connect to everything itself.
It probably can, and connecting is the easy part. What the tool will not do is decide that the customer in one system is the account in another, keep history the source overwrites, tell you when a nightly load silently returned half the rows, or stop thirty dashboards from querying your production database at once. Direct connections are excellent for one or two clean sources and get fragile fast beyond that.
Can we skip the engineering by exporting to spreadsheets on a schedule?
For a while, genuinely yes, and we would rather someone did that than spent six figures prematurely. It stops working when the exports get large enough to be slow, when someone edits one by hand and the edit is lost on the next refresh, or when you need last year's version and nobody kept it. Treat it as a deliberate interim step with a review date, not as the answer.
Should the first hire be an engineer or an analyst?
Whichever matches the bottleneck. If people are asking questions of existing reports and nobody can answer them, hire the analyst. If people want reports that cannot be built from the data as it stands, hire the engineer. A common and reasonable move at this size is one outside engineer for a defined build plus one internal analyst who inherits it, rather than two permanent technical hires at once.
We already spent $80,000 and nobody trusts the result. Now what?
Do not rebuild yet. Take the three numbers people distrust most and reconcile each against whatever they use instead, line by line, until every difference is explained. That is usually one to two weeks and it produces a specific list: this is a definition disagreement, this is a broken join, this is a load that has been failing on Sundays. Most platforms in that state need a few targeted repairs and a written definition per metric, not a replacement.
Frequently asked questions
Watch someone produce the number by hand and time it. If they open one system, get it in under an hour, and everyone accepts the result, it is a presentation problem and a report will solve it. If they open three systems and match records by judgment, or if two competent people produce different answers, the problem is underneath the presentation layer and a dashboard will publish it rather than fix it.
Moves data out of source systems on a schedule and handles the failures, decides and implements how records from different systems are matched, keeps history that source systems overwrite, shapes raw data into tables that mean what the business says they mean, and writes the tests and alerts that catch a load which ran but produced the wrong result. Building charts is generally not their job and usually not their strength.
Over several years the arithmetic often favours the hire, at roughly $150,000 to $220,000 a year fully loaded for meaningful capacity. The costs that do not appear in that comparison are three to six months of recruiting, the risk of a single point of failure, and the fact that if nobody internally can evaluate the work you will not learn about a poor design for a long time. Many companies at this size get a better result from an outside build with an internal owner who inherits it.
Write one page per contested number saying what it means and which date governs it, then start capturing snapshots from any system that overwrites its own state. The first costs a few days of internal time and settles arguments that no software can settle. The second is the only thing on the list that gets more expensive with delay, because history you did not capture cannot be recovered later.
Usually not. Unused dashboards are typically a trust problem or a relevance problem, and both are diagnosed by asking three users what they open instead and why. If the answer is that they do not believe the numbers, reconcile the top few against the versions they do believe. If the answer is that the reports do not bear on any decision they make, that is a management question and no amount of plumbing changes it.