Important problems are chosen and not assigned
💎CORE ARGUMENT
Hamming's question to his colleagues was roughly this: what are the important problems in your field, and why are you not working on them? I put it to my own roadmap and did not much like the result.
Writing the promotion case meant listing what I had worked on for two years. Nearly every line began with someone else's verb. Asked to. Given. Picked up after. The work was good. But I could not find the line where I had looked at the whole of Halden Flow, decided what mattered most, and argued my way onto it.
That is the claim. Nobody assigns the important problem. An organisation assigns what it already understands well enough to write a ticket for. The problems that matter most are usually the ones not yet legible enough to hand out, so the only way to get one is to choose it and make the case.
It is uncomfortable because being assigned is safe. If the assigned thing fails, the assignment was wrong. If the chosen thing fails, I was.
I am not saying every task should be important. Most of a job is maintenance and should be. What I am saying is that a portion of the year, perhaps a tenth, ought to go to a problem I picked and can defend, and that for two years my portion was nothing.
It breaks down on leverage. A senior product manager cannot simply choose the company's problem. I can choose within my reach, and I can ask for more reach, which is what the autumn was about. The answer in November was not this cycle. The question was still the right one. This note leans on 💎 Dignity is not the same as never asking for anything, since choosing a problem starts with being willing to ask for it, and on 💎 Knowing how I work is part of the job.
Where it arrived: Tram line 4, the day after the case went in.
🧱BUILT FROM
🌍WHY IT MATTERS
Each quarter I write down the most important problem within my reach and what share of my time it got. If the share is zero twice running, that goes on the agenda with Katarina. I do not save it for the yearly review.
☑️NEXT STEPS
- List the three important problems in the Operations Suite, in my own view
- Ask Katarina which of them she would back
- Put the quarterly share-of-time number in the review template
📖 Hamming on important problems: keep a short list of the important problems, and be honest about why today's work is not on it.
💎 Knowing how I work is part of the job: choosing well depends on knowing what I am good for. 💎 Dignity is not the same as never asking for anything: for three years I mistook waiting to be chosen for good manners.
Organisations hand out work that is already understood. The most valuable problems are not yet clear enough to assign, so they go to whoever names them and argues for them. Waiting for a good assignment selects for the well-specified problem over the important one.
💎 The structure of a system explains more than the people in it, which I also believe. If structure explains more than people, then who works on what is mostly decided by the org chart, and telling an individual to choose better is close to blaming her for the reorganisation. Both are true. I can choose inside a structure, and the structure sets how much choosing there is.
Put to readers in 📝 Issue 47 - Who chose your important problem. Put to the committee in 📂 Promotion case for Group Product Manager. It began with 📜 Ask for the promotion out loud.