The decision review should happen twice

TL;DR: I would schedule the second decision review when I schedule the first. Steve Jobs’s 1992 MIT Sloan discussion is useful for technical leaders who want teams to learn from recommendations after implementation. Approving a decision and observing its consequences are different responsibilities.

Jobs argues that making recommendations without staying for implementation limits what a person can learn. Later, he describes trying to help colleagues learn from mistakes instead of immediately fixing the problem himself. MIT Sloan’s archive identifies the session and those themes.

I would borrow the demand for follow-through without turning his critique of consultants into a rule about job titles. An employee can avoid the consequences of a recommendation. An adviser can remain deeply involved. The meaningful distinction is who returns when the result becomes visible.

Separate a reasonable choice from a fortunate outcome

Consider an illustrative technical decision: a team chooses a simpler deployment approach because it expects modest traffic and needs to deliver quickly. The first review records those assumptions, the alternatives and the signs that would justify revisiting the choice.

A month later, traffic is higher than expected and operations are difficult. It would be too easy to say the original team made a bad decision simply because the outcome was painful. The useful questions are more precise. Was the traffic assumption reasonable with the information available? Was an important warning ignored? Did the team notice when the condition changed?

A different case can produce the opposite trap. A weak decision may happen to work because demand never arrives. Success does not automatically validate the reasoning that produced it.

I would use the second review to distinguish what the team could have known, what it actually expected and what the result now teaches. That gives people something more useful than congratulations or blame.

Make the learning change the next decision

The review should end with one change that can be observed later. Perhaps the team needs a clearer traffic assumption, an earlier load test or a less expensive migration path. “Be more careful” gives the next project little to use.

I would also give the person who made the recommendation a role in examining the outcome. Quietly replacing their work may repair the immediate problem while removing the chance to understand it. That does not mean leaving an active failure in place for educational value. Stabilise the situation, then make the reasoning available for review.

The recording presents historical management views, not evidence that a particular review format causes better organisational performance. Some decisions take years to reveal their consequences, and several changes may happen together. The second review needs to acknowledge those limits rather than force a tidy explanation.

Still, the proposed habit is inexpensive: attach a return date and an observable expectation to a consequential recommendation. If the outcome is not yet knowable, identify the next useful observation.

A technical decision teaches more when its authors return to compare the expected consequence with the one that arrived.