Why it matters
What this principle is for.
If customer needs, competitors, technology, and knowledge never changed, complacent leaders would win forever. That is not the world. The best leaders never stop working on their craft.
Great leaders are voracious learners. They do not limit curiosity to the job at hand. They read, they seek people from different backgrounds, and they put themselves in situations that are uncomfortable on purpose. Negative situations count. They are tuition if you extract the lesson.
Change is disorienting. Skills you mastered stop fitting the problem. Leaders use that discomfort to grow. They will not get it right the first time. Trial, help, practice, then new mastery.
Curiosity is also how you Invent and Simplify. You do not just ask why it works that way. You ask what other ways it could work, and what would happen if. You learn the nuts and bolts of what you own before the outage teaches you.
You cannot see yourself accurately without other people. Feedback from peers, mentors, customers, and managers shows you strengths you are using by accident and gaps that are capping you. Being vocally self-critical is not weakness. It is the ingredient that lets Are Right, A Lot compound.
Calibration
Under, just right, over.
Look for a concrete thing someone did not know, what they did to learn it, and what changed in the work. "I read a lot" is not this principle. Neither is turning every miss into a new framework, or forcing the whole team through training they do not need.
| Situation | Under | Just Right | Over |
|---|---|---|---|
| An unfamiliar term in a meeting | Lets the term pass so the meeting can move. Stays lost for the rest of the discussion. | Asks a brief question or notes it and looks it up the same day. Comes back only if it changes the work. | Stops the meeting for a full explainer. The agenda does not finish, and people stay late to recover the decisions. |
| A new library that might help this week | Ignores it and stays on the familiar path even when that path is slow. | Gives the library a short, time boxed try. Keeps the old path if the try does not clearly help this ticket. | Rebuilds the ticket around the library. The original work slips while they compare options. |
| A neighboring team's design review | Skips it because the service is not theirs. Misses a change that will land on them. | Reads the doc, attends if it touches their work, and asks a question that tests one assumption. Leaves when the rest is not their problem. | Sits in every review and debates each design. Their own tickets wait. |
| The first approach stops working | Keeps forcing the same method. Does not read, ask, or try another path. | Pauses, looks up how others solved it, and tries one different approach with a time box. Returns to the original if the detour is worse. | Drops the ticket to survey every method they can find. Days pass with nothing working in the branch. |
| A ticket outside your stack | Leaves it for the specialist. Does not open the docs or attempt a first cut. | Takes the ticket, learns the slice it needs, and checks with someone who knows the area before merging. | Uses the ticket as a reason to study the whole stack. The ticket sits while they take a course. |
| Data that does not match the plan | Talks past the numbers so the plan can stay. Does not open the raw source. | Pulls the data, names what they do not understand, and changes the plan only where the evidence is clear. | Rewrites the whole plan from one surprising chart. The team chases a new theory each afternoon. |
| A question you cannot answer in your own review | Bluffs or shuts the question down so they still look like the expert. | Says they do not know, writes the question down, and comes back after they have checked. Keeps the review moving. | Turns the review into a live research session. Reviewers sit while they read docs on the call. |
| Someone asks why we do it this way | Answers with that is how we do it and moves on. Does not check whether the reason still holds. | Explains the history, admits the parts they are unsure about, and looks it up if the answer may be stale. Changes the practice only if that check warrants it. | Turns the question into a rewrite of the team's process. Shipping pauses for a long debate. |
Examples
What it looks like in the work.
Iterate the process, do not blame the people
A new planning process missed the date. The under move is "the people failed the process." The over move is a brand-new process by Monday. The just-right move is a short, honest pass with the people who used it, then one more attempt with the sharp edges filed off. Look for whether they can learn without thrashing.
Change the system after the outage
Someone on the team took production down. Curiosity does not mean a public shaming, and it does not mean everyone has to page themselves as a rite of passage. It means you understand the steps that got you there, you change the system, and that class of mistake dies. The write-up is for learning, not for checking a box.
Learn it, then put it back into the work
The last new thing you learned only counts if it showed up in the product, the process, or how you work with customers. A talk you watched and a book on the nightstand are inputs. I want the output. What did you apply, and who else can now use it?
In the role
Individual and manager.
Individual
You can name the last thing you did not understand and the specific thing you did about it. You know the parts of your system you have not opened yet. You ask for examples when feedback is vague, and you change a behavior where someone can see it.
Manager
You put people into stretch work on purpose, then you make it safe to extract the lesson when they miss. You do not run a wall of shame. You do not mandate a class for a technique one person needed. You model changing your mind when a teammate teaches you something.
Go deeper
Questions that make the principle concrete.
- When is the last time you took on work outside your comfort zone, and what did you have to learn to finish it?
- What do you do in the first hour after you hit something you do not understand?
- Are you focused on the fact that you were wrong, or on how the next attempt will be different?
- Who did you ask for feedback, and what did they see you change afterward?
- Which part of your system have you never actually opened, and why not?
- What did you do with two pieces of feedback that contradicted each other?
- How did a miss on your team change the system, not just the slide deck?
- What new skill have you practiced on purpose in the last quarter?
- When a teammate challenged how you saw a problem, what did you do with that challenge?
- What are you reading or studying that is not required for this week's deliverable?
From the blog
Writing that goes deeper.
- Mental Models
Learn, invent, and adopt models so you can frame a hard thing simply.
Related