Communicating ML

Concept Lesson

Your fraud detection model is ready. It has been trained on 2.3 million transactions from a Lagos-based fintech, tested on a holdout set of 580,000 transactions (A holdout set — also called a test set — is a portion of data you deliberately set aside and do NOT use during training. You use it only at the end to check how well the model performs on data it has never seen before. This is like studying with practice tests but saving one final exam to see if you actually learned.), and it achieves 90% precision (Precision: of everything the model flagged, how many were actually positive? Recall: of all the actual positives, how many did the model catch? We covered these in detail in Week 5.). The bank's risk committee — the CFO, the head of operations, and the compliance officer, none of whom have written a line of code in their lives — have given you 10 minutes in their Thursday meeting to make your case. They want to know one thing: should they deploy this model, and what happens if they do? You have spent three months building this system, and now your entire project hinges on whether you can explain it clearly to people who think in terms of risk exposure, customer complaints, and regulatory fines — not F1 scores and confusion matrices.

The core skill here is finding the right abstraction level for each audience. Your CEO does not need to know about gradient descent, training configurations, or the difference between regularization techniques. But they absolutely need to know why the model sometimes flags legitimate transactions as fraudulent, how often that happens, and what the cost of those errors is in customer churn. The principle is simple: match your explanation to what the listener needs to make a decision. A useful structure for any stakeholder presentation is three questions: What does it do? How well does it work? What are its limitations? If you answer those three questions clearly and honestly, you have done your job. For instance, when you tell the risk committee that the model is "like an experienced fraud analyst who has reviewed 100,000 cases and can spot patterns a junior analyst would miss, but who also occasionally flags a normal purchase because it looks unusual," you have communicated capability, mechanism, and failure mode in one sentence without using any technical vocabulary.

Honesty about uncertainty is not a liability — it is what builds trust. Consider the difference: "Our AI will solve your fraud problem" versus "Our model catches 90 out of every 100 fraudulent transactions, and it incorrectly flags about 3 out of every 100 legitimate ones. That means for every 10,000 transactions, roughly 300 customers will have a payment temporarily blocked. We recommend a quick manual review queue so those customers are inconvenienced for minutes, not hours." The second statement is longer, harder to deliver, and less exciting. But it is the one that lets the CFO model the customer support cost, the compliance officer assess the regulatory exposure, and the head of operations plan the manual review workflow. When you hide or downplay limitations, you do not just erode trust — you make it impossible for decision-makers to plan around the real behavior of your system. The most effective ML communicators are the ones who present limitations as clearly as capabilities, because that clarity is what gives an organization the confidence to actually rely on your work.

A common mistake is to assume that non-technical audiences cannot handle nuance. They can. What they cannot handle is jargon, unexplained acronyms, or presentations where the speaker buries caveats in footnotes hoping nobody notices. Another mistake is over-hyping: telling a bank board that your model "uses advanced deep learning" when a logistic regression would have worked just as well. If the board later learns you overstated the technology, you have lost credibility permanently. The right approach is to be precise about what your system does, honest about what it does not do, and concrete about the numbers — always tying performance metrics back to business outcomes that your audience cares about. If your recall is 70%, do not just say the number. Say: "Out of every 100 fraudulent transactions, our system catches 70. The remaining 30 will need to be caught by your existing manual review process. Here is how we recommend supplementing the model."

Concept Lesson

You ran three experiments this week. Your team lead sends you a Slack message at 4 PM on Friday: "Hey, can you give me a quick summary of how the models performed? I need to update the product manager before end of day." You stare at the blank text box. Where do you start? Do you list all the hyperparameters? Lead with the best number? Mention the one that failed? This is the moment where technical writing skill determines whether your team lead walks into that meeting armed with useful information or confused and guessing. Good technical writing follows a simple four-part framework: Context (what problem are you solving and why does it matter?), Method (what did you actually do, with enough detail to reproduce it?), Results (what happened, presented objectively?), and Interpretation (what does it mean, and what should we do next?). This structure works for a Slack message, a formal report, a model card, or a conference paper — the level of detail changes, but the skeleton stays the same.

Reproducibility requires specificity, and specificity requires you to anticipate what a reader needs to replicate your work. Consider the difference between these two descriptions of the same experiment: "We trained a model on customer data and got good results" versus "We trained a Random Forest classifier (200 trees, max depth 12, min samples split 5) on 15,000 labeled customer support tickets from Q1-Q3 2025, using TF-IDF vectorization (TF-IDF is a method for converting text into numbers — it counts how often a word appears in a document and adjusts for how common that word is across all documents. The point here is the level of detail, not the technique itself.) with 5,000 features. We evaluated using 5-fold stratified cross-validation (Cross-validation means splitting your data into several parts, training on some and testing on the rest, then rotating through all the parts. '5-fold' means five parts. 'Stratified' means each part keeps the same ratio of classes as the full dataset.) and selected the model with the highest mean F1 score. The best model achieved F1 0.86 on the validation set." The second version lets a colleague three months from now — or even yourself, after you have forgotten the details — understand exactly what was done and reproduce the result. This level of detail is not pedantic. In production ML teams at companies like Flutterwave or Paystack, the inability to reproduce a previous experiment costs real engineering time. When you leave out details because they seem obvious to you right now, you create a gap that someone else will have to fill by repeating your entire process from scratch, or worse, making incorrect assumptions about what you did.

Common writing mistakes in ML reports are predictable and avoidable. The first is burying the key result: a colleague once wrote a 6-page report where the best model's F1 score appeared on page 5, after four pages of methodology. Your team lead reading a Slack summary does not have four pages of patience — lead with the number. The second mistake is not stating a baseline. Saying "our model achieved 82% accuracy" is meaningless without context. Is 82% good? For a balanced binary classification problem, maybe. For a dataset where 80% of samples belong to one class, a model that always predicts the majority class gets 80% accuracy — so your 82% is barely better than guessing. Always anchor your results against a baseline: majority class, random guessing, or the previous best model. A third mistake is passive voice that obscures responsibility. "The data was preprocessed" leaves the reader wondering who did it and how. "We removed 340 rows with missing values (2.1% of the dataset) and normalized numerical features using min-max scaling (rescaling numbers so they all fall between 0 and 1 — the smallest value becomes 0, the largest becomes 1, and everything else is proportionally in between)" is precise and actionable. Finally, many ML writers skip limitations entirely, either out of enthusiasm or fear. A single sentence — "We did not evaluate on out-of-distribution data (data that looks different from what the model was trained on — for example, a model trained on formal English reviews struggling with Pidgin English text), so production performance on new customer segments is unknown" — can save your team from deploying a model that quietly fails in the real world.