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 week’s pattern, Discovered Work focuses on balancing a couple of scales that are central to the patterns of Long Pressed - 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. - Shape Up

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 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 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

We use Pitches to hand off responsibility for solving batches of fixed time variable scope problems to the teams. We use Now, Next, Thinking About to transparently and accurately portray what we know today to our stake holders.

Further Reading

• Imagined vs. Discovered Tasks

• 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.

Don’t forget to share and subscribe!

Subscribe now

Share

When framed properly and handled with care we believe Feature Requests are a powerful pattern. As you'll see, the antipatterns are in our own behavior as a response to a feature request, not in our customer's behavior in initiating one.

If you talk to a customer and they ask you for a new feature, or they tell you how they think something should work, what's your reaction? Is it any of these? 👇

• Come up with reasons why we won't do it

• Commit to doing something "like that" in the future

• Write it down, let them know we wrote it down, and move on

• Change the subject

• Commit to changing our priorities and work on it instead

Solution

Reframe your conversation with the customer from supply, you've been supplied a feature request, to demand, there could be an underlying struggle to make progress that you need to discover by digging deeper.

We recommend a simple heuristic. Identify the problem that the customer is trying to solve with their request and ask them what they're doing today to solve that problem instead.

If they’re demonstrating a suboptimal, compensating behavior then it will be worth your time to explore. At the very least you’ll have an interesting conversation. If they're not doing anything to solve that problem, then you need to ask yourself whether there's a problem worth solving and consider having a teaching moment.

Claims

Customers are more likely to dig deeper into their own struggles and provide you with further insights when you help to reframe their thinking and encourage thoughtful discussion.

Related Patterns

Culture Fit - When hiring, consider the interactions a candidate will have with the customer. Do they have the emotional intelligence and self awareness to reframe instead of react?

In Hunting for Jobs (to-be-done) we focus on discovering the real reasons why our customers hire and fire our products.

Avoid

Developing a solution on the spot with the customer or talking about your own feature ideas. Use time with customers to identify demand, where do they really struggle to make progress?

Antipatterns

Unconscious Bias - many of the problems related to this pattern can be associated with biases we have about our customers! Recognize them and be thoughtful and purposeful instead.

Further Reading

• Competing Against Luck

• Demand Side Sales

• Know Your Customers' "Jobs to Be Done"

• The Jobs To Be Done Playbook

Each week we feature a pattern from Long Pressed - a highly connected graph of product, people, software and design patterns that explores the way we work.

Subscribe now

Share

Now, Next, Thinking About

It's inevitable, at some point you'll be asked to officially write down what you think you're going to do in the future. It's scary, the future is going to arrive and what you thought you were going to do isn't what you think you should do now. Don't panic. Don't start googling product roadmap templates. The fact is, there's work you're doing right now, work you're considering doing next, and a bunch of other stuff you've recently thought about. If those things are already recorded in some layer of your Writing Stack then you're 90% of the way there. The other 10% is framing that what you think you're going to do next could change and what you're thinking about is most likely going to change.

The actual contents of each category of this pattern depend on the time scale in which you actually commit to and complete work. For example, if your smallest work increment is 6 weeks, then what is committed to the current 6 weeks goes into now, and what might be committed to the next 6 weeks goes into next. It's helpful to make the time scale and team size clear up front so that your audience has a sense of how many "Nexts" can fit into the next "Now".

Now

• This work cannot be changed unless there is a major problem in stakeholder Alignment

• Updated at the beginning of every work increment to reflect what is now being committed to being completed

• The team is accountable for this work

• Everything in this category has already arrived at the design or engineering level of work

Next

• Stakeholder feedback is welcome

• Updated at the beginning of every work increment to reflect what is being considered and shaped next

• No commitment to do something if we happen to find out it's not the right thing or the best thing to do next

• Everything in this category is currently in the product management level of work

• Not everything in this category will fit into the next "Now"

Thinking About

• Your conversation starter, where you need to gauge interest and alignment

• Keep it to about 1 year max

• If you're not thinking about anything beyond "Next" then leave it out, don't make it up!

• Only needs to be revisited if your highest level product strategy changes

Problems

Teams are struggling to find themes in upcoming product work to represent as a roadmap, or roadmaps are disconnected from the Source of Truth of their ideas.

Long term plans used to lead discourse about potential future product or business scenarios can easily be misconstrued as Commitment by stakeholders, resulting in an unintentional loss of Optionality.

Bigger Problems

This pattern requires sufficient discipline of a Writing Stack in order to remain connected to a Source of Truth.

This pattern is extremely difficult to implement if product teams work off of backlogs using scrum or kanban style patterns due to an inability to discern ordered themes of varying levels of fidelity from an ordered list with a single level of fidelity. Instead, we recommend working on Fixed Time Variable Scope projects.

Observations

Whereas Objectives and Key Results and Hill Charts are about Making Progress, Showing Progress, and Seeing Progress, this pattern is about reporting status. The difference is that the progress patterns are designed to be dynamic, updating in real time, rather than static (hence "status"), updated on a specific cadence.

Many of our patterns Draw Clean Lines by passing different levels of information at different time scales via an interface or a protocol.

Related Patterns

Engineering and design teams are encouraged, via Discovered Work, to expose their thinking, make trade offs, and aren't committed to doing something if they happen to think it's not the right thing to do in the moment.

Tools

A Writing Stack can help teams more efficiently leverage their Source of Truth of information for what they think they'll do next and what they're thinking about in general.

