Zac Stryker Home Projects Blog Resume About Contact GitHub
← Back to blog

From BI Dashboards to ML Pipelines: Changing Career Tracks

A year ago, if you'd told me I'd be training neural networks and debugging tensor shapes, I would have laughed. My world was Tableau, QlikView, and SQL queries. But here I am, and the path from business intelligence to machine learning engineering turned out to be shorter than I expected.

The BI Foundation

Working in BI gave me something that a lot of ML tutorials skip over: an intuition for data. Years of building dashboards at the Defense Health Agency and the Florida Department of Health meant I spent my days living inside datasets. I knew what messy data looked like. I knew how to spot outliers, understand distributions, and ask the right questions before writing a single line of code.

That foundation matters more than people realize. A surprising amount of ML engineering is data engineering — cleaning, transforming, and understanding your inputs before any model gets involved. The ETL pipelines I built in SSIS and the data models I designed in Snowflake were closer to ML preprocessing than I thought.

The Pivot Point

The shift started with a simple question: what if the dashboard could tell you what's going to happen instead of what already happened? BI is inherently retrospective. You're summarizing the past. Machine learning flips that around.

I started small. Python was already in my toolkit from automation scripts, so I picked up scikit-learn and started with the basics — regression, classification, clustering. The concepts clicked faster than I expected because I already understood the data side. What changed was the tooling:

  • SQL queries became pandas DataFrames
  • Calculated fields became feature engineering
  • Dashboard KPIs became model evaluation metrics
  • ETL pipelines became training pipelines

The mental models transfer. Precision and recall aren't that different from the accuracy checks I was already doing on BI reports. A confusion matrix is just a crosstab with higher stakes.

What I Had to Unlearn

Not everything carried over cleanly. BI trained me to think in exact numbers — a revenue figure is either right or wrong. ML lives in probabilities. A model that's 92% accurate is considered good. That took some adjusting.

I also had to let go of the "one query, one answer" mindset. In BI, you write a query and get a result. In ML, you train a model, evaluate it, tweak hyperparameters, retrain, and repeat. The iteration cycle is fundamentally different. It's more experimental, more scientific.

The hardest part wasn't learning TensorFlow. It was accepting that "good enough" is a valid outcome when you're working with probabilistic systems.

The Projects That Bridged the Gap

The two projects on this site represent different stages of that transition. The text summarization project was my entry point — NLP felt natural because I'd spent years working with text data in reports. Understanding extractive vs. abstractive summarization mapped well onto my existing knowledge of how information gets condensed in executive dashboards.

The digit recognition project pushed me into new territory: computer vision, neural networks, and client-side inference with TensorFlow.js. That was the moment it stopped feeling like extended BI and started feeling like a new discipline.

What Transfers, What Doesn't

Transfers well:

  • Data intuition and EDA skills
  • SQL and data transformation experience
  • Understanding of business context and stakeholder communication
  • Visualization skills (useful for model interpretability)
  • ETL and pipeline thinking

Need to build from scratch:

  • Linear algebra and calculus fundamentals
  • Deep learning frameworks (TensorFlow, PyTorch)
  • Model architecture design
  • GPU/hardware considerations
  • Research paper literacy

Advice for BI Developers Considering the Switch

Start with what you know. Pick a dataset from your domain and apply ML to it. If you've been building sales dashboards, try demand forecasting. If you've been doing healthcare analytics, try patient outcome prediction. The domain knowledge you already have is a genuine advantage.

Don't skip the math, but don't let it block you either. You can build working models without a PhD in statistics. But understanding the intuition behind gradient descent and backpropagation will make you a better engineer. Learn it incrementally.

Build things. The gap between "completed a tutorial" and "built something from scratch" is where the real learning happens. Deploy a model. Make it accessible through a web interface. The full loop from data to user-facing product is what separates ML engineers from people who can run model.fit().

The career tracks aren't as far apart as the job titles suggest. BI gave me the data skills. ML gives me a new set of tools to apply them. The transition isn't a leap — it's a step.