I just want to share what I think is the biggest challenge in entering the data field as a first-timer, perhaps a career shifter or a fresh grad (like me).

Assuming you already had the chops to do the job at its most fundamental level as well as the tools that go along with it.

The biggest challenge (at least for me) is understanding the data in your specific domain.

It’s easy to know a company by the way it creates value; you can even state the mission statement that they have in a sentence or two.

But the data terminologies that they have may not be that intuitive to understand, and the root cause of that complexity all comes down to this: no documentation.

Depending on the company that you’re working for, there may already be documentation in place; this is eminent in multinational companies, but for a local company, I think it’s more usual that there is no documentation.

You could always understand the data by asking your team and the developers, but putting myself in a developer’s perspective, there may be data fields that require context to understand, and that context, more often than not, has a story behind it (a business one). If there are many data fields, then it’s already worth a two-hour knowledge-sharing session, which is time you are taking away from a developer.

Having documentation—a written resource that outlines essential company information from the business’s functions, departments, metrics, up to data architecture and backend operations—can significantly impact a new hire’s understanding. A well-written document addressing common questions from new hires (technical or non-technical) makes a difference in understanding the company holistically in one week versus three months.

Now, I’ll admit that I’m a little bit biased about this opinion because I like to write and I like to read. But it is one of those chores that do not move the business forward, but it supplies knowledge to the people who are about to move the business forward. 🫳🎤