LinkedIn Post Ideas for Data Scientists

My model was 94% accurate. Completely useless. Here's the gap nobody warned me about early in my career. I'd optimized for accuracy on a dataset where 92% of the label was the majority class. A model that just always predicted the majority class would have scored 92% — my 'impressive' model was barely better than doing nothing at all. Worse, the 2% improvement it did offer wasn't even on the cases the business actually cared about; it was accurate on the easy majority and still weak on the rare, high-stakes minority class that mattered for the actual decision. I now ask what metric maps to the real decision before touching a model. Accuracy on the wrong target is just an expensive way to be confidently wrong.

Most companies that hire a data scientist actually need a SQL analyst. I've watched this happen at two companies I've worked for, including my own hiring. I was hired to 'build ML models.' My first six months were entirely dashboards, ad hoc SQL queries, and answering 'can you pull the numbers on X' from people who genuinely just needed a query, not a model. There's nothing wrong with that work. It's valuable and often more immediately useful to a company than a model would be. The problem is the title mismatch: hiring for ML when the real need is analytics creates frustration on both sides, and premature ML investment when a simple query would answer the question. Ask what decision the model would actually change before building it.

How I explain a model to executives without ever saying the word 'algorithm.' I lead with the decision it changes, not the mechanism: 'this flags the 8% of accounts most likely to churn next month, so the retention team can call them first.' I frame error costs in dollars, not precision or recall: 'when we're wrong, it costs us either a wasted retention call or a missed save — here's roughly what each costs.' I frame confidence as a range, not a false certainty: 'this isn't a guarantee, it's a ranking, and it gets better as we collect more data.' No jargon, no algorithm names. Executives don't need to understand the model. They need to trust the decision it's informing.

We A/B tested the A/B test. Our sample size was a fantasy, and finding that out was humbling. We'd been calling results 'significant' based on p-values checked daily as data came in — classic peeking, which inflates false-positive rates far beyond the 5% everyone assumes they're working with. Ran a proper power analysis retroactively on our last six 'winning' tests: three of them didn't have enough traffic to detect the effect size we claimed to have found, meaning we'd essentially been reading noise as signal. We now pre-register sample size and a fixed test duration before launching, no peeking allowed until the calculated endpoint. Uncomfortable conversation with product about slower test cycles. Much better conversation than continuing to ship decisions based on statistical fiction.

A stakeholder asked for a dashboard. What they actually needed was one decision made for them, and building the dashboard would have wasted three weeks. I asked what they'd do differently based on the numbers before building anything. Turned out the real question was simple: should we keep or cut a specific underperforming marketing channel. That's one analysis and one recommendation, not an ongoing dashboard nobody would check after month one. I built a two-page analysis instead: the channel's actual ROI, a clear recommendation, and the confidence interval around it. Delivered in four days instead of three weeks. Most dashboard requests are actually decision requests wearing a dashboard costume. Asking 'what would you do differently' before building anything saves everyone real time.

Four feature engineering mistakes that leaked the future into my models before I learned to catch them. Using a customer's 'total lifetime purchases' as a feature to predict churn — that total includes purchases made after the prediction date in a naive pipeline, silently telling the model the answer. Computing a rolling average over a window that included the exact day being predicted, not just prior days. Splitting train and test randomly on time-series data, letting the model learn from future patterns to predict the past. Joining a table that got updated retroactively, so 'what we knew at prediction time' quietly became 'what we know now.' Every one of these produced suspiciously great validation metrics. That suspicious greatness was the tell, in hindsight, every single time.

LLMs ate my custom NLP pipeline. What I actually do instead now, concretely. I used to build and maintain bespoke text classifiers for intent detection, sentiment, and entity extraction — real infrastructure, real retraining cycles, real ownership overhead. Now, for most of those tasks, a well-prompted foundation model with a handful of examples matches or beats my old classifiers' accuracy, built in an afternoon instead of weeks. Where classical methods still win for me: extremely high-volume, low-latency, cost-sensitive classification where an LLM call is simply too slow or too expensive at scale, and anything needing fully deterministic, auditable logic. My job shifted from training models to evaluating and prompting them. Different skill, similar underlying judgment about what the data actually needs.

A week in my actual job, honestly logged: roughly 70% plumbing, 10% modeling, the rest split between meetings and communicating results. Monday: three hours cleaning a dataset with inconsistent date formats across two source systems that were supposedly the same data. Tuesday-Wednesday: building and debugging a data pipeline, not touching a model once. Thursday: finally modeling, about four hours of actual model work, the part every Kaggle competition trains you to think is the whole job. Friday: presenting results, half the day, translating findings into language a VP could act on. Nobody warns you in school that the Kaggle-style modeling is maybe 10-15% of the real job. The rest is just as important, and much less glamorous.

Six questions I ask before starting any modeling project, because most of the value is in deciding what not to build. 1. Is there a simple baseline or heuristic we haven't tried first? 2. What specific decision changes based on this model's output? 3. Do we actually have the data, at the volume and quality needed, or are we assuming we will? 4. What happens if we do nothing — what's the cost of the status quo? 5. Who owns acting on this model's output once it exists? 6. How will we know if this project failed, and when do we call it? Half the modeling projects I've killed with these questions were killed in the first conversation, before anyone wrote a line of code.

What's the most overrated metric in data science right now? I'll nominate mine and take the heat. Accuracy, on its own, with no mention of class balance or the actual cost of different error types. I've watched it get cited in board meetings as if a single number could summarize a model's real-world value, when the decision it's informing usually cares far more about one specific type of error than the aggregate rate. Close second: R-squared, treated as a universal quality signal when it says almost nothing about whether the model is useful for the actual prediction task at hand. What's yours? I want the metric you've seen misused in a meeting, and what actually should have been reported instead.