>A rigid business plan gets one locked into a preset invariant policy, like a highway without exits —hence devoid of optionality. One needs the ability to change opportunistically and "reset" the option for a new option, by ratcheting up, and getting locked up in a higher state. To translate into practical terms, plans need to 1) stay flexible with frequent ways out, and, counter to intuition 2) be very short term, in order to properly capture the long term. Mathematically, five sequential one-year options are vastly more valuable than a single five-year option. - Nassim Taleb on [[Convexity Bias]] The lists, if you can call them that. Frighteningly disorganized musings portraying beautiful, unadulterated, discovered work - abound in Figma designs, as `// TODO:` and `// FIXME:` comments in code, and as quick one-off messages to self or other in [[Slack]] - their curators silently mocking the abhorrent imagination of what [[JIRA]], [[Trello]], and the team backlog thinks needs to be done. Why do these lists disagree so fervently? Because the former are *discovered* whereas the latter are *imagined*. During the course of any creative work, [[Knowledge Workers]] develop, whether explicitly recorded or not, mutable sets of the following categories - Things they must do - Things they want to do - Things they could do - Things they would do if X, Y or Z - All of the above except replace "they" with "others" Allowing good people to discover their work, by challenging them to solve [[Fixed Time Variable Scope]] problems, rather than asking them to imagine and commit to what they need to do beforehand improves satisfaction, productivity, autonomy, and [[Trust]]. This pattern focuses on balancing multiple scales - Commitment and [[Optionality]], and Reporting and [[Transparency]]. #### Commitment and Optionality First and foremost, we commit to what problems to solve, not how we're going to solve them. Until we get to work, the lowest level of detail we've recorded is the problem and its solution bounds, determined by the powers to be of the business. *Then* we get to work. >The team naturally starts off with some imagined tasks—the ones they assume they’re going to have to do just by thinking about the problem. Then, as they get their hands dirty, they discover all kinds of other things that we didn’t know in advance. These unexpected details make up the true bulk of the project and sometimes present the hardest challenges. - Ryan Singer, [[Pitches]] As we discover our work, we write it down and we categorize it. It's visible to others solving the same problem and might give them ideas. Discovering new work does not commit us to doing it, but provides us with options, the possible paths we can take. All this while we've never stopped working towards a solution to our problem. When we come to a fork in the road we look up at our list we realize we can make [[Trade Offs]], we can choose our path. #### Reporting and Transparency Enabling a team to discover work is a gift imbued with trust, and the common favor to return is transparency. A solid foundation for this balancing act [[Draw Clean Lines|Draws Clean Lines]] around what is being reported and what is being done. In [[Objectives and Key Results]] for example, higher level reporting is done against objectives, whereas access to and definition of Key Results is limited using the [[Functional Access Only]] principle. ### Problems Difficult or interdependent and blocking problems are being discovered too late and resulting in [[Tech Debt]] instead of [[Trade Offs]] Teams don't know how to [[Making Progress|Make Progress]] with no backlog or assigned lists of tasks Teams are committing to completing tasks instead of solving problems Scope changes are impacting reporting but not results People are keeping scattered lists of work in code ### Claims - Engineering and design teams can be more successful and satisfied with more autonomy and creative freedom - Properly balancing reporting and transparency leads to higher trust factors - Recording discovered work *as it's discovered* is an avenue to focus ### Tools There are plenty of tools you can use to help implement this pattern, but the key is to find the attributes that will provide different levels of information fidelity for reporting on status and organizing discovered work. [[Basecamp]] for example, allows users to track overall status of a scope on [[Hill Charts]], which shows progress over time, and organizing to-dos within those scopes as discovered work. Tools like [[JIRA]] and [[Trello]] allow users to track progress of a card through columns on a board. In Trello you can add discovered work to to-do lists inside each card. In [[JIRA]], if your cards are Epics or Tasks, you can track discovered work as Tasks within Epics or Sub Tasks within Tasks. ### Avoid Starting projects by coming up with lists of [[Imagined Tasks]], get to work instead of start discovering while doing. ### Related Patterns - [[Do The Hard Stuff First]] - [[Pitches]] - [[Objectives and Key Results]] ### Further Reading - [Imagined vs. Discovered Tasks](https://basecamp.com/shapeup/3.1-chapter-10#imagined-vs-discovered-tasks) - [[Convexity Bias|Understanding is a Poor Substitute for Convexity]] ### Antipatterns [[Context Switching]] and its sister antipattern [[Ripples]] can cause people to unintentionally reprioritize their work and introduce [[Imagined Tasks]] ^antipattern-1 ### Categories #transparency #todo-lists #optionality #reporting #backlog #commitment #trade-offs #tech-debt #scope #tasks #autonomy ![[✉️ Subscribe For Updates#^subscribe]]