If you want to go fast, go alone. If you want to go far, go together.

Teamwork doesn’t have to be difficult. One of the keys to building a strong team is building a shared understanding. If members of a team have similar backgrounds and can communicate well, they’re able to move far and fast as a cohesive team.

At Vaporware, we’ve created a process to expedite our shared understanding through a series of exercises, that ultimately allows us to team up with new clients on transformative software in just one week. While there is a shared experience that only the trenches of the process can provide, I’d like to introduce 3 of our practices to see if they can help your efforts.

Start with Why

To go far, you have to know where you’re going. While you may be filling out the map and directions as you go, it’s difficult to adjust course when true north keeps changing. Pulling from the great Simon Sinek, great teams start with why. While his thought-provoking talk was grounded in marketing, I would argue it’s more vital for team inspiration and camaraderie. If the members of the team are bought-in to the same purpose, then they can trust the other team members to work towards that same purpose.

We define the why of a team through a Vision, Goals, and Success Metrics. We’ve talked about the Vision before, so let’s focus on the Goals and Success Metrics. Also known as Objectives and Key Results, these help quickly communicate the tangible purpose of what the team is trying to achieve. These do not tell the team how to organize themselves or what to do on a daily basis, but how to know they’re successful. These SMART success metrics help individuals re-evaluate and self-direct when there is confusion in prioritization or effort. It helps them avoid rabbit holes and share a common language for where they’re headed. Speaking of language...

Develop a Glossary

Language is key to fast and efficient communication. While jargon is known to create barriers to entry, a glossary provides a bridge across those barriers. We’ve shamelessly stolen this practice from Business Architects who religiously develop what they call "Books of Knowledge". In our world of software products, we simply create a new glossary at the outset of each product, that gives our team a shared lexicon.

By defining our product’s key terms, their synonyms, and relationships we’re able to immediately highlight several key things that trip most teams like if similar terms are causing confusion or if our product is going against industry standards. Ever confused about who your customers are? What user you’re talking about? Having trouble communicating with customers? Is the new guy on the team getting confused a lot? A glossary can help all of these things -- and more. We truly believe that every project, team, or product should have one -- and would propose a GLOSSARY.MD standard for code repositories. But just having a glossary is not enough, it needs to be frequently updated, referenced, and shared. If you’re looking for inspiration on your glossary, check out this great example that GitHub provides its users as part of getting started.

Note that we don’t immediately start with all the right language and have a glossary. We develop it over time through other exercises like...

Tell the Story

Stories give our processes life. Using actors, we can easily understand complex topics and their experiences through context instead of single words on a flow chart. A story brings humanity, empathy, and understanding of perspectives we may never personally experience. But while a novel may take a long time to read, there are shorter ways of understanding a story.

User Story Mapping is a modeling process that helps us quickly place customers and users’ experience with the ideal output of our team front and center. Starting with a breadth of key activities (or journeys), we outline the high-level users and key interactions. By breaking each activity into sequential steps, we can then understand the entire process at a glance, without discussing every minute detail.

We can then use that same User Story Map to define all of the details (individual stories) within the steps of the process. With every detail laid out, we can start slicing by aligning stories to the Goals in our shared understanding, which allows us to prioritize collectively through “slicing” horizontal lines throughout the entire process, instead of developing large depth in specific steps or journeys.

Curious about how these artifacts look like in practice? Here’s an example Product Blueprint, the initial artifact we start every project with to quickly build our shared understanding.

What other tools or exercises does your team use to get on the same page?

Go fast and far,