How the leader track works
Six sessions, forty-five minutes each, and every one of them ends the same way: a short list of decisions you now own and questions you can ask on Monday. There is no code on this track and no homework you need a Python environment for. a1 sets the economics, a2 covers the one failure mode that arrives disguised as success, a3 turns data quality into a budget line, a4 handles governance and feature stores, a5 draws the line between hand-crafted and learned features, and a6 hands you the review checklist your team should be able to answer without preparing.
Everything runs on one shared case: Lumen Skincare's checkout data - 40,000 sessions, a 3.2% conversion rate, and a pile of raw columns that look, at first glance, entirely unremarkable. Your practitioner colleagues are on a parallel ten-session track building exactly what you are learning to fund and review. Same case, same numbers, different job. When they say "we one-hot encoded channel and it bought us nine points," you will know what that sentence cost and what it was worth.
The unglamorous truth about where the time goes 7 min live
Google's Machine Learning Crash Course states it without any hedging: "ML practitioners spend far more time evaluating, cleaning, and transforming data than building models." That sentence is written for practitioners, but it is really a budget statement, and it is aimed at you. If most of the effort lives in the data layer, then most of the funding decisions live there too - and if your project plan has a line for "model selection" and no line for "feature work," the plan is describing the smaller half of the job.
LiveWhy the visible half eats the budget4 min▶
Model-shopping is legible. It has vendor names, benchmark tables, a demo, and a clean before-and-after slide. Feature work has none of that. It produces a sentence like "we split signup_date into tenure and weekend," which sounds like housekeeping and reads on a status report as no progress at all. So the budget drifts toward the legible half, and the return stays in the invisible one.
Three consequences worth naming out loud in your own org:
- The stalled-project pattern. A team that has tried four models in six weeks and moved the metric by nothing is almost never model-limited. They are input-limited, and no fifth model fixes that.
- The invisible-win pattern. The person who quietly re-encoded a category and bought nine points of AUC gets less credit than the person who ran the model bake-off. Notice who is actually producing the return.
- The reporting gap. If your status template has no row for feature decisions, your team has no way to report the work that matters, so they report the work that fits the template.
The planning meeting that ate the quarter. The recognisable version: three weeks of debate over gradient boosting versus a neural net, a decision, then a result that lands within noise of where it started. The afternoon nobody scheduled - sorting which columns the model can actually read - was worth more than the three weeks. This is not a criticism of the team. It is a criticism of how the work was framed and funded.
LiveGoogle's feature doctrine, in leader language4 min▶
Google's "Rules of Machine Learning" is written for engineers, but five of its rules are really operating principles for whoever holds the budget. Read them as constraints on what you should approve:
- Rule 17: "Start with directly observed and reported features as opposed to learned features." Translation: hand-crafted, explainable inputs first. Embeddings and learned representations are a later, more expensive step, not a starting position (that is a5).
- Rule 19: "Use very specific features when you can." Specific beats clever. A proposal that leads with sophistication rather than specificity deserves a second look.
- Rule 20: "Combine and modify existing features to create new features in human-understandable ways." If your team cannot explain a feature in one sentence to you, that is a warning, not a sign of depth.
- Rule 21: "The number of feature weights you can learn in a linear model is roughly proportional to the amount of data you have." More columns is not free. Adding inputs without adding data spends a budget you did not know you had.
- Rule 22: "Clean up features you are no longer using." Feature debt is real debt, and it is paid by whoever maintains the pipeline after the original author moves teams.
What the ladder proves 6 min live
Below is the whole argument of this course as a table. Six rungs on Lumen's checkout data, 3,000 sessions split 1,800 for training and 1,200 held out. Each rung switches on one more group of feature decisions. The algorithm - a plain logistic regression - is identical at every rung. Nobody tunes it, nobody replaces it, nobody buys a bigger one.
| Rung | What was switched on | Held-out AUC | Gain |
|---|---|---|---|
| 0 | Nothing. No features at all | 0.500 | coin flip |
| 1 | Raw numerics - numbers already in the table | 0.696 | +0.196 |
| 2 | + Encoding - categories the model could not read | 0.785 | +0.089 |
| 3 | + Datetime - what was hidden inside a timestamp | 0.806 | +0.021 |
| 4 | + Interactions - relationships no column holds alone | 0.812 | +0.006 |
| 5 | + Selection - removing a known noise column | 0.813 | +0.001 |
LiveRead the shape, not just the total4 min▶
The total is memorable, but the shape is what you fund against:
- The first rung is nearly free. Raw numerics buy 0.196 and they were already in the table. If a project has not done this, it has not started.
- The biggest single jump is encoding, at +0.089. That is worth sitting with. Encoding is a translation problem, not a modelling problem: those columns held real signal all along and the model simply could not read them. Nobody sells a product for this. It is craft, and it is the largest single line on the board.
- The later rungs get small, and that is normal. Datetime buys 0.021, interactions 0.006, selection 0.001. Diminishing returns are not failure - they are the signal that the input layer is close to exhausted and it may finally be time to talk about the model.
- Selection barely moves the score, and is still worth doing. It buys simplicity and stability rather than accuracy: fewer columns to maintain, fewer things to break, less to explain in an audit.
If someone shows you a project with a flat metric and a long model-comparison table, ask which of these five rungs they have actually climbed. In my experience the honest answer is often "one."
Self-studyWhat AUC means when you are not the one building3 min read▶
You do not need the maths, but you do need the scale, because these numbers will be quoted at you:
- 0.5 is random. A coin flip. The model has learned nothing.
- 1.0 is perfect, and on real business data it means somebody made a mistake. Which is exactly the subject of a2.
- 0.8 on a rare event is genuinely useful. Lumen converts at 3.2%. Ranking that well enough to score 0.813 is a real, spendable business capability.
One more habit worth building now: every score in this course comes as a pair. A training score answers "did the model fit what it already saw," and it is always available and always flattering. A held-out score answers "will this work on rows it has never met," and it is the only one connected to your P&L. If a team reports one number without saying which it is, that is your cue to ask.
Watch features carry a model ★ 14 min · everyone runs it
The workbench below is not a picture. It trains a real logistic regression in your browser on 1,800 Lumen sessions and scores it on 1,200 it has never seen. Start with every lever off, then switch groups on one at a time and press Score on held-out after each. You are watching a model get better without anyone touching the model.
Start with all levers off. Press Score on held-out: 0.500. A coin flip. Everything above this line is something a person builds, not something the algorithm finds on its own.
Switch on raw numerics, score again: 0.696. Spend and pages viewed were already in the table. The only cost was deciding to use them.
Add encoding: 0.785. Note the size of this one - +0.089, the biggest single jump on the whole board. It is a translation problem, not a modelling one: the model previously could not read those columns at all.
Add datetime: 0.806. Tenure and weekend were sitting inside a single signup timestamp the entire time, invisible until somebody decided to take it apart.
Add interactions: 0.812, then selection: 0.813. The returns shrink. That shrinking is information, not disappointment.
Now scroll back up and look at the algorithm. It never changed. Not once. That is the entire pitch of this course, and it is the number to carry into your next planning conversation.
What to do with this in your own org. Take one stalled model your team owns and ask them to draw its ladder - which of the five groups are actually switched on today, and what the held-out score was before and after each. Most teams have never drawn it. The exercise usually finds an unclimbed rung within an hour, and it costs you nothing but the meeting.
Five questions that reframe a stalled project ◐ 5 min read
You will not out-argue your data scientists on modelling, and you should not try. What you can do is change which question the room is answering. These five move a conversation from "which model?" to "which columns?" without requiring you to write a line of code - and every one of them has an answer your team can give in under a minute if the work is healthy.
1 · "Which of the five feature groups are switched on right now?" Raw numerics, encoding, datetime, interactions, selection. If the answer is vague, the ladder has not been climbed and the model is not the constraint.
2 · "What did the held-out score do the last three times we changed something?" This separates teams tracking real movement from teams tracking activity. If the last three changes were all model swaps and the metric is flat, you have your answer.
3 · "Which columns can the model not currently read?" Categories held as text, timestamps left whole, free text ignored entirely. Each one is unclaimed return sitting in a table you already pay to store.
4 · "What would you build if I gave you two weeks and forbade you from changing the model?" The best question on this list. A good team lights up. A team that has nothing to say has been working on the wrong layer.
5 · "Which features are we maintaining that nothing uses?" Rule 22, in your voice. Feature debt shows up as pipeline fragility long before anyone calls it that.
Self-studyHow to hear the answers3 min read▶
A few patterns worth recognising in the responses:
- "We threw all the columns in and let the model figure it out." Common, and rarely true in the way it sounds. Categories held as raw text or integer codes are either dropped or actively misread - Google's crash course notes that a model handed indexed categories treats them as continuous numbers and would "consider 'purple' six times more likely than 'orange.'" That is arithmetic on nonsense, not a shortcut.
- "The next model should fix it." Ask what the last one was supposed to fix. Two of these in a row is a pattern, not a plan.
- "We are blocked on data quality." This is often correct and often under-funded, because it does not present as machine-learning work. It is session a3.
- "The training score is great." Ask for the held-out number and watch what happens next. That reflex is the whole of session a2.
Self-studyWhat this changes in how you fund3 min read▶
Three concrete shifts, all of them cheap:
- Put feature work on the plan as its own line. Not "data prep," not "cleanup." Name it, size it, and let people report progress against it. Work that has no row on the plan gets done in the gaps or not at all.
- Ask for the ladder, not the leaderboard. A model-comparison table tells you what was tried. A ladder tells you where the return came from. Only one of those helps you decide what to fund next quarter.
- Reward the invisible half. The encoding decision that bought 0.089 deserves the same visibility as the model that bought 0.004. If your recognition only tracks the legible work, your team will keep producing legible work.
None of this needs new headcount. It needs the plan to describe the job accurately.
Three things to do this week ◐ 20 min total
- Pick one model your org depends on. Ask its owner for the ladder: which feature groups are on, and what held-out score each one bought. Note how long it takes them to answer.
- Open your current project plan and look for the line that funds feature work. If there is not one, write the sentence you would use to add it.
- Ask any model owner for a single number: the held-out score. If they give you the training score instead, notice it and bring it to session a2 - that is exactly the gap next session is about.
Official sources covered
This track teaches the decision-making core of the canonical feature-engineering sources - Google's crash-course data modules and Rules of Machine Learning, sklearn's pitfalls and selection guides, Kaggle Learn's feature-engineering course - with a live workbench where the numbers are computed rather than illustrated. Certificates and graded exercises stay with the official providers, linked each session. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · According to Google's crash course, where do machine-learning practitioners spend most of their time?
The wording is direct: "ML practitioners spend far more time evaluating, cleaning, and transforming data than building models." Read as a budget statement, it says most of the funding decisions live in the data layer, not the model layer.
2 · On the ladder, held-out AUC climbed from 0.500 to 0.813. What is the leader takeaway?
Same estimator, same rows, same split at every rung. The climb is entirely attributable to how the inputs were shaped, which means it is work you can staff and schedule rather than hardware or vendors you have to buy.
3 · A team proposes starting with learned representations rather than hand-built features. Which of Google's rules speaks to this?
Rule 17 sets the order of operations: observable, explainable inputs first, learned representations after. It is not a ban on embeddings - session a5 covers when they pay - it is a statement about what you fund first.