If you think someone else can benefit from learning about this pattern please share it and if you haven’t already don’t forget to subscribe!

Subscribe now

Share

Tribal Knowledge

Tribal Knowledge refers to a dependency on people for the dissemination of important information and the execution of critical processes. There are two "fears" related to Tribal Knowledge

1. A significant branch of important information or a critical competency will be lost if an employee leaves the company

2. A significant branch of important information is safeguarded by an individual or a team for reasons other than the Functional Access Only or Draw Clean Lines principles

Overcoming the challenges of Tribal Knowledge may require aligning longer term incentives so that team members have Skin in the Game.

Bigger Problems

A sub-category of tribal knowledge is the intellectual property that is stored in code. Version Control is an invariant pattern of any Modern Business that writes their own software.

Related Patterns

Writing Stack - we talk about using Stack Overflow Teams to dynamically move tribal knowledge to a formalized system over time and out of Semi-Ephemeral Chat.

Good Culture Fit practices can help build a team that thinks long term and avoids a situation in which tribal knowledge translates to job security.

We feature a new modern business pattern weekly via our newsletter, so don’t forget to subscribe and share!

Subscribe now

Share

When is the kitchen a pattern, a context, or a form?

When we talk about kitchens in general, we’re talking about the pattern, kitchens.

When we talk about whether you need to build a kitchen due to the invariants of some larger pattern such as a home, or which smaller patterns within the kitchen you’ll need to implement such as the stove, we’re talking about the context, kitchens.

When we talk about the specific kitchen that you end up designing and building, we’re talking about the form. When you look at a specific kitchen, it is instantly recognizable as a kitchen because of its form.

When you use a kitchen that’s already been built to solve a problem, you are using the form within your own context. Let’s say you want to boil some water for tea. The pattern “Boil Water” is a child pattern of the Home -> Kitchen -> Stove -> Pot pattern hierarchy. Since boiling water and so many other cooking related patterns are enabled almost exclusively by the given hierarchy and its sibling hierarchies like Home -> Kitchen -> Sink, we don’t include a “Boil Water” pattern in our Home pattern language. The form enables the user to boil water without explicitly specifying the pattern.

Is this business related?

On Long Pressed, our readers’ largest pattern is the Modern Business. They land on our site because they want to build a successful Modern Business. Their specific context has them attempting to identify the smaller patterns of Modern Business that, if they build, will solve their unique challenges.

The smaller patterns of Modern Business that we focus on are the Teams, Product, Software, and Design. These are the kitchens. Your kitchens aren’t necessarily going to look like our kitchens, but they’ll be instantly recognizable as kitchens anyway. Of course, we dig much deeper with the hierarchies of Modern Business patterns that you’ll want to explore.

It’s important to understand that Long Pressed is an evolving pattern language developed by the leadership team of a real product development and engineering organization. It is a form of pattern language.

The patterns we choose to write about are those that we’ve implemented in our own business context throughout the last 5 years, not simply read about or studied. While it’s an opinionated take on what to do, how, why, and when (pattern, solution, problem, and context) we also try to identify, understand and present the forces at play as a decision making framework for the reader.

We understand that not every business can adopt “large” patterns all at once, nor do we think they should do so blindly. We feel that most modern business patterns are presented at too high of a level and are unrealistic insofar as they set an expectation to be implemented holistically or not at all. Its clear to us, for example, that you may be able to benefit from Hill Charts even if you can’t fully adopt Shape Up, as long as you understand the contexts in which they can be implemented, the tools available to you to implement them, and the challenges they’re intended to solve. The eschewing guidelines of patterns like Scrum, “Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless,” are self-defeating. We encourage iteration and adaptation rather than rote adoption. The way that you work is only the means, but we believe people can love the way they work.

A Pattern Language is a book by Christopher Alexander that - while originally touted as tackling challenges in architecture, urban, and community design - pioneered a powerful, hyperlinked problem solving heuristic that could be leveraged by anyone with enough experience, curiosity and 🤔 moments to recognize the patterns of their domain.

They create life, by allowing people to release their energy, by allowing people, themselves, to become alive. Or, in other places, they prevent it, they destroy the sense of life, they destroy the very possibility of life, by creating conditions under which people cannot possibly be free. - Christopher Alexander on patterns which are alive

Long Pressed is a work of such curiosity regarding the design and decision making challenges of Modern Business. It is based on our experiences and opinions in Product Development, Software Design, and Teams. Those patterns which allow people to thrive, to become alive. An additional category of patterns, Antipatterns, explores some broader problems with are a detriment to the success of a Modern Business. Those which create the conditions under which people cannot possibly be free.

If you’d like to stay up to date as we publish the patterns we work by subscribe to our newsletter!

Subscribe now

Share

This week's guest pattern, COMPOSE, was developed by Writing.coach founders Ellen Fishbein, Dr. William Jaworski, and Samuel Nightengale after more than 20,000 hours of collaboration with hundreds of writers. You can find COMPOSE in its original format here.

COMPOSE stands for:

C = Concept 🔥 Your subject in general.
O = Objective 🚀 What you want your reader to think, feel, do, or understand.
M = Material 🎨📚🧩 The definitions, descriptions, stories, arguments, data, and examples you'll need to meet your objective.
P = Plan ♟ A flexible sketch of how the material will come together.
O = Organization 🏛 The precise order in which you'll present the material.
S = Style 🕶 Your unique voice expressed in writing that's fun to read.
E = Elegance 🥋 The ultimate polish that makes hard work look easy.

