Wilkening Consulting's Curiosity Resources |
If it feels absent, start by lowering the cost of asking “why.”
Make “I don’t know—yet” an acceptable, even praised, response.
Leaders should model ignorance openly and map how they learn.
Share short “learning notes” after decisions to show your work.
Reward thoughtful questions in reviews, not only perfect answers.
Replace blame with blameless postmortems that hunt for surprises.
Publish problem backlogs with context, not just ticket titles.
Create rotating “guide” roles to demo tools, datasets, and users.
Normalize 10% time for explorations tied to mission outcomes.
To detect curiosity discreetly, watch for pull, not push.
Track who bookmarks docs, not who talks loudest in standups.
Notice commit messages that explain “why,” not only “what.”
Sample meeting notes: do they capture questions or conclusions?
Instrument wikis with optional “what I learned” fields.
In code reviews, count clarifying questions vs. nitpicks.
Host lightning talks; log volunteer rates and follow-up pings.
Seed “mystery bugs” and see who traces root causes patiently.
Quietly analyze search logs to learn which topics draw revisits.
During shadowing, observe who asks users to “show me” twice.
-
Launch “Curiosity Sprints”: one-week probes ending with demo day.
-
Write “Why-first PRDs” that start with hypotheses and unknowns.
-
Add an optional “Open questions” field to tickets and PRs.
-
Run monthly micro-experiments; publish results in 300 words.
-
Start a 15-minute “What surprised you?” ritual after key work.
-
Discreetly track doc deep-reads and return visits (aggregate only).
-
Put inquiry in the promo rubric: credit great questions, not just outputs.
No comments:
Post a Comment