Translation and notes
A readable adaptation of the article's core ideas, with the original source clearly credited.
Determination involves more than wanting something strongly: discipline supports will, while ambition sets its direction. This brief adaptation introduces an independent commitment review exercise. Imagine a three-person team building wholesale ordering software, repeatedly carrying unfinished work into the following week. The scenario and review procedure below are proposals here, not examples or instructions from the source.
Choose one important commitment and describe an observable result. Instead of “improve onboarding,” specify that a pilot customer can import a product list and see the errors in each row. Record the owner, deadline, reviewer, and exclusions, such as cleaning every historical file or supporting every format. Check dependencies before promising delivery. The developer may need a real file and explanations of its columns from the customer contact. If that input is unavailable, assign a separate preliminary action to obtain a sample with sensitive information removed. Set a time to request help before the end-of-week review.
At the review, compare the actual result with the agreed definition. An importer that only exposes errors in technical logs is partially complete, not finished. Record time spent, observed obstacles, and scope changes separately. An effort report cannot substitute for examining the result, and a missed date does not establish a character flaw. Identify whether the estimate, missing input, an urgent interruption, or an unresolved product decision explains the gap. Then explicitly continue, reduce, or stop the commitment. For a first trial, a row number and a clear error message might suffice; in-product editing could wait. A revised deadline should identify what has changed since the previous promise.
After several reviews, inspect recurring dependencies rather than ranking people by completed task counts. If one person must approve most work, reduce that decision queue; if requests keep expanding, agree when new scope can be accepted. Tasks differ in difficulty and dependencies, so their counts are not interchangeable performance measures. End each review with a traceable decision for every open commitment. Select one process change for the next week and check whether the same obstacle recurs.
Selected advice from the article
- Practice discipline alongside willpower.
- Spend time with peers who pursue ambitious goals.
Operating takeaways
- Define one observable result with an owner, deadline, and reviewer.
- Record exclusions and missing inputs before committing to delivery.
- Compare results with the original definition and separate scope changes from execution.
- Give overdue work an explicit continue, reduce, or stop decision.
- Use recurring obstacles to choose one process change, not to rank people.
Quick feedback
What did this article make clearer for you?
Choose a reaction or share a question or experience. Useful responses can shape future notes.
This is a free adaptation, not a word-for-word republication of the original article.