Most mid-sized employers do not start by choosing a data architecture. They start by hiring someone called a data analyst or a data engineer, and then find out the person was the wrong fit for the system they actually have.
The reason is simple. A data lake and a data warehouse need different people. If you pick the hire before you understand the storage, you pay for it in months of rework.
The two setups in plain terms
A data warehouse holds cleaned, organized data, mostly tables of transactions and reference information. It exists to answer known questions: monthly sales, inventory turns, margin by product line. Managers and analysts use it through reports and dashboards.
A data lake holds data in its raw form, structured or not. Sensor readings, logs, documents, exports from older systems. Nobody has decided yet what it is for. Engineers and data scientists work in it to build models or find patterns nobody planned for.
Many companies end up with both, or with a combined setup often called a lakehouse. That is fine. It just means you need to be clear about which part of the work is open.
What each setup asks of your team
| Setup | Core roles | What the work looks like |
|---|---|---|
| Warehouse | BI analyst, data modeller, reporting developer | Defining metrics, cleaning inputs, keeping reports consistent |
| Lake | Data engineer, data scientist, ML engineer | Building pipelines, preparing raw data, testing models |
| Both | Data engineer plus analyst, ideally a lead who owns the whole flow | Moving data between the two and keeping definitions aligned |
A strong report builder is often a poor fit for a raw-data environment. A strong engineer may get bored maintaining finance reports. Neither is a flaw in the person. It is a mismatch in the job.
Where this shows up by function
Manufacturing and operations. Plant sensors and machine data pile up quickly and rarely arrive tidy. If you want predictive maintenance, you need someone who can handle that raw feed. If you want a weekly view of scrap, downtime and on-time shipments, you need someone who can build a trusted reporting layer from the ERP and the floor systems.
Finance. Controllers need numbers that tie out. That points to a warehouse and to analysts who understand accounting logic, not only SQL. A finance team that cannot trust its own reports will rebuild them in spreadsheets, and the data investment is wasted.
Sales. Pipeline reporting is warehouse work. Churn prediction or pricing models are lake work. Many sales leaders ask for the second when the first is still broken.
AI and data. Any serious machine learning project depends on the plumbing under it. Hiring a data scientist before there is a data engineer is one of the most common and costly sequencing errors we see.
Hire in the right order
For most mid-sized employers, this sequence holds up:
- Start with the business question. Write down the five decisions you want better data for. That tells you whether you need reporting, modelling or both.
- Hire the engineer or architect first if your data is scattered across systems. One capable person who can connect sources is worth more than three analysts working from different exports.
- Add analysts once the data is reliable. They will be faster and stay longer when the inputs are clean.
- Bring in data science last, and only with a defined use case.
- Name an owner. Someone has to be responsible for definitions. Without that, two departments will report two different revenue figures.
Consider contract help for the build
The heavy lifting of setting up pipelines and a reporting layer is often a project, not a permanent job. A contract data engineer for 6 to 12 months can build the foundation, document it, and hand it to a smaller permanent team. That avoids hiring a senior specialist you will not need at full capacity once the build is done.
The risk is a build nobody inside the company understands. Require documentation and a named internal counterpart from day one.
Questions to ask in the interview
- Describe a pipeline you built and what broke in the first 90 days.
- How did you decide which data to clean up front and which to leave raw?
- Tell me about a time two teams disagreed on a metric. What happened?
- What would you want to know about our systems before writing any code?
Good candidates answer with specifics and ask about your business before your tools. Weak ones list platforms.
What to do next
Before you open a requisition, write one page: the decisions you want to improve, the systems the data sits in, and who will own it once it is built. That page will tell you whether you need an engineer, an analyst, a contractor or some mix. If you want help turning it into a role and finding people who have done it in Canada or the US, a Traverse recruiter can help with that.