Using COMPOSE

Writing well involves executing all 7 steps of COMPOSE (not necessarily in order). By executing COMPOSE mindfully and repeatedly, you'll get better at sidestepping and solving these problems every time you write.

Concept: Your subject in general

Your Concept answers the question, "What are you writing about?"

Find inspiration in something that stands out as important or meaningful - something you did, felt, learned, witnessed, or discussed with someone. A powerful Concept is something

• You're excited to think or talk about

• You notice excites others as well

• You understand well or want to understand better

• You innately learn more about through discussion with others

By the end of the Concept phase, you'll have a jumble of interesting ideas - a "primordial soup" of thoughts with the potential to carry you to the final product.

Objective: What you want your reader to think, feel, do, or understand

A promising concept can take you in many directions. Pick the best one.

Think about your readers and what you want to communicate to them. Ask yourself, "What am I trying to get my reader to think, feel, do, or understand?"

What is your Objective?

Maybe you want the reader to learn a new skill, buy something, believe something, empathize with you, laugh, or offer you a job. Your Objective can also aim at personal growth - understanding something better yourself. The quest is no less worthy.

Projects don't survive without a clear Objective. Yours will lead you from a blank page to the final draft.

Material: The definitions, descriptions, stories, arguments, data, and examples you'll need to achieve your Objective

What's going to get your readers to think, feel, or do what you intend? How will you achieve your Objective?

Your aim during the Material phase is to build an inventory of everything that can help. You'll use your own words and go One Level Deeper to process the things you've researched, learned, thought about, experienced, discussed, or imagined. Nothing has to be in order yet; just lay it out in front of you.

Even if you don’t end up using a particular anecdote or bit of research, writing it down isn't a waste. It’s a rehearsal. If you take the time to play with your ideas, you’ll understand them more deeply, and your performance will be better for it.

Plan: A flexible sketch of how the Material will come together

Outlines are a waste of time. They're too linear, granular, and inflexible to help at this stage. Don't marry yourself to a particular structure yet.

Instead of an outline, make a high-level Plan - a few sentences, a drawing, or something else that gives you a clear sense of your main points and core material. Plan to cover the essential points, and only the essential points.

Organization: The precise order in which you present the material

Just as random letters don't make words, and random words don't make sentences, random material doesn't make a message your readers can understand. Your material needs to be organized in a way that readers can follow.

Organization is determined in part by your Objective. If you’re writing a how-to guide, your material is ordered into steps for readers to follow. If you’re telling a story, the events you’re describing are ordered in time. If you’re trying to prove a point, your ideas are organized logically - some of them provide support or evidence for others.

Longer pieces of writing will often have parts with different kinds of Organization. For example, you might incorporate a narrative into an argument that supports your thesis.

Style: Your unique voice expressed in writing that is fun to read

Effective writing captures not just what you want to say, but how you want to say it—your unique voice. 

Style includes all the tricks, tools, and techniques that make writing fun to read. That toolbox includes advice you heard in school: use the active voice, avoid adverbs, master punctuation, and use verb phrases instead of abstract nouns. 

What they probably didn't tell you in school is that Style matters only at a late stage in the writing process. It’s only when you’re really sure about what you want to say that you should start thinking about how to say it. Style comes only after you've worked through COMPO.

Elegance: The ultimate polish that makes hard work look easy

“Beauty walks a razor’s edge; someday I’ll make it mine.” - Bob Dylan

If you’re reading something that’s not only meaningful, but also fun and memorable, you’re not looking at a first draft. More likely, it’s the 100th draft. It takes hard work to produce an elegant result. That’s why elegance signals competence.

We aspire to elegance—for your work as much as our own. We test each composition, paragraph, and sentence by asking: is this as smooth and simple as we can make it? 

Writers reach elegance the way martial artists reach the black belt. Your work will become more elegant the more you practice COMPOSE, and that will set you apart as a writer.

Problems

Omitting critical steps of the writing process causes us to try to write a final, refined piece too early or quickly.

Struggling to turn low-fidelity notes and research into thoughtful writing.

Not knowing how to Make Progress when trying to write, getting "stuck".

Related Patterns

In Templating Time we cover a technique for planning your time that might be able to help with the Plan stage of COMPOSE.

In Writing Stack we talk about how we leverage different levels of fidelity of writing about the same Material to help Organize writing and meet our communication Objectives.

Tools

A lot of the steps of COMPOSE rely on nonlinear thinking. There are plenty of Tools for Thought that can help such as Roam Research.

Further Reading

• COMPOSE

• COMPOSE As a Tweet Storm

• POP Framework for Memorable Writing

• What makes Paul Graham a great writer?

• Mastery of Metaphor

If you think someone else can benefit from learning about this pattern please share it and if you haven’t already don’t forget to subscribe to Long Pressed!

Subscribe now

Share

An affordance is a result which you offer someone through an interaction with your product.

A signifier helps your user understand the affordance which you are offering.

The use and definition of the words "Affordance" and "Signifier" can be a point of contention amongst software designers, product managers, and design generalists. I'm offering an explicit distinction between them not to be contentious, but to help draw clean lines through the roles of product management and design.

We want our product managers to worry more about choosing the right affordances for our users and less about choosing the signifiers of those affordances, an area which good designers can be entirely entrusted. At the same time, we want our designers to understand that their job isn't to draw a button on the screen, but to offer the user an affordance.

