Skip to content

Blog · Feb 23rd, 2023 · 8 min read

Ronald Aveling avatar Ronald Aveling avatar

Ronald Aveling

Shared understanding: why it’s important and how to fast-track it in your project

Tips and tricks to get your team’s collective intelligence buzzing in product development.

When it comes to building digital products and experiences, the amount of time it takes teams to find shared understanding can have a big impact on delivering outcomes.

This article explores how creating an environment where psychological safety and active learning are supported can help teams accelerate early alignment; leading to better outcomes, happier teams, and improved time-to-market. Included are tips and tricks to help you accelerate alignment within your own unique team and delivery context.

Shared understanding in a nutshell

You may have encountered the term shared understanding by other labels such as “unified mental model”, “hive mind”, or “collective intelligence”. From the perspective of shipping software, we see it as a product team having shared sense of:

  • What’s to be built.
  • How it relates to the business domain and users it’s in service to.
  • How and where the needs and constraints of the business, users, and the underlying tech are in conflict with one another (tradeoffs!).

Here’s a simplistic illustration of a how a team with no shared understandings might start out before a project kickoff:

A representation of the domains of Business, UX, and Tech existing in an isolated and siloed manner.

Here the needs and concerns of practitioners who are in service to Business, UX, and Tech exist apart from one another. This leaves room for gaps (in understanding, and execution) to manifest, which can negatively impact outcomes, team health, and perhaps even exacerbate feelings of isolation that team members might already be feeling.

A representation of team specialisations operating from a position of shared understanding. Business, UX< and Tech circles overlap with one another.

Here’s those same three concerns operating when a critical mass of shared understanding has been reached. There are less gaps, and practitioners in any one of the three domains have greater overlap with the needs and constraints of that which exists outside their zone.

Why finding shared understanding early is important

If you’ve worked on dynamic cross-functional projects you might be thinking that shared understandings evolve throughout the entire project. In our experience, you’re 100% right! Understandings do need updating and re-qualification throughout. However, just because they change doesn’t mean that you can’t be more effective by striving for a “critical mass” of alignment early. Here’s a handful of reasons why:

  • You’re more likely to identify and close the big (and expensive to fix) gaps sooner.
  • Less gaps often increase the possibility of achieving better outcomes, and reducing time-to-market.
  • You’re more likely to develop actionable empathy for the needs and constraints of your cross-functional teammates.
  • Being more tuned-in to your colleagues means you’re less reliant on specification documents as everybody is in sync, and on the same page.
  • You’re more likely to enjoy the making process, which can increase employee retention and build a better organisational culture.

We’ve found that in order to fast-track the path to a unified mental image, a few things need to be in place:

  • Organisational and cultural support for engaging in active learning in the early stages of the project.
  • The ability for teams to self-select tools and processes that are inclusive and match the unique composition of their team.

Impediments to shared understanding, and how to overcome them

Here’s a list of obstacles you may encounter on your quest, and some suggestions for how to sidestep them:

Tricky terms and domain logic

Getting aligned can be tough if you don’t know exactly what it is that you’re talking about! Setting aside access to the right users and stakeholders for a moment – collaboratively building a dictionary of terms and core concepts can go a long way to improving alignment in the first weeks of your project.

A perceived need to demonstrate measurable progress early

Tech teams often experience pressure to appear as if they are being productive in easy-to-measure ways on day one. This pressure often manifests as rushing into code or wireframing. It can be a real dampener for reaching alignment, and often ends up manifesting as increased learning debt across the life of the project, inferior outcomes, and poor team health.

Talk to your teammates and superiors about the value of starting slow to go fast, avoid learning debt by making the practice of active learning visible early, and nudge your collaborators in the direction of making your alignment-generating efforts both valued and measurable. The cost of dealing with last-minute gaps can get a lot more expensive that the effort you put in here!

Existing predispositions towards siloed and linear ways of working

If you’re in a team dynamic where tasks are handed over the fence to you (waterfall model, we’re looking at you), it can be hard to find a holistic sense of what it is y’all are working on. Gaps arise, the blame game sets in, you may have experienced how the rest of that story goes...

