This index starts from situations and from things you want to get better at. A line offers one or two cards for examining the subject; it does not describe a category of people and does not assume the problem is yours.
You can look for a difficulty, a strength to deepen, or backing to offer. The eighty-five cards are all reachable here, each at least once, with no ranking by importance and no required order.
For a first attempt with no job and no team, to deepen a practice, to grow a group or to back someone, the four paths also give direct ways in.
Understanding the problem and asking a question
- I want to pin down the problem behind a request → If you don’t understand why, you are not ready to build it
- Something I found while working is worth sharing → Do not bring the task. Bring the problem
- I need a word pinned down before we decide → Ask the naive question straight away
- A software dependency deserves a closer look → Read the source · Curiosity is billable
- I want to understand a handover between crafts → Read outside your lane
- A fix works, but its cause is still unclear → Don’t stop at the first answer
- I want questions to get a visible follow-up → ⇄ Nobody asks twice
Examining a disagreement or a piece of feedback
- A new fact invites us to revisit a decision → Being wrong is free. Staying wrong is expensive
- I am looking for a way to examine a disagreement with an experienced person → Respect the elder. Challenge the idea
- I want to get more out of a review of my work → Your code is not your baby
- I cannot answer yet and have to agree a check → “I don’t know” is a professional answer
- We want to clarify who contributes to the discussion and who calls it → Deciding and being right are two different jobs
- We want to make reporting mistakes easier → ⇄ If being wrong costs status, nobody will be wrong out loud
- I want to make objections possible and give them a follow-up → ⇄ You cannot ask for candor and keep the last word
Connecting work to its effects
- We finish tasks without knowing what they make possible → The ticket is not the work
- A signed-off solution still has to meet real use → Signing off a spec does not make it right
- We prepared a lot and have little feedback on the solution → The more you polish, the harder it gets to change your mind
- Someone asks for a precise solution; their need is still to be understood → A feature request is not the problem
- I want to learn from someone the problem affects → Talk to the person who has the problem
- Support requests could point at an improvement → Support is product research with angry participants
- I want to tie a technical explanation to what my audience needs → The customer does not care about your architecture
- We want to connect requests to expected outcomes better → Product is not the person who writes the tickets · ⇄ A roadmap nobody may refuse is a queue
- Access to the field is missing to inform the work → ⇄ Customer access is a budget, not a value
- I have handed a proposal on and need to clarify who picks it up → Done on your side does not mean solved
- Several parts are finished, but what happens to the file is unclear → Done on your side does not mean solved
- I want to know what a delivered piece of work changed → Come back a month later
- We have to clarify coordination and decisions on a shared subject → A responsibility shared by six people does not exist
- A disappointing result deserves examining → The bad outcome is yours too
- We want to discuss the effects of the work, not only the tasks done → ⇄ You ask for outcomes and you review activity
Acting with a remit and with backing
- A change threatens a commitment and has to be flagged → Good news can wait. Bad news cannot
- I depend on an answer or on backing to carry on → Being stuck is a decision
- We have to choose what can wait without losing the useful protections → Fast does not mean rushed
- I am looking for a bounded attempt that would let us learn → Shipping creates information
- A way of doing something looks more complicated than it needs to be → Making it simple is a technical achievement
- I want to propose an improvement beyond my usual remit → Ownership starts where the job description stops
- I want to answer an initiative by clarifying what follows and its limits → ⇄ The first reaction sets the rule
- We want to make useful attempts easier inside the time we have → ⇄ Your delivery rhythm is a decision you made
- We want to credit simplification and maintenance too → ⇄ You get the complexity you reward
- An activity keeps coming back; we have to decide whether a change is worth it → The second time is information
- A step is poorly understood and deserves an inquiry before we change it → Delete the step before you document it
- I want to prepare a relay for an essential piece of knowledge → Knowledge that fits in one head is an outage waiting
- We want to check whether a rule is still useful → Not everything deserves to become a process
- A workaround deserves understanding with the people concerned → The shortcut everyone takes is the real process
- We want to credit the work avoided and the service kept running → ⇄ You pay for hours, you get hours
Learning and building a strength
- I want to add to the bearings available around me → Your best teacher does not work here
- I am looking for quality criteria suited to the use, beyond a local comparison → Your market can be local. Your standard can’t
- A resource, a language or an access is missing for me to learn → Knowledge is not what you are missing
- I want to learn from an open project, with a first step within reach → Open source is a classroom
- We want to plan learning inside the time we have → ⇄ Learning on your own time is a filter you did not mean to set
- A careful decision turned out badly; we want to understand why → A good decision can still lose
- I want to examine the conditions that would allow more initiative → You build the environment you complain about
- We want to open hiring to other kinds of evidence → The filter you are running
- I want to go deeper into a skill I already use → Twelve years of experience, or the same year twelve times
- I am looking for sources to understand my craft better → Your craft has a literature
- I want to hand over a problem with the framing and the help it needs → Hand over a problem, not a task
- I want to explain what my review checked → A review that only says yes teaches nothing
- We want to spread decisions inside a clear frame → Let them carry what is reversible
- I want to prepare a successor without handing over all my work at once → Make yourself replaceable on one subject
Connecting choices, means and recipients
- We want to examine capability and costs before making a commitment → What you can build decides what you can sell · ⇄ An estimate asked for after the decision is not an estimate
- We have to plan for leaving a vendor too → Choosing a vendor is signing up for three years
- I want to understand a choice well enough to carry my part of the decision → Understanding cannot be delegated
- I am looking at how the first recipients will find what we built → Distribution is part of the product · An audience takes longer to build than a product
- We want to prepare the relationship with recipients before the project ends → Marketing is not decoration
- I want to explain what my proposal helps people do → Talk about the problem before you talk about yourself
- We have to set aside means for access and adoption → ⇄ You cannot ask for distribution while funding only features
Comparing causes, tools and costs
- We want to understand what feeds the load before choosing a response → Sort them by cause, not by subject
- Requests look alike; their common cause is still to be checked → Sort them by cause, not by subject
- I want to know how to check an AI output, or choose another method → AI is leverage, not a shortcut
- I want to compare a new tool to the resources we already have → The cheapest leverage is already paid for
- We want to keep the useful controls before amplifying an operation → Leverage in the wrong place multiplies the mistake
- We want to make a contribution of prevention or of service visible → ⇄ You pay for hours, you get hours
Passing on, crediting, and preparing what follows
- We want to make contributions identifiable and back passing them on → Put your name on it · ⇄ You are the missing reference, and you left nothing behind
- I get asked to write about my work more often than I build → Write after you build, not instead
- An incident may have something worth keeping to teach us → Write down what broke
- I want to make a useful answer findable without removing direct help → Answer the question in public
- I am looking for a way of passing things on that suits my craft → A trace is not necessarily code
- A useful resource is still hard to find → Publish where people search
- We want to check whether a resource helps the people it is for → Publish where people search
- I want to examine what can be shared, at what cost and with what agreements → What publishing really costs
- We want to agree on visibility and attribution that people choose → ⇄ Your team works under your name
- I want to share situated learning, with its limits → Nobody has written down what you know how to do
- I want to give the reader enough to examine my reasoning → An opinion is not an artifact
- We want to clarify the terms of internal or public sharing → ⇄ The absence of a rule is a ban
- We want to tie recognition to real contributions → ⇄ You are the only buyer who sees all the work
- A departure calls for a bounded, accepted handover → Leaving is not a betrayal
If no line matches, open the full contents. The builder test can also help: it gives your level and suggests a line of work.