A simple heuristic to determine whether you're discussing an affordance or a signifier is as follows

If X affords Y then Y is an affordance AND
If X signifies the affordance Y, then X is a signifier

Note that you must identify an affordance first in order to identify a signifier.

For example, the screen affords tapping the button, and tapping the button affords exporting the data. The affordance we discuss when designing our software is exporting the data. Unless a button is specifically required to signify such an affordance, we don't bother prescribing it (for example it's too prescriptive for a pitch in Shape Up). Apple's product management team on the other hand probably talks about the affordance of tapping on the screen.

Further reading: The Design of Everyday Things
On Long Pressed: Affordances and Signifiers

-Justin

Subscribe now

Share

The Jobs-to-be-Done framework, made famous by Clayton Christensen & Bob Moesta focuses deeply on understanding your customers' struggle for progress and the causal mechanisms of their behaviors.

It's a beautifully simple metaphor - a "job" is defined as the progress that a customer desires to make in a particular circumstance. Customers buy or "hire" a product for the specific job. When they hire a new product, they fire an existing one.

When practicing the framework within our business, we need to use techniques that expose customers' underlying job requirements. We need to understand the functional, social and emotional dimensions that go into the hiring decision. And we need to understand the trade offs the customer is willing to make.

The solution lies not in the tools you're using, but what you are looking for and how you piece your observations together. If you can spot barriers to progress or frustrating experiences, you've found the first clues that an innovation opportunity is at hand. - Clayton Christensen, Competing Against Luck

Where the hunt begins

So how do we practice this framework within our business? According to Christensen, a good place to start is with asking yourself these questions

• Do you understand the real reason why your customers choose your products or services? Or why they choose something else instead?

• How do your products or services help your customers to make progress in their lives? Where are they trying to make progress?

• What is competing with your products and services to address these jobs?

Hunting For Jobs

What they hire - and equally important - what they fire - tells a story.

The high-level goal is to expose the underlying functional, social, and emotional reasons why someone hires a product.

Finding a job close to home

Understanding the unresolved jobs in your own life can provide fertile territory for innovation. Some of the most successful innovations in history have derived from introspection.

Workarounds and compensating behavior

You can learn as much from people who aren't hiring, as you can from those who are. This "nonconsumption" often represents the most fertile opportunities for innovation. What compensating behavior are these nonconsumers taking to make progress? These folks have literally invented their own solution to their problem.

Look for what people don’t want to do

Christensen calls these "negative jobs." For example, the hassle and huge time investment that comes with visiting the doctor for routine treatment, is a job people don't want to do. The emergence of the pharmacy clinic (i.e. CVS MinuteClinic) is an innovation born from that job.

Unusual Uses

Closely study how customers use your products, especially those uses that are unusual and unexpected. Often companies can find growth opportunities where it never seemed possible. Christensen's example here is the story of Arm & Hammer's iconic baking soda. The company thought their product only fit within the "baking" category. They realized they had new growth opportunities hiding in pain sight after observing customers hiring their baking soda for deodorizing refrigerators, keeping swimming pools clean, freshening carpets, and removing shower stains.

The “Emotional Score”

In our experience, this is most often missed at most companies, and yet, it's probably the most powerful in terms of results. We would recommend checking out the further reading section below on this one, but the summary is that you need to fully understand the context of a job before you can innovate to solve it. This almost always means more focus on the social and emotional dimensions of the hiring decision.

Problems

Extreme variability in successful new products or attempts at innovation. 

I don't know why people purchase my products (or other products). 

I don't know why customers stop using my product. 

I don't know why customers switch to my competitors' products.

Avoid

• Focusing only on current customers

• Focusing only on functional product observations

• Focusing only on the "big hire" (when a customer purchases a product) and neglecting the "little hire" (when they actually use the product)

• Focusing only on the hire (what the customer bought), and not the fire (what they stopped using)

Tools

Customer Interviews are the most important tool when you think about the Jobs-to-be-Done framework. There are various ways to find existing customers to interview. (start with your email list and offer incentives)

Respondent.io is a great tool for finding interview candidates from outside your current customer base

Related Patterns

In Feature Requests we similarly reframe our thinking relative to our customers' behaviors and strive to dig deeper.

Further Reading

• Competing Against Luck

• The Jobs To Be Done Playbook: Align Your Markets, Organization, and Strategy Around Customer Needs

• The Jobs-to-be-Done Handbook: Practical techniques for improving your application of Jobs-to-be-Done

If you think someone else can benefit from learning about this pattern please share it and if you haven’t already don’t forget to subscribe to Long Pressed!

Subscribe now

Share

Try as you might, you will never be able to avoid Context Switching altogether. You can reduce it to the bare minimum but eventually you have to shift context - from one part of a project to another, one project to the next, or from work life to personal life.

There is a certain school of thought that advocates you should draw back, reduce exposure to outside influences, and become a hermit. An exaggeration sure, but the sentiment is pervasive.

If you decide you want to learn to meditate and you envision yourself at the top of a lonely mountain, eyes closed in silence breathing in fresh air with every breath, your teacher will question your self-awareness. What good will meditation do you in isolation? Do you not want to participate in life? A true master can meditate in the middle of a busy street without being disturbed.

The same is true for context switching and deep work. You can develop the skills to drop into focus when things around you are crazy. Of course, this isn't without bounds. ADHD is a real crutch. If you're not into the bustle of a coffee shop, nobody is going to expect you to be able to do deep work in one without a great pair of noise canceling headphones.