Talk to one another, and talk often. Check out our thoughts on the value of working synchronously, and be sure to dive in to Shamsi Brinn’s excellent No-Handoff Manifesto.

A preference for sharing polished work over work-in-progress

You may practice your craft in an environment where formal, polished presentations are highly sought after. These certainly have their place. But if you’re not careful, overemphasising on bulletproof presentations can slow your journey to common ground.

Can you skip the prep time required to make polished thing, and instead opt for sharing your unvarnished work and thoughts in a quick huddle? It might just bring you closer to a solution and build more trust while you’re at it.

Confusing documentation with understanding

Our instinctive reaction to the knowledge gap is to seek more information. We confuse understanding with information.

Steven Bangay, Executing Strategy

Documentation can play an important role in how shared understanding is created within a team. However, there can be be subtle, yet meaningful differences between (a) documentation in service to advancing understandings, and (b) documentation in service to specification. The former can be very helpful for improving alignment (and these kinds of artifacts often lose relevance and value as shared understanding increases, while the latter is often better suited to situations where things are less likely to change.

If you’re reaching for a documentation effort – ask yourself which of the two outcomes you’re in service to. When your cause is in service to advancing understandings – use tools that are accessible to all disciplines in your team to find flow faster.

A lack of psychological safety

Many of us have struggled with imposter syndrome in some way, shape, or form. One could argue that it’s both a symptom of, and contributor to, all the preceding items in this list!

Creating a psychologically safe environment can take time and genuine effort. It’s hard to offer a prescription for achieving this within the bounds of this article; but if you’re able to make progress on some of the other obstacles throughout your next project – re-check your vibes at the end. You may just find that your team feels safer and more excited about what’s next. That’s a good sign that trust and safety are on the improve.

How to gauge the health of your team’s shared understanding

Every project brings its own unique variables to bear on what “enough shared understanding” might look and feel like. While there’s no one-size-fits-all solution to lean on, this doesn’t mean you can’t find your own way to confidence and consensus. Here’s some questions you might like to ask yourselves in order to evaluate the state of your team’s hive mind:

  • As a team:
    • Are we confident that the most opaque parts of this project are sufficiently transparent from the perspective of all participants?
    • Have we generated enough trust and safety to openly explore our thinking and work in the open from here on out?
    • Will the mindshare we have empower us to work in a highly synchronous manner going forward?
    • Are we aware of, and agreed upon, the key tradeoffs that are stake within the stated ambitions of the project?
  • As an individual:
    • Do I know enough about the cross-functional needs and constraints of my colleagues such that my work will help (and not hinder) them in their goals?

If you’re interested to learn more about how we apply these principles at Thinkmill, checkout The Thinkmill Method. If you’re running a project and feel like you’d benefit from seeing this way of working applied in a more hands-on, context specific manner, we can augment your delivery team and help improve your delivery culture while we’re there. Get in touch to learn more.

Credits and recommended reading

The following resources have made a valuable contribution to the way we reason about effective collaboration within cross-functional software environments:

  • Shamsi Brinn’s No-handoff manifesto offers a way out of waterfall inspired our way of working.
  • Dr Cat Hicks’ research into the value active learning and psychological safety in developer teams is excellent reading.
  • John Cutler’s “Go slower to go fast” advocates for spending meaningful time on finding shared understanding in order to mitigate the many pitfalls of misaligned teams. His product-management substack is top-shelf.
  • Strategy boffin Steven Bungay has summarised his key thoughts on executing strategy which overlap with many of the pillars of cross-functional product development.

Tagged in

Ronald Aveling avatar Ronald Aveling avatar

Ronald Aveling

@ronaldaveling (opens in new window)

Ronald is a designer with a soft spot for systems and structured content. Knows the difference between Tofu and Tempeh. Makes a damn good brunch.

A photo of Jed Watson & Boris Bozic together

We’d love to work with you

Have a chat with one of our co-founders, Jed or Boris, about how Thinkmill can support your organisation’s software ambitions.

Contact us