Growing our own food
Marie and I are aspiring gardeners. We love the idea of being able to supply ourselves with food grown from our own gardens. With that in mind, over the winter, we ordered a (set of garden beds from VegoGarden (with profuse apologies to my favourite Notion consulting client Kevin aka “Plant Daddy” from Epic Gardening as they do not ship in Canada đ) and throughout the spring we’ve been developing the beds; layering logs, decomposing waste, compost, and, finally, soil. We’re excited to see what this layering of components yields as we plant this year.
One morning recently when we were having coffee together, Marie asked me “just for fun, how would you number these beds?”. Without much thought, I said (pointing), “1, 2, 3, 4, starting with the bed on the left closest to me”.
Here’s what I “saw”:
Marie thought this was interesting, and explained to me the way she saw it.
Here’s how she “saw” it:
“OUTRAGEOUS!”, he exclaimed! Okay, not really.
While she saw the numbering from a top-down perspective, read similarly to how we read in English from left-to-right, and from top-to-bottom, I saw the beds as if I was an actor on the stage (the stage being our “porch”). I started referring to my preference as the “Stage” method and hers as the “Book” method.
We discussed what we thought were the reasons we wanted to number them that way and quickly realized how such a “simple” system (label four items) became complex because there were multiple viewpoints.
How would we “talk” about our gardening system if, when I said “#2”, Marie had a totally different planter in mind?
This is often how systems play out in real families, companies, and communities. Something seemingly simple like “number these from 1â4” becomes wildly complex due to mixtures of human experience, cultural concerns, and opinion.
I thought it’d be interesting to see how this dynamic might play out in a larger community. And where else do you go when you want someone to refute, argue, or otherwise shout opinions at you?
To Twxtter!
Funny exercise: Assuming I am standing on my porch, how would you number these beds 1-4? @mariepoulin asked me how I would do it and our method differs. Explain your logic. pic.twitter.com/yP4L6oZqw5
— Benjamin Borowskiđšâđ (@typeoneerror) March 31, 2024
As you can see from the embedded tweet, this got a fair number of replies! I expected folks to generally agree or disagree with one of the two of us. What I did not expect were the number of different patterns that emerged.
Here are a selection:
- Multiple different variations on counting clockwise or counter-clockwise, starting at different beds.
- “Hand painted signs with names”.
- “That depends, which way’s North?”
(I kind of love that last one because “It depends” is probably my favorite complete sentence.)
Individualization
One thing I noted were the number of responses which were something along the lines of “this is the way” or even “this is the only way that makes sense”.
The reality of systems is that they are often relative to the observer. Something that seems clear to one person is often convoluted to another. In these cases of conflict, who is “correct” is often the one who holds power in decision-making, who is loudest, or simply the one who persists.
When things aren’t clear, some things we could consider are things like:
- What is the harm in being wrong? And if the decision made is not the one we personally desired, how were we harmed by it?
- What long-term implications might the decision have, and how can these be mitigated or accounted for?
- Who are the authorities over how the decision is made? Do the authorities consult with those with varying views? How willing are these role-holders to change their minds?
- How would we establish methodology for testing our assumptions, e.g., how could we de-risk our naming strategy such that we could see how it works with different strategies over time?
- Are there alternative solutions or compromises that could address the concerns of all parties involved?
- How does the decision align with broader organizational values, goals, and ethical considerations?
- What data or evidence supports or contradicts the proposed decision, and how reliable is this information?Â
- Does Kevin from Epic Gardening have a preferred way?! How much does an expertise bias help or harm us?
- Are there opportunities for feedback and evaluation after the decision is made to assess its effectiveness and adjust course if necessary?
- …we could go all day here. Getting the point?
I think about these kind of things a lot in things like building systems in Notionâwhere the complexity is like 10,000X larger than thinking about how to label some garden beds. Â
A lot of what I build in Notion seems incredibly intuitive (to me), but when presented to the team will be noted as “not working [for me]” at the individual level. The same thing occurs with organizational systems created by Marie; they make complete sense to her, but I’ll sometimes be dumbfounded.
How do you decide when things get complex?
I’ll give you an example in Notion.
One of the most powerful things about the software is that we can make a shared Tasks database where we store everyone’s Tasks. Notion is neat in that each member of our workspace can use Linked Views to see their Tasks in a unique way that is conducive to their working style. This is awesome. But what else might the power of optionality belie?
Optionality is the flexibility or freedom to choose from various courses of action without strict commitments, allowing adaptation to changing circumstances. It’s what makes Notion so powerful.Â
However, in hyper-individualized spaces, the danger of hyper-optionality lies in the lack of shared systems or frameworks for decision-making. Without common guidelines or structures, individuals may become overwhelmed by the abundance of choices, leading to decision paralysis, stress, and missed opportunities. In such environments, the absence of shared systems can hinder collaboration, communication, and effective problem-solving, as each person navigates their choices independently, potentially fragmenting efforts and outcomes.
Often hyper-optionality leads to missing out on the beauty of shared contexts. For example, let’s say Notion allows Marie to create a way of looking at her tasks based on a “Now”, “Next”, and “Later” status.
In order to understand how she views these statuses, we need to understand how Marie thinks. What does Now, Next, and Later mean to Marie?
- Now: today, within the next day.
- Next: within a week or two.
- Later: beyond two weeks, usually 1 month plus.
She also moves to In progress when she’s literally working on it.
So in order to assign tasks to Marie, I might have to have knowledge of her personal “second brain” systems, and the context that her dashboard relies on a Now/Next/Later Status property rather than a canonical Due Date property.
If I (which I do) think about scheduling primarily by specific dates, I might assume that assigning a task with a Due Date will get it onto Marie’s home page. Is that true though when Marie herself determines what content in Notion appears on her dashboards and how?
Who made that decision? When? Who was consulted? Where can I learn about how it works? What if I had other coworkers who were designing their own dashboards? How will we know if they use similar or different systems?
Now we see how optionality and opinion can hinder shared progress. Huh, guess systematic and simple design is not that simple!
How to solve for optionality?
High levels of optionality can start to go beyond complexity and into chaos. Sometimes chaos is grand; here we can test lots of different systems. Observing chaos in practice can lead to innovation. But what if our current desire is closer to “Getting Things Done” post-innovation?
Spending the time to agree on a baseline shared system can be a huge boon here. For example, I like to start by making sure views are designed at the database source level that everyone can find utility in. Architects can then pull through views into their private dashboard and deviate (ahem) moderately to get more customization. Starting with a shared set of views that “guarantee” filters will match through all sub-systems is super important.
For example, we might create a set of 4 simple views in our Tasks database. In order to created a personalized “Todo” system, we might ask our collaborators to leverage the “Todo” view as a linked view in their personal dashboards.Â
(Againâas with Status Optionsâwe might leverage the ability to add Descriptions to Views to document what the intention of these base views are).
Further, an SOP describing how we work, how we assign work, and what their expectations are might help ensure that any derivations they make in their own sub-systems do not mask important expectations in the super-system.
For example, having a look at one of Marie’s early personal dashboards…
Above we can see:
- That Marie can leverage her individualized Now/Next/Later strategy using Groups, and,
- That she’s using the “Todo” view from our source database as a starting point.
This ensures that tasks with dates appear in this view, however, if I don’t assign them as “Now”, she has the potential to miss or ignore them.
So if something must be done literally now, we have to remember to select that as the status along with the date.Â
Not a huge deal if you’re lucky enough to collaborate with someone like Marie. But what if you were working with 100 Marie’s? Could that company have (allow) that level of optionality? Could be dangerous!
In some cases, digital systems aren’t going to cut it. For example, as someone with ADHD, Marie tells me she struggles with time and prioritization. Work generally gets done more through following motivation than by enforcing rules. Some folks love a good deadline, others effectively see time very differently and operate more through intuition than assignment. Knowing your team can help you in not designing digital systems that are don’t serve you.
In some cases, designing reviews into your Notion and setting intentional time to sync with your team live can be a better strategy than trying to enforce rigid technical rules. It doesn’t mean not setting dates/times to your tasks, but it might mean that Marie and I have to review more frequently and I might have to get her attention outside of Notion if a task is critical.Â
One strategy we’ve developed is marking a task as “Blocked”. This means that we cannot proceed without support from the team. Blocked tasks are de-prioritized in a sense (which runs counter to the traditional meaning of Blocked in many productivity systems). We’re going to admit that we don’t have the capacity to do them now and we can do them together the next time we sync. We might even used Blocked to mean something that we want to collaborate on instead of tackle on our own. “Rewriting the copy for our home page” is a great example of a task that might get blocked in our company.
One of the beautiful new features that just shipped in Notion is the ability to send Notifications when a trigger is fired in database automations. Now we can notify any assignees or folks who assigned the task that the task is “Blocked”. This helps someone like me who’s very time-sensitive know this task isn’t going to be worked on even if I asked for it to be done today.
Documenting Optionality
A shared SOP and set of SOPs can also help solidify how work gets assigned and scheduled. This way, deviations must meet a set of criteria to ensure nothing of value is lost.
Make sure you double-check to ensure you’re not losing or missing information because of an errant filter.
An example of this is once I found an filter set on our shared support email inbox that was automatically tagging sent emails in a certain way and removing them from the inbox. The tag strategy made it so that gmail would not display responses in a thread (for some reason I could never figure out). This meant that occasionally someone would respond to an email and then another person would respond again with a different answer. The filter system, while it worked for one person on the team, did not scale to work for everyone.
When we give too much control over sub-systems to the players, we sometimes create the cause for suboptimization. Suboptimization is often an effect of an over-emphasis on customizationsâthere’s our friend hyperoptionality again!
In Donella Meadows seminal work Thinking in Systems, she defines it thusly:
When a subsystemâs goals dominate at the expense of the total systemâs goals, the resulting behavior is called suboptimization.
Yes, we want everyone to be able to do their jobs and in the way that they prefer. But when we suboptimize for total customization, it can be very destructive.
Back to the beds
So what about our beds? What is the actual necessity here for numbering them in a certain way? Why are we so attached to order and having our way when it comes to simple systems?
Let’s consider a handful of the given realities here:
- There’s only four beds (currently).
- We may want to add a few more on either horizontal or vertical.
- We know there will never be 100s of beds due to the size of our yard (not to mention our capacity as gardeners!).
To me, the answer is that all the suggestions are “correct”. We could even rotate through all the suggestions and try different numbering systems. The only core issue here is historical information. With that in mind, I’d give each bed a canonical name that will never change, as well as a Name that could possibly change. This way we can adjust names as needed while retaining our historical insights on what was planted where and when.
Not unlike how pages work in Notion. Each page has a canonical identifer that will never change and a Title that can change and has no limitations on duplicates.
With that in mind, Marie ended up storing the information about the beds in a Gallery view in Notion, which allows us to name them in any way we like because we have the ID property of the page to ensure we have a canonical identifier to look up the information. What we name the page is almost irrelevant because we start with a system for naming that is essentially out of our hands and thus reduces decision fatigue.
You’ll note here that Marie ended up going with a Left(L)/Right(R) naming strategy with the rows counting away from the porch. This is closer to my original strategy, but was actually suggested as the “Gamer” method by my brother (L1/L2 and R1/R2 triggers).Â
I think this is great because we can always add more boxes vertically and increment the row counter without having to re-name or re-number!
What’s the point?
What’s the actual important thing here? Ordering systems or starting planting food and protecting the food from deer?!
I think it’s the later, but I’m always amazed at how easy it is to get into arguments about how systems should work. Systems can be as complicated and/or complex as the humans that are designing and using them.
My general advice is to try not to get lost in the weeds on rightness; focus on what the most important decisions that need to be made to enable you to start testing them.
Notion tips in your inbox