Interstitial Journaling

Apart from trying to minimize the frequency of your context switching in the first place, you can make the process itself faster and less cumbersome. You can reduce your Dynamic Loading times.

The way to do this is interstitial journaling. By taking notes as you work, you can create "hooks" that your mind can grab onto when you return to a project or task and making loading the context into your brain much faster.

While interstitial journaling alone can be useful, you can further improve workflows by using tools to overcome procrastination.

Pomodoro Technique

One reason the Pomodoro Technique works so well for some people is that by setting a timer you immediately reduce the horizon in which you have to focus. A decade-long project becomes much less scary if you force yourself to keep going for just 25 minutes and only have to consider what you need to accomplish in that amount of time. Setting the timer can dramatically reduce the amount of procrastination you're doing.

Just setting the timer often isn't enough, though. Apart from the scariness of long timescales, you need to know what you're going to do until the timer goes off. The solution of a lightweight checklist of questions to figure out that help you avoid obstacles that might get in your way.

Work Cycles

We tie interstitial journaling, the pomodoro technique, and more efficient context switching back together with the Work Cycles method developed by Sebastian Marshall at Ultraworking. We plan a work cycle by asking ourselves 3 questions.

• What do I want to accomplish?

• How exactly do I want to start?

• What do I want to avoid?

The value lies in being precise with your answers. Similar to Discovered Work, you don't want to write down answers to how you are going to spend your time that can be enumerated into limitless possibilities. "I'm going to write the first paragraph of the introduction of my dissertation" is much better than "I'm going to work on my dissertation". At the end of your time spent focusing you can actually say whether your goal was accomplished.

Knowing how to start (I am going to open up RStudio and look at analysis.R) and writing down your obstacles (If I get interrupted by a delivery I will bring it into the house and immediately return to work) helps you to get started because you've pre-loaded actions that don't need to be considered and distracting in the moment.

Finally, reviewing work you've completed on an interview is crucial as well. You'll want to grade yourself on how well you actually accomplished what was planned. This will give you a chance to write down new thinking in your current context via interstitial journaling, re-scope your time, and observe your working environment - distractions, state of mind, etc.

We recommend at least 30 minutes of work coupled with 10 minutes of planning, or longer for deeper work like coding and writing. You can combine these cycles into longer blocks in order to plan your context switching ahead of time. A/B switches between days don't cost as much when you implement interstitial journaling to save your work contexts.

Problems

I have multiple unrelated projects that I need to work on in a single day 

I could get this task done if I could figure out how to start and commit a small amount of time without getting distracted

Claims

By using templates to guide your interstitial journaling, you can make returning to a project much easier, prevent procrastination, and spot patterns in your work to amplify or counter.

Longer time scale patterns like Objectives and Key Results can help you regain focus when you’re starting from a blank slate, such as at the beginning of the day when you need to decide where to spend your attention.

Avoid

Over committing to the number of things you can work on each day with this method. 2 is preferred, 3 is possible, anything more is too much.

Tools

There are a lot of tools out there that provide the templating needs to implement this pattern and you don't need a special timer for the Pomodoro Technique.

From Ultraworking, you can find a Google Sheets or Excel Template to guide you in work sessions.

Cortex Futura provides templates for Roam Research in a public roam graph

Further Reading

• How to use Roam Research for Interstitial Journaling

• Interstitial journaling: combining notes, to-do and time tracking

• Work Cycles

• Pomodoro Technique

If you enjoyed reading about this pattern please share it and if you haven’t already, subscribe for more!

Subscribe now

Culture fit is a vital part of building and maintaining a high performing team and has become a popular assessment during the hiring process. It's more obvious how to assess someone's technical abilities and the hard skills needed for the job, but how does one think about and evaluate culture fit? What is culture fit?

Culture fit assessments should focus more on whether this person will thrive within your current working environment. How they will interact with the company's work patterns.

Rarely are two companies alike, but you can observe common patterns across environments. Knowing your work style patterns will help you find people that can effectively work in your environment. This is the meaning of culture fit.

Patterns of working environments

Good cultural patterns create a living environment and organic engagement. Everyone has skin in the game and feels empowered to do their best work.

Bad culture patterns can rob people of their sense of belonging. They can deter people's ability to thrive.

They create life, by allowing people to release their energy, by allowing people, themselves, to become alive. Or, in other places, they prevent it, they destroy the sense of life, they destroy the very possibility of life, by creating conditions under which people cannot possibly be free. - Christopher Alexander on patterns which are alive

Asynchronous vs. Synchronous

Organizations vary from asynchronous to fully synchronous collaboration environments. In asynchronous companies, people work on their own time. Most decisions in these organizations are made independently or using asynchronous communications tools (i.e. email, long-form writing tools). Synchronous-first companies spend a large portion of working hours in groups and require frequent meetings to get in sync and make decisions. These contrasting work styles require different mindsets, tools, and experiences. We need to assess the candidate's ability to fit and thrive in a given environment.

Here are some traits to look for when hiring people for asynchronous work environments.

1. Hire people that feel comfortable working alone and thrive on deep work.

2. Clear and concise written communication is critical. When working asynchronously, it's often necessary to make decisions or to integrate your work with others. Thus, all employees should be able to clearly and concisely communicate their points in written form.

3. Hire Managers of One. Asynchronous work requires relentless self-management and focus on outcomes.

