I chose data for a reason I used to avoid saying out loud: the money mattered. I wanted a career that could pay well, open doors, and give me skills that were useful across industries. But I stayed in data for a different reason. I like the feeling of taking something messy, confusing, and ignored, then turning it into something people can actually use. That is also why I still use Excel, even while working with Python, SQL, dashboards, and machine learning tools.
For me, Excel is not a career path by itself. I am not trying to become “the Excel person” in the room. My path is in data analytics, applied data science, and eventually stronger analytics engineering work, where I can move between business problems, technical systems, and decision-making. Excel sits right in the middle of that path. It helps me understand data before I automate it, explain results before I productionize them, and work with stakeholders before I ask them to trust a model.
A typical week shows this better than theory. On Monday, I might receive a messy CSV from an operations team. The file has inconsistent customer IDs, blank fields, strange date formats, and duplicate rows. Before opening Python, I often open Excel. I use filters to inspect categories, conditional formatting to spot missing values, and quick pivot tables to understand what the dataset is really saying. That first look helps me avoid writing clean code for the wrong problem.
On Tuesday, I might use Power Query to clean a file that someone will need to refresh again next week. I can remove extra columns, split fields, standardize names, merge lookup tables, and leave behind a process that a business user can inspect. Could I do it in Python? Yes. Sometimes I should. But when the audience is a finance or operations team that already lives in Excel, Power Query becomes a practical middle ground between manual cleanup and full engineering.
By Wednesday, Excel often becomes my testing ground. If I am working on a fraud-detection model, for example, I may export flagged transactions into a workbook and use pivot tables to summarize risk by merchant, country, transaction type, or time of day. I might use XLOOKUP to bring in merchant metadata from another file, then apply conditional formatting to highlight unusually large transactions or repeated failed attempts. This does not replace the model. It helps me see whether the model output makes business sense.
On Thursday, Excel becomes a communication tool. I might send a workbook to a stakeholder who does not care about my notebook, my feature engineering, or my model validation process. They care about which customers are risky, which products are underperforming, or which region needs attention. Excel gives them a place to filter, comment, challenge, and add context. A perfect Python pipeline is useless if the people who need the output cannot act on it.
By Friday, I usually know what should stay in Excel and what should move out. If the task is small, temporary, or exploratory, Excel is enough. If the workflow is recurring, sensitive, large, or mission-critical, it belongs in code, databases, tests, version control, and documentation. That distinction matters. Excel becomes dangerous when people use it as hidden infrastructure. But it becomes powerful when people use it as a fast thinking space.
That is why I think technical people in data should stop treating Excel like a beginner tool. Pivot tables are still one of the fastest ways to summarize a dataset. Power Pivot and DAX can support serious business analysis. Dynamic array formulas make modern Excel more flexible than many people realize. Conditional formatting is simple, but it is excellent for quick exploratory analysis. Excel is not impressive because it is complex. It is valuable because it makes useful work happen quickly.
I also think Excel teaches something that coding alone does not always teach: proximity to the business. In a notebook, it is easy to become obsessed with elegance. In Excel, you are closer to how people actually argue with numbers. Someone will ask why a total changed. Someone will filter a region you forgot to check. Someone will notice that a “duplicate” is actually a valid business case. Those moments make the analysis better.
So yes, I use Python. I use SQL. I care about reproducibility, clean pipelines, and scalable systems. But I still use Excel almost every week because data work is not only about building technically correct solutions. It is about moving from confusion to clarity. It is about helping people trust what they are seeing. It is about turning raw information into decisions.
I may have entered data partly because I wanted a career with strong earning potential, but I stayed because the work rewards curiosity. Excel is one of the places where that curiosity starts. Before the model, before the dashboard, before the production pipeline, there is usually a messy file and a question. Excel gives me a fast way to begin answering it.
Top comments (0)