Repetition is not practice.

Repetition is doing something again. Practice is doing something again with correction.

That distinction explains why some people improve quickly while others accumulate years without accumulating mastery. They have written hundreds of updates but still write vaguely. They have shipped many features but still miss the same edge cases. They have managed teams for years but still avoid hard feedback. They have used AI daily but still accept plausible nonsense. They have repeated the activity. They have not installed the correction loop.

Practice requires three things: a target, a rep, and feedback that changes the next rep.

The target is the standard. What does good look like? Not “better writing” or “cleaner product work” or “more strategic thinking.” Those are wishes. A target is specific enough to aim at: customer updates name the issue, impact, owner, next step, and timing. Product specs name the user problem, non-goals, tradeoffs, risks, and support implications. AI-generated research is accepted only after source verification and contradiction checks.

Without a target, repetition creates style but not quality.

The target should include an observable failure condition. A customer update is not acceptable if the reader cannot tell who owns the next step. A design review is not complete if recovery states are missing. A sprint plan is not ready if every task depends on the same overloaded engineer. An AI research brief is not usable if the strongest recommendation would change after reading the primary source. The failure condition keeps practice from becoming theater.

The rep is the deliberate attempt. It should be small enough to repeat and hard enough to stretch judgment. A full product launch may be too large to practice cleanly, but launch readiness notes can be practiced. A complete strategy may be too broad, but decision memos can be practiced. “Be a better manager” is too vague, but giving specific feedback within twenty-four hours is a rep.

The feedback is where most people fail.

Feedback has to be timely, specific, and consequential. “Looks good” is not feedback. “Make it sharper” is barely feedback. Useful feedback says: the opening hides the decision; the metric is unaudited; the customer promise is stronger than the evidence; the design solves the happy path but ignores recovery; the code is readable but creates an ownership gap; the AI summary missed the April source note.

Good feedback changes what the person sees.

This is why deliberate practice often feels uncomfortable. It puts your current ability against a standard and makes the gap visible. Comfort is not the point. The point is calibration. Cal Newport’s craftsman mindset is useful here: skill becomes valuable because focused effort and deliberate practice build rare capability. The discomfort is not a sign that you are bad at the work. It is a sign that the work is finally teaching you.

Volume still matters. You cannot think your way into mastery without reps. But volume without correction automates mediocrity.

This is a real risk in AI-assisted work. AI can increase volume dramatically. More drafts, more code, more analysis, more variants, more plans. That feels like practice because activity increases. But if the operator is not correcting against a standard, they may simply become faster at selecting plausible work. Worse, they may lose the reps that used to build judgment.

The question is not “How much did we produce?” The question is “What did production teach us?”

A strong practice system makes learning visible. After each rep, capture the correction. What mistake repeated? What signal was missed? What did the senior reviewer notice first? What standard was unclear? What checklist should change? What example should be saved?

The best operators keep small libraries of correction. Not for bureaucracy. For compounding.

A writer might keep a file of cut openings, stronger rewrites, and notes on why the rewrite works. A product manager might keep a collection of tradeoffs that were misunderstood and how they were clarified. An engineering manager might track review comments that recur across the team. An AI operator might keep rejected outputs with labels: unsupported claim, stale context, generic synthesis, missing source, wrong level of detail, bad assumption.

Patterns turn into training material.

Practice also needs increasing difficulty. If the reps never get harder, you get fluency at the current level, not mastery. The escalation should be intentional. First write the customer update with a template. Then write it without one. Then write under time pressure. Then write after bad news. Then write for an angry enterprise customer. Then teach someone else how to write it.

Each level tests a different part of the operating system.

The same applies to management. First give feedback in a low-stakes setting. Then give it when performance is slipping. Then give it to a high performer. Then give it when you contributed to the ambiguity. Then repair trust after waiting too long. Practice is not the repetition of the easiest version. It is progressive exposure to reality.

One reason teams avoid real practice is that it looks inefficient. Reviewing, correcting, rewriting, rehearsing, and debriefing all take time. But the alternative is hidden rework. The organization pays later through customer confusion, slow decisions, repeated mistakes, quality drift, and senior people cleaning up the same problems forever.

Practice is how you pay the learning cost on purpose.

Managers have a special role here. They are not only task assigners. They are designers of reps. If the team needs better judgment, the manager should ask: what recurring decisions develop that judgment? What feedback will people receive? Who can review? What examples define the bar? What should be delegated now, and what still needs supervision? What mistakes are safe enough to learn from, and what mistakes require guardrails?

That is talent development as operating design.

For individuals, the practice question is blunt: where are you repeating without improving?

Maybe you send updates every week but never study whether they drive decisions. Maybe you write strategy documents but never compare predictions to outcomes. Maybe you use AI to code faster but do not review the architecture consequences. Maybe you lead meetings but never ask whether decisions were clearer afterward. Maybe you produce more content but never identify what made the strongest pieces work.

Pick one loop. Make the target explicit. Do the rep. Get correction. Change the next rep. Save the lesson.

Mastery is not built by heroic intensity once a quarter. It is built by correction installed into ordinary work.

Repetition creates familiarity. Correction creates skill.