(F)acts, (A)ssumptions, (B)eliefs

Here’s an activity ANY team can do to stay more aligned.

It is fabulous. It is simple. But consider how often you and your team are misaligned on the foundational things underpinning your work.

FAB – Facts, Assumptions, Beliefs

1. Start a document

2. List incontrovertible FACTS relevant to your work.

For example:

  • Net Revenue Retention for [Profile] is currently ###%
  • [Competitor] recently launched [Product]
  • There’s a relationship between the housing market and interest rates

Provide links to the data/insights that support these facts.

3. List ASSUMPTIONS relevant to your work, along with something to indicate the current level of certainty. Indicate the relationship between the assumption and your current work.

For example:

We are operating on the assumption that [Profile] will not adopt the new product extensions in 2023 but will gradually adopt them in 2024.

  • Implications: decreased investment in 2023 with a ramp into 2024.
  • Confidence: medium-high (though falling)
  • Type: Operating (revisit on #/##/####)

We assume that a lack of expertise in [Segment] will hamper the shift to [New Technology]. 

  • Implications: New product initiatives centered around the expertise gap in [Segment]
  • Confidence: low (but increasing, with active research)
  • Type: Testing (report research on #/##/####)

Provide links to the data/insights that support these assumptions.

Note the difference between operating assumptions—things we are currently operating based on and will revisit—and assumptions we are testing.

4. List your BELIEFS. 

“Wait, aren’t those assumptions?” Yes, and no. Beliefs are foundational assumptions. They may span years or decades. By calling them beliefs, we are also acknowledging contrarian and untestable assumptions.

e.g.

  • We believe in a sea-change shift to [some practice]
  • We believe [technology] will eventually become a commodity

5. After establishing this document, establish a ritual of regularly revisiting FAB. 

  1. Keep a history of the doc
  2. Review and update regularly
  3. Encourage your team to make notes in the document and batch up the feedback for the next meeting.

Bonus 1: FAB is fractal. There are company-wide FABs and team-level FABs. In an ideal world, you make all of these public and accessible.

Bonus 2: Note how some things remain stable (hopefully), while other things change all the time (not necessarily a bad thing). If EVERYTHING changes all the time, you should explore that. Why?

From https://cutlefish.substack.com/p/tbm-4652-facts-assumptions-beliefs

Think Big, Work Small

How does your team work?

Some companies only work big. Large, prescriptive projects with no incremental value delivery, no experimentation, and infrequent integration. Efforts advance at a glacial pace. Scope expands to fill the available time, and then some. And the work “on the roadmap”? That work gets bigger and bigger as well through a cycle of disappointment, fear, and planning overcompensation. 

Some companies only work small. They sprint in circles. The work lacks coherence and feels scattershot. There’s a perception of progress, but looking back the team sees a lot of disjointed, reactive work. The resulting experience is incomplete and imbalanced. But management applauds the team(s) for being responsive, and the cycle continues. Plus… more features to sell! 

Some companies define big, and work small. Large, prescriptive projects get broken into many small pieces. Think of this as a combination of #1 and #2. The team works small and integrates frequently, which reduces risk and accentuates progress. But there is little room to respond to learning and feedback. Design work is more set-in-stone, and less strategic. Like a big lego set, it is placing tiny pieces according to the plan. What if the finished lego set is the wrong lego set? What if 20% of the work represented 80% of the value? Then again, the team is applauded for finishing “big things”.

Finally, we have thinking big, and working small. The team rallies behind a compelling mission linked to a coherent strategy. The mission is outcome/impact oriented. The team contemplates a vision for the holistic experience but works with broad strokes. They sequence work with the riskiest assumptions first — experimenting, testing, and learning. This is not a ship-and-forget or a ship-and-maybe-in-a-year-we-come-back operation.

For items 1-3, note how incentives can hold these ways of working in place. Big prescriptive projects look bold and compelling. High velocity is intoxicating. Rapid progress on big prescriptive projects …exciting!

Thinking big, and working small is more nuanced. There’s more acceptance of uncertainty. There’s less set in stone. There’s an art to framing a mission to leave space for creativity, while also capturing the opportunity. 

Start by figuring out where your company tends to work right now. If you only work big, then start working small. If you are only working small, maybe start by defining the bigger thing. If you’re working small and defining big things prescriptively, then start easing off that level of prescriptiveness focus on missions and strategies.

From The Beautiful Mess – Think Big, Work Small

Charlie Kindel 5 P’s

Charlie Kindel – how to achieve focus in any endeavor you embark on by simply writing down the PurposePrinciplesPrioritiesPeople, and Plan (the 5Ps). An endeavor could be a software development project, a job search, or a phase in your life. I have personally found the 5Ps a useful tool for small projects (e.g. prepping for a VC demo/presentation) as well as large scale projects that include 1,000s of people.

  • Purpose: Why do we exist? Why are we in business? Where do we want to be in the future? What will we deliver?
  • Principles: What are the non-negotiable rules and key strategies? How will we act?
  • Priorities: What’s the framework for tradeoffs? In what order do you do things? How much mass or energy do you apply to each element of the plan? What is not important?
  • Plan: How are we going to stage and tackle solving the problems? What are the known dates & forcing functions on the calendar?
  • People: Who’s accountable for every key part of the plan?

From https://ceklog.kindel.com/2011/06/14/the-5-ps-achieving-focus-in-any-endeavor/

Conway’s Law

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Melvin Conway

Conway’s law was not intended as a joke or a Zen koan, but as a valid sociological observation. It is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.

Easily observed in organisations today Conway’s law still has merit and should be considered when designing software or reviewing organisational design.

From http://www.melconway.com/Home/Conways_Law.html

Also, from https://www.linkedin.com/posts/jonny-williams-83433836_do-you-care-about-conways-law-if-youre-activity-7009445165320790016-ZYTW/

So what might caring about Conway’s Law help you to do as a team enabler?

👉 Understand misalignment between the organisation’s communication structure and the systems and products they are creating.
👉 Recognise potential organisational impediments that might limit effective collaboration and communication.
👉 Offer practices, tools, and techniques that can help teams to navigate the limitations of the structure around them.
👉 Avoid common pitfalls and challenges that arise when working on complex systems.
👉 Help senior colleagues to understand that they play a role in shaping systems and products through their influence over communication structures.

Why Corporate Apps Fail

Have you ever found yourself saying things like:

  • Why are enterprises so slow?
  • How do they decide what to buy?
  • Why is it so hard to deliver things in an enterprise?

I worked for a large ‘enterprise’ organisation for a few years trying to deliver infrastructure software change, and found myself having to explain these things to developers who worked there, salespeople, external open source engineers, software engineers who worked for enterprise vendors, and even many, many people within that organisation.

A few of those people suggested I write these explanations up so that they could pass it on to their fellow salespeople/engineers etc..

The polygon of Enterprise despair

From https://zwischenzugs.com/2018/10/02/why-are-enterprises-so-slow/