We strongly recommend and prefer optimizing for asynchronous work even when hiring people in a more synchronous environment. People that thrive asynchronously can often succeed in more synchronous environments, but the reverse isn't true. 

If your environment is more collocated and heavy on meetings, you should also ensure you hire people that:

1. Can concisely and clearly communicate verbally

2. Aren't afraid to speak up in a face-to-face meeting

3. Are more extroverted and don't feel drained by the abundance of face-to-face interactions.

4. Can stay focused through many distractions and are not afraid to say no.

Remote vs. collocated

Commonly companies fit on a spectrum between collocated and remote. Even within a company, departments vary on the remote spectrum. People that thrive in asynchronous environments are already well equipped to perform in Remote Work environments, but there are a couple of traits you can look for.

1. Does this person have a quiet place where they can think and work deeply? If not, the company can choose to provide such space in co-working or other facilities.

2. Remote doesn't typically mean asynchronous all the time. You still need to make time to integrate your work and get in sync from time to time. If you're hiring people in various timezones, ensure there is time flexibility or enough of a work day overlap to allow for these interactions to happen without being forced.

There are certain types of work that might require more collocation or proximity to a location. For example, product managers should typically spend a lot of time talking to customers. For many companies, remote interaction with the customer might be enough, but there is no getting away from being onsite in some industries. For example, if you develop manufacturing software, there is no way to avoid spending time in a manufacturing plant to understand customer struggles.

For jobs that require onsite presence, ensure that the person you're hiring has the ability and the will to be onsite. Sometimes employers who try to attract employees underestimate how much time onsite will be required to be successful. Be honest and transparent about the requirements for being physically present.

Centralized vs. decentralized decision making

In some companies, decisions are made from the top by the CEO, product manager, or lead developer, who pass it down to the people doing the work. In others, people doing the work have more latitude to make certain decisions. Even within a single company, these principles can vary from department to department and team to team.

Decentralized decision making is a spectrum. No company is a true democracy, nor should it be (we prefer an Idea Meritocracy if possible). But companies that force more decisions downstream benefit from employees feeling more empowered, and as a result, they are more engaged.

Employees want to feel empowered and seek a feeling of belonging. Companies that lean more towards centralized decision making create an inner conflict and deflate morale.

Patterns which prevent us from resolving our conflicting forces leave us almost perpetually in a state of tension - Christopher Alexander

• Hire people who love being empowered and are good at making trade offs.

• Assess how people view mistakes. Good employees view failures as learning opportunities rather than something to avoid at all costs. Ask about a recent failure and what resulted. Did it lead to more processes and risk aversion or a better outcome?

• Ensure you genuinely have an environment that promotes decision making, as people who want to own their work and making progress will quickly lose motivation in such conditions.

If your environment is more on the centralized decision spectrum, you should be honest about this during interviews. Hiring hourly contractors might be a good option in these environments. Many contractors are happy to just do the work you pay them for.

Risk aversion vs. risk taking

There is also a big difference between companies' cultures when it comes to risk-taking. Many companies embrace the "move fast and break things" mantra, where others lean more towards the "don't break things" side.

Find where on the spectrum your company fits. If you are all about taking risks:

1. Hire people who have a bias for action and are Independent Thinkers

2. Hire people who know how to break a project down to its necessary parts and focus on essential vs. trivial

3. Favor people who try to deeply understand the problem before going all-in on a solution.

4. Hire people who view mistakes as opportunities to learn and iterate

There are some companies that by the nature of their business have to lean towards less risk taking. Companies in the financial industry that handle large amounts of money, companies in the healthcare space that in addition to dealing with private patient data are also responsible for life or death decisions, have less tolerance towards risk. We find that, although managing risk is important in these companies, the majority of the true risk occurs at the edges of company activities. Still, risk aversion can swiftly spread to every other function of the organization. 

Companies where mistakes can be catastrophic by nature should have more processes and protocols in place to reduce chances of errors. In these environments:

• Hire people who are detail oriented and can thoroughly analyze side effects

• Hire people who can balance decisions about what's risky and requires more thorough analysis and work vs. what elements of a project would benefit more from quick action.

Problems 

Hiring people who don't fit into your current work patterns can cause tension and rob the team of life. 

Most companies tend to assess for skills and technical abilities needed to perform the job, but fail to properly evaluate the culture fit.

Observations

• Teams that find a good culture fit among the team members will experience Organic Engagement. These interactions will lead to high productivity without the management overhead. 

• Most great work happens during Deep Work working alone and then integrating the individual pieces with others. We tend to rightfully emphasize the ability to work on a team, but take the ability to function and work deeply alone for granted.

Claims

How your organization functions is critical to knowing which people will thrive in it. For most Knowledge Workers, remote and asynchronous environments offer an advantage. Optimizing for remote and asynchronous will allow you to hire from a wider talent pool, unconstrained by timezones. 

Remote and distributed teams will benefit from moving more towards the asynchronous spectrum and hiring people who can productively work alone.

Tools

The best way to test for culture fit is to work with a person on an actual real-life project. Understand how they make decisions and Trade Offs and how they interact with the rest of the team and their environment. This is difficult or, at times, impossible to do in the real world. You're usually interviewing someone who already has a job or, for other reasons, can't dedicate their time.

• Present Past Projects - The best way we've found to assess for culture fit retrospectively is by having the candidate prepare and present their previous project(s).

