Key Takeaways
- The only data person at a company creates the most value by solving immediate business decision problems, not by trying to build a perfect platform from day one.
- Rebuilding everything at once usually delays visible impact. Incremental improvements are more effective in messy, early-stage environments.
- Ad hoc requests need lightweight structure early, or they will consume the time needed to build durable reporting and data systems.
- Metrics and definitions should be shaped with business stakeholders, not decided in isolation by the data function.
- Documentation is part of the work. It preserves trust, reduces repeated explanations, and makes analytics usable beyond one person.
Being the only data person at a company is often framed as an opportunity. You get ownership, autonomy, and the chance to build something from the ground up. In practice, it tends to feel very different.
Data is scattered across spreadsheets, SaaS tools, and loosely managed databases. Different teams have their own definitions of the same metrics. Leadership wants visibility but cannot clearly articulate what that means. At the same time, requests come in constantly, each one framed as urgent, each one interrupting whatever you were working on before.
It is easy in this situation to default to building. Building pipelines, building infrastructure, building what you think a proper data platform should look like. That instinct is understandable, but it often leads to months of work with very little visible impact.
Working effectively as the only data person is less about building the ideal system and more about making deliberate tradeoffs. The goal is not perfection. The goal is to create clarity and deliver value quickly enough that the business begins to trust and rely on data.
There are a few principles that make this significantly easier.
1. Do not rebuild everything at once
When you step into a messy environment, the instinct is to fix it properly. That usually translates into some version of a full rebuild. New tools, new architecture, new pipelines, a clean foundation.
The problem is not that rebuilding is inherently wrong. The problem is timing.
A full rebuild delays visible outcomes. While you are designing and implementing a better system, the business is still operating without reliable data. From their perspective, nothing has improved. Over time, this creates a gap between the effort you are putting in and the value the business can actually see.
A more effective approach is to work with what already exists and improve it incrementally. Choose tools that meet your immediate needs rather than what you believe will be ideal in the future. Focus on delivering something useful in the near term, even if it is not perfect.
In most small environments, simple solutions hold up surprisingly well. A well structured database and a few reliable pipelines will go much further than an overengineered stack that takes months to stabilize.
Complexity can be introduced later, once there is a clear need for it and the business has already seen the value of what you are building.
2. Put structure around ad hoc requests early
Ad hoc requests are unavoidable. They are a natural part of working with data, especially in organizations that do not yet have established reporting.
The issue is not the existence of these requests but the lack of structure around them.
If every request comes through a different channel and is handled immediately, your time becomes fragmented. You spend your day reacting instead of making progress on anything meaningful. Over time, this prevents you from building the systems that would reduce the volume of ad hoc work in the first place.
Introducing a simple system for requests creates clarity. This does not require heavy process. It can be as straightforward as:
- A single intake channel
- Basic prioritization
- Clear expectations for turnaround time
It is also important to define what urgency actually means in the context of the business. Without that definition, everything will default to being urgent, and you will remain in a constant reactive state.
When handled well, ad hoc work can inform what should be formalized into repeatable reporting. Without structure, it simply consumes all available time.
3. Start from decisions and work backwards
It is common to begin by thinking about pipelines, data models, and infrastructure. While these are important, they are not what the business ultimately cares about.
What matters are decisions.
Which decisions does leadership need to make regularly. What questions do teams struggle to answer today. Where is there uncertainty that could be reduced with better visibility.
Starting from these points changes how you approach the work. Instead of building pipelines and hoping they become useful, you identify the specific outputs that would enable better decisions and then work backwards to determine what data and transformations are required.
Decision → Metric → Data → Pipeline
This approach allows you to deliver value more quickly because you are targeting a specific outcome rather than building general purpose infrastructure. It also reduces the risk of building things that are technically sound but rarely used.
Many data efforts fail not because they are poorly built, but because they are disconnected from actual business needs. Focusing on decisions keeps the work grounded and ensures that each piece of engineering serves a clear purpose.
4. Work with the business to define the data
As a data person, you are responsible for structuring, transforming, and delivering data. That does not make you the authority on how the business should be defined.
Metrics, definitions, and logic all depend on how the business operates in practice. Without input from the people closest to that work, it is very easy to produce outputs that appear correct but do not reflect reality.
Establishing relationships with business stakeholders is critical. This could be someone in operations, finance, product, or any function that relies heavily on the data. The goal is not just to gather requirements, but to validate assumptions continuously.
A seemingly straightforward metric like revenue can have multiple valid interpretations depending on timing, recognition rules, or edge cases in the underlying systems. These nuances rarely surface without direct collaboration.
By involving business partners early, you ensure that what you build aligns with how the company actually thinks about its performance. This reduces rework and builds trust in the outputs you deliver.
5. Treat documentation as part of the work, not an afterthought
When you are the only data person, documentation becomes essential. It is not just a record of what you have built. It is how your work becomes understandable and usable by others.
Effective documentation goes beyond technical details. It should not only describe tables, columns, or transformations. It should explain the business context behind the data.
For each important dataset or dashboard, the documentation should clearly answer:
- What each metric represents
- How it is calculated
- Which business definition it follows
- What assumptions are included
- Where the data originates
Someone from the business should be able to read this documentation and understand how the analytics were built and what each number means.
Documentation is how you translate business intelligence into something durable. It ensures that the approach you and the business agreed on is clearly captured and consistently understood.
Without this, you will find yourself explaining the same logic repeatedly, dealing with conflicting interpretations, and slowly losing trust in the numbers being produced.
Good documentation prevents that. It scales your work beyond your own time.
What You’re Really Being Asked to Do
Working as the only data person is often framed as building a data platform, but that is rarely the real expectation, even if it is how the role is described.
What the business actually needs is clarity. It needs consistency. It needs a way to trust the numbers it is using to make decisions.
That does not come from a perfect architecture or the right combination of tools. It comes from steady progress. From choosing what matters, delivering it, and making it understandable to the people who rely on it.
Over time, the systems you build will improve. The architecture will evolve. The tooling can change. What matters early on is that the business starts to feel the impact of data in a tangible way.
If you focus on that, you create momentum. And once there is momentum, everything else becomes easier to justify, easier to prioritize, and easier to build.
That is the job, whether it is written that way or not.