By Steve Jackson
As statisticians, we serve in a wide range of roles—sometimes advancing science, sometimes guiding policy, and, often, simply helping people see clarity in numbers. Most organizations need an accountant, and most can benefit from a statistician. The settings may change, but the core challenge is the same: taking data and transforming it into insight others can act on. Some statisticians do clinical trials, some focus on finance or tech, but I support transportation safety research to help agencies understand crashes, risks, and how to make our roads safer.
Daily Workflow
I typically support multiple projects in various stages, including proposal writing, planning and designing studies, analyzing data, and contributing to a final report. My company is fully remote, and I’m the only statistician, so it’s on me to plan my day to meet those various demands.
When writing proposals, I need to work with my colleagues to fully understand the project so I can craft a valid strategy that will produce valuable insight into the problem at hand. Proposal writing is a fast-paced team effort, with members at different levels of experience and ability. Everyone involved is focused on different parts of the study, such as the overall aims, pricing, and subcontracting. Since the product hinges on collecting the right amount of the right data and applying the right analysis methods, my role is to absorb the team’s thoughts and plans and craft an analysis that meets the project’s goals within constraints. Early in my career, I tended to plan comprehensive studies that went way beyond the stated goals, but budgets aren’t built for those, so I’ve learned to keep things narrow and focused.
After winning projects—and sometimes just out of the blue—I’ll be asked to take a high-level plan and fill in the details or develop a formal data collection and analysis plan. This has become a significant portion of my work. Often, a plan sounds good until you get to the analysis. A badly planned study might fail to collect the data necessary to answer the research questions. In my case, the necessary data may come from questionnaire items and responses, crash records, driving simulator output, or a combination of all three.
My approach to data collection and analysis plans is both qualitative and quantitative. First, I make sure the data to be collected can address the stated research questions, then I simulate that data and conduct an analysis. This often exposes previously unanswered questions such as how many trials each participant will experience, the kinds of data to be produced and how to prepare them for analysis, and any special considerations I need to account for in the analysis. Once agreed upon by the team, the plan becomes an important document we all reference to make sure we’re on track.
Analyzing the data is the fun part, but a relatively small piece of the puzzle. The adage that 80% of an analysis is preparing the data is 100% true in my experience, and I don’t think academic programs spend enough time on this¾at least they didn’t when I was in school. Classes often focus on what to do with perfectly curated data sets without explaining how to get to that point.
In my role, preparing data can involve merging dozens of files, decoding outputs, or reducing a data stream to a single number. For example, if we’re using a driving simulator and looking for lane encroachments, I’ll take a time series that includes vehicle position and heading and find when some percentage of the simulated vehicle has crossed over the lane line, then count those occurrences and store them in a table for analysis. This involves a lot of back and forth with the project team to make sure we’re all on the same page. Usually, the ‘analysis’ is several lines of code, but the preparation can be hundreds.
Analyzing the data is the fun part, but a relatively small piece of the puzzle.
When I do get to the analysis stage, I spend a lot of time proving to myself that the planned approach is the right one. When we give reports to the client, other statisticians and nonstatisticians review my work and ask questions, especially if the results do not comport with their a priori beliefs about the topic. “Why did you use this type of model? Wouldn’t t-tests be simpler? How did you account for multiple comparisons?” I strive to predict these questions and explain them in my contribution to the final report. I consult statistical texts, read copious articles, and converse with large language models until I feel confident that what I’m doing is correct and defensible. Statistical analysis is part art and part science; you make decisions along the way, and there are often multiple techniques available. The key is being able to defend those decisions.
Key Skills and Tools
The ability to constantly learn is crucial to being a successful statistician. Before I got into this field, I supported patent and trademark research. I knew next to nothing about patents, and I had never used Stata before, but was able to learn on the job. Since moving into transportation research, I’ve picked up a wealth of knowledge on how different road users interact with one another and the built environment. This type of domain expertise is a necessary component in statistical analysis. Without it, even the most sophisticated model can misinterpret data and lead to misguided decisions.
The ability to constantly learn is crucial to being a successful statistician. Before I got into this field, I supported patent and trademark research. I knew next to nothing about patents, and I had never used Stata before, but was able to learn on the job.
Communication skills are equally important, both for getting information and reporting analysis results. As statisticians, we are experts in finding patterns in data, but our colleagues and clients are experts in everything surrounding the data. I often work with project team members to translate their needs into the components I need to conduct a valid, worthwhile analysis. When they say the study will show participants images of road signs and ask questions to gauge their comprehension, I ask about the format of the questions, whether all participants will see all stimuli, what the relevant participant characteristics are, what comparisons need to be made, how much of a difference we expect to see, etc.
After the analysis, a different set of communication skills comes into play. Here, statisticians may be tempted to explain the intricacies of the chosen model, but that is rarely top of mind to others. Colleagues and clients, alike, are primarily focused on the results—but regression output is the last thing they want to see. I always try to visualize the results in a meaningful, intuitive way to convey the findings. This can include simple bar graphs, scatterplots and boxplots, or more bespoke visuals such as heatmaps, plots of GPS traces, or speed profiles. I tend to provide too much information in my first attempt and become simpler and more elegant as I iterate with the team.
My main tool is R (RStudio). My graduate school program taught both R and SAS, but I have used R for roughly 90% of my statistical work, followed by SAS (6%), Stata (3%), and Python (1%). SAS tends to be prohibitively expensive, and Stata can be limiting. There are many articles out there comparing R and Python, but I’ve always found R can do anything Python can do with the added benefit of more mature statistical libraries. As an open-source tool, R is always evolving. This requires constant learning, but the payoff is increasingly advanced analysis and automation opportunities.
I recently finished a project that was essentially 36 studies in one. Rather than importing data, developing models, and visualizing the results one by one, I developed custom functions and exported the results to a Word document and PowerPoint slide deck. As revision requests came in, I was able to make a few changes that were applied across the codebase for quick turnarounds.
AI has a place in my work, but with heavy guardrails. I use ChatGPT and Claude to discuss analysis ideas and quickly write code for me, but these tools have their strengths and weaknesses. They can write code faster than me, but it’s often overly complicated. I recently asked them to help me pull text from a large PDF. After going around and around with them, I ended up taking the 200+ lines of unsuccessful proposed code as inspiration and whittling it down to about 60 lines to get the job done.
These tools also tend to be sycophantic, agreeing with everything you say, potentially leading down time-wasting rabbit holes. My recommendation with these and similar tools is to treat them as an enthusiastic intern: eager to please but in need of guidance.
Work-Life Balance
As a remote worker and the only statistician on my team, I have struggled with work-life balance. I started my current role before COVID kicked open the doors to remote working. At first, it was hard to close the laptop at the end of the day when there were still tasks to be done. Over time, however, I learned to manage expectations and use to-do lists to keep timelines realistic and prioritize impactful tasks.
Early in my career, I was taught to always say yes to new work. I still do that, but I also let that person know what else is on my plate. If there is a lot on my mind at the end of a workday, I’ll channel that stress into making a to-do list for the next day.
Career Path
I don’t think my 18-year-old self expected to become a statistician. In college, I took Econ 101 freshman year, as required, and found it interesting enough to pursue as a major. When I got to econometrics—the statistics behind economics—I saw how data could be turned into insight and really enjoyed the process. My first job out of college was in management consulting, which is not always focused on quantitative analysis, but I was fortunate enough to direct my career toward projects that appealed to me.
While filling out my individual development plan (a tool companies use to make sure their employees are growing their skillsets and ability), it dawned on me that I could cement my place in quantitative analysis with a master’s degree in statistics. At that time, I only had a few weeks to study for and take the graduate record examination and apply to schools. I scored well on the GRE and was accepted into an online program at a reputable university. The first semester was by far the hardest.
In 2010, tools for online teaching and learning were in their infancy, and without a peer study group, I was mostly on my own. I would stay at the office late into the night watching classes and working on homework. I once stayed all night and filled a wall-sized whiteboard trying to derive something. Many weekend hours were also spent on homework. It was a lot of hard work, but worth it in the end, and my workplace paid for almost all of it with a generous tuition reimbursement program.
With my statistics degree in hand, I started looking for more statistics-oriented jobs. I only had experience in Excel-based financial analysis, but I had the degree and the stated goal of using my education on projects involving statistical analysis.
In 2012, data scientist was declared the “sexiest job of the 21st century.” I landed at another consulting firm and was soon assigned the role of statistician for the Office of the Chief Economist at the US Patent and Trademark Office. This was the first job I had where my boss actually asked for a regression model and gave feedback on the results. The subject matter was new to me, so I had to quickly learn the process, lingo, and how to work with the massive trove of data I suddenly had access to. This job taught me a lot about how to ‘be’ a statistician, beyond just running a model.
A few years later, I went to work for another consulting firm in the entirely unrelated field of transportation safety research. I again learned the details and became an expert in certain types of data and analyses. I also earned the GStat and PStat credentials. These were nice résumé boosters, which can be valuable in an industry such as consulting, where proposals are won or lost on team members’ qualifications.
Advice for Aspiring Statisticians
In my relatively short career, I would recommend that aspiring statisticians be, above all, willing to learn new things—fields of research and technical tools and techniques. Like accountants, statisticians can apply their expertise to pretty much any problem. I chose the consulting route and learned new subject areas and ways to communicate statistics with different audiences as I encountered them.
A day in the life of a statistician may involve planning studies, wrangling data, making analysis choices, and/or ‘crunching the numbers,’ but the common thread is solving problems through objective data and analysis and communicating the findings.
Explaining statistical work in multiple ways is often essential. Colleagues may be interested in technical details, while clients will focus on analysis results. A good graph—the simpler the better—can help you show the data and explain the results.
It’s also helpful to get into the habit of explaining things to your future self. In my experience, I’ll do an analysis, then go on to another project, and then get questions about the first project months later. Documenting your process and decisions will save you from unnecessary rework and anxiety-inducing situations in which you can’t recall why you didn’t try a certain model or use a certain variable.
The tools and techniques for using statistical analysis to answer questions are always evolving. It’s important and helpful to stay on top of the latest innovations. Specific to R programming, there are always new packages available to apply the latest specialized statistical model or produce publication-ready graphics, process data, etc. These packages typically streamline processes and facilitate access to broader types of data. In other words, they can make your job easier, so take advantage of them. Use large language models as tools but never blindly accept their suggestions. At this point, they can offer misguided advice and cause problems when over-used.
A day in the life of a statistician may involve planning studies, wrangling data, making analysis choices, and/or ‘crunching the numbers,’ but the common thread is solving problems through objective data and analysis and communicating the findings.
Leave a Reply