• If you want someone to work on a real project which requires more than a few hours of work, you should consider paying them a fair rate for their time. Show people that you value their time. More candidates will be willing to participate, and they won't feel like you're taking advantage of them.

Avoid

Avoid creating a homogeneous idea environment by hiring people based on seeing eye to eye or having a common background or views. Having a diversity of ideas, experiences, and backgrounds (cultural and professional) is vital for the success of Modern Business. Focus more on skills, problem-solving abilities, and approach to work.

Related Patterns

• Objectives and Key Results

Further Reading

• Perils of Incessant Teamwork

If you enjoyed learning about this pattern please subscribe below and discover more on Long Pressed

Subscribe now

Subscribe now

Objective

Improve transparency, alignment, focus, collaboration, and motivation of cross functional organizations in the next six months.

Key Results

1. Set ambitious monthly objectives for each team and identify three to five weekly, measurable key results to get them there.

2. Transparently report weekly progress towards objectives and monitor each team's key results.

3. Meet bi-weekly to evaluate the efficacy of the key results and adjust as needed.

Objectives are meant to be ambitious, and even failing to reach them, through the underlying activities and measurement of key results, will oftentimes deliver substantial value anyway.

Key Results are measurable activities and can be noted as completed or not at each check-in interval. In the case of Google OKRs, each key result is ranked from 0.0 to 1.0 as a measure of progress.

The objective time scale should ideally be several times longer than the key results check in interval, allowing for evaluation of the efficacy of the Key Results as a catalyst of progress.

An OKR program and its underlying data should be transparent to cross-functional teams.

Problems

• People have a difficult time with priority, focus, and alignment, being pulled in different directions because they don't have a single Source of Truth that says "This is what I need to be working on instead".

• Transparency between cross functional team activity

• Activities on a smaller time scale do not add up to goals at a larger time scale

• Organic Engagement and collaboration across teams

• Reporting progress towards goals feels subjective

• Lack of measurable results means relying on Gut Feel

Bigger Problems

Trust and Accountability - let's say you want to set an objective for inbound leads and a key result to drive traffic to your website. The expectation is that team members will strive to understand and iterate on a useful definition of "high quality traffic" in pursuit of the overarching objective, rather than cheap ads in pursuit of the key result. If leadership thinks the latter will occur, there is a trust problem, if the latter does occur, there is an accountability problem.

Claims

• Clearly communicated, ambitious team goals can help attract the best talent

• First Level Explanatory Concepts are the easiest to understand catalysts of action. The mechanisms underlying balanced goal settings result in changes to individual plans, intentions, tasks, etc.

Tools

Basecamp for Product Teams

If you're already using Shape Up to track projects in cycles, you can use Basecamp teams to track objectives at a higher level. You can then use hill charts to measure the progress of objectives and OKRs in general to help understand which pitches to bet on based on whether they'll progress a team objective. Here is an example. Note you can even change the to-do list title to be called "Objectives".

Notion for Cross Functional Teams

Notion has a Template Gallery where you can find plenty of templates to build and track OKRs. You can also set permissions on individual pages to share progress towards objectives and key results with external teams. If you choose to use Notion, consider also making the underlying data for key results available to others as well. For example, if a Key Result is to interview 3 customers per week, create a template for interview notes, capture key customer information and attributes, and share it with other teams that can benefit!

Spreadsheets and Docs for Business Teams

You can always start with the simplest approach to OKRs and just use spreadsheets, just make sure you're committed to measuring, scoring, and reporting. Spreadsheets are a particularly easy approach if you intend on evaluating and reporting OKR statuses live during meetings or conference calls. You can find a simple OKR template here, and scorecards here. If you use Office 365, those tools should be easy to replicate or find online.

Avoid

Tying OKRs to compensation and Employee Evaluation. They're meant to be iterative and evolve to find an optimal balance of activities to achieve goals and make progress.

Objectives that maintain Status Quo. Watch out for words and phrases like "continue", "keep doing", or "maintain". If the objectives aren't exact then aim to use scaling words like "accelerate", "increase", "expand", "reduce", or "eliminate". Make sure the current state is clear and your magnitude of scale is ambitious.

Categorizing objectives. Don't set several objectives related to "Get Better At Sales" and communicate the category externally. This can unintentionally have a distracting Anchoring effect and result in the subjective analysis of OKRs - "Well we made progress on sales so we're good". The objective should be the highest explicit goal that is communicated as part of this pattern.

Prescribing the underlying activities required to achieve results. This can make all the difference, especially for Independent Thinking. For example, "write 3 blog posts" can accidentally prescribe who writes them, whereas "3 new blog posts" opens up possibilities for guest writers, cross posting, etc.

Producing unstructured data from key results that you can't leverage later to iterate and improve outcomes. For example, if your key result is to contact X qualified outbound leads, you need to track simple things like the message used for outreach, the company attributes used to qualify, and whether the contact was successful. If you can track enough attributes and outcomes, we can start talking about multivariate regression! (No we're not writing about that pattern. Actually maybe)

Furthermore

It's important to remember that OKRs are meant to be dynamic. Let's say you start with a "simple" objective: Lose 10 pounds this year. There are a number of ways to get there, but you have to decide your specific approach, your key results. You might say "exercise daily at least 30 minutes" and "eat less than 2000 calories each day". If you're not achieving the key results, you can't reasonably expect to achieve the objective, that's Accountability. If you are achieving the key results and not making progress toward the objective, you look at the data underlying the key results and iterate on what you think can get you toward the goal. This is where trust and Transparency plays a role and why key results have to be measurable.

Related Patterns

• Aligning Vectors

• Shape Up and Hill Charts

• Key Performance Indicators

Further Reading

• Measure What Matters

• What is an OKR? Definition and examples

• Set goals with OKRs

• Building a practically useful theory of goal setting and task motivation

If you got this far, please reach out to me personally on Twitter I’d love to know what you think!

The Writing Stack

Different people need to work on and consume written information at different levels of fidelity. For example, we don't want readers of this site seeing raw information organization or unfinished pages, but we need to see them and work on them!

Every application and website we use in our business has a rich text editor or free form text field. Let's be explicit in choosing which ones need to be ignored and implement a writing stack. We'll draw clean lines around where and how we capture, refine, and publish information to different audiences. Developing good writing habits at each part of the stack will result in better Transparency and more thoughtful Organic Engagement and discourse.

Team members at the same level should have the same access to each part of the stack such that they capture, refine, publish, and consume information in collaboration with each other.

Start by drawing lines between the Capture and Publish parts of the stack. Different teams might have different needs for each part but the best solution is going to require a publish component that can be leverage across teams.

Capture

You'll want to find the right balance for your team in terms of workflows, templating, and collaboration. A few decent templates for meeting notes, customer feedback, and ideas can go a long way. Information should be captured in a way that is transparent to adjacent team members.

Refine

Refinement is the stage of writing when captured information is developed before it is published to any audience other than adjacent team members. Refinement is best done in the same tool as capturing due to the One Level Deeper principle, but can also be done in the same tool as publishing.

Publish

Each part of the writing stack increases the fidelity of information. The publishing component of the stack is introduced when a new audience needs access to the information.

Problems

• Enabling someone to discover important information requires granting access to tools whose primary function isn't publishing information. See Functional Access Only

  • Example 1: Information is stored in a GitHub Wiki and you are finding that Program Management team members are constantly being granted access

  • Example 2: You're headed down a path of trying to consolidate all teams into the same Slack Workspace because that's where information "naturally" lands

• Onboarding new team members who will eventually be Managers of One is a major time commitment

• Anxiety due to lack of Transparency between team members and leadership

• Context Switching due to cross-functional team members inability to discover important information

Claims

Teams that fail to agree which types of information belong where, or have too many repositories of disparate information which offer the same level of fidelity and access develop Tribal Knowledge.

Tools

Capture

Notes.app - Surprisingly, if everyone on a particular team is in the Apple ecosystem then Notes.app can actually be a great way to implement the capture part of the writing stack. You can easily share different folders in notes with different people, and the informality of the notes application (being that most people use it for personal capture) makes it a great way to aggregate and consolidate low fidelity information.

Roam Research - Probably the best raw information and development capturing tool right now for individuals due to its hierarchical nature. Templating, workflows, and querying are all very powerful tools. Best for small technical teams due to learning curve and syntax. Recommended to backup databases regularly until its proven. We use Roam for the Capture and Refine components of our stack.

Notion - The only tool on our list today that sufficiently covers all three components of the writing stack for teams. Great templating ability and workflows, lacks in some page linking, querying, and block referencing capabilities.

Miro - What we thought was best for design inspiration and infinite canvases turns out to be a great place to capture and iterate on raw information, ideas, feedback, etc. We're not so sure about its refinement and publishing capabilities though. Probably best for design and visual oriented teams.

JIRA - If you choose to use JIRA or another Project Management tool for the capture component of your writing stack please be cognizant of our note.

Refine

Notion, Roam Research - Especially if you're using them for your capture component.

Google Docs and Office 365 - If powerful formatting and publishing as PDF or printing is important.

Publish

Stack Overflow Teams - if your current information situation suffers from Semi-Ephemeral Chat and constant Q&A discourse.

Basecamp Announcements - if you're doing Shape Up or already using Basecamp as a Project Management tool then Basecamp is actually a great place to post formal writing, increase Organic Engagement and maintain the proper access and fidelity of published information via Company HQ, Teams, and Projects.

Notion - especially if you're capturing and refining here already.

Confluence - especially if you're using other Atlassian products

Avoid

Basecamp Docs & Files and JIRA tickets for publishing - The reason we want to avoid these is because it's difficult to draw clean lines between the tickets which contain published information and which contain captured information. Capturing refined information in JIRA also violates the Functional Access Only principle, since JIRA's primary functionality is project management, its access should be limited to people with project management and execution functions. 

Pen and Paper for Capture - I know, we all love pen and paper. The problem is that physically written information can't be queried, and makes collaboration increasingly difficult in a shifting Remote Work landscape. Instead use tools like Miro to capture

GitHub Wiki for publishing - For a similar potential violation of Functional Access Only principle

Antipatterns

Semi-Ephemeral Chat can diminish the long term value of the capture component of an individual's writing stack.

Tribal Knowledge can mean that implementing a writing stack requires convincing more senior team members to develop and disseminate information that they may not even have written down or that are organized in their own private writing stack. This issue can be especially difficult to solve if those members don't have equity, i.e. do not have an upside in the long term success of the business.

If you found this pattern interesting, explore more on longpressed.com, where it will also stay up to date. If you haven’t already, please don't forget to subscribe!

Subscribe now

The patterns we feature in this newsletter are codified and connected in a pattern graph that you can explore in depth on longpressed.com.

Subscribe below and don’t forget to share!

Subscribe now

-Justin