Shared understanding is hard Part 2

Doodling …. DO YOU HEAR ME!!!!Here is a a retro format that I have used over the years…

Today we are going to explore the idea of shared understanding. Please take a couple minutes to brainstorm words that are used with the best intentions by you or your fellow teammates, but that cause confusion, and make it difficult to forge shared understanding.Here are some of the words the a team generated recently:

Better, Architecture, Review, Design, Milestone, Team, Product Vision, Story, Epic, Bug, Engagement, Process, Healthy, Tech Lead, “Own this”, “Write a Story”, Validate, Experiment, Deadline, Spike, Proof of Concept, Ops, “Do Your Best”, Ownership, AccountabilityDo your best? Really? But this output is very normal for the exercise.

OK. Consider that these smart and talented people spend ~40hrs a week together. Not all of that time is spent talking, but a good chunk is spent interacting, Slacking, and socializing. Most of these words are used in regular meetings. How could such relatively pedestrian product development words cause confusion and impact outcomes?

I’ve done this retro exercise many times. And I’m always surprised. What happens after the team brainstorms these words? The first instinct is to write a glossary. We need to work this out! We need a common vocabulary! Let’s chat now! Who owns what words? Write a Confluence page!

But then it dawns on people that some of these concepts are a moving target. It isn’t the words themselves — they all have reasonable Google-able definitions — but rather about the varied (and shifting) context. After the retro, I print the output of the exercise as a reminder that you can’t assume people know what you mean. Shared understanding is HARD. You need to WORK at it. No one is going to read/remember that Confluence page (let alone understand it even if you do write it).

You need repetition, experience, conversation, interaction, reformulation, iteration, STORIES, drawing, coffee, mind maps, wins, trust … and even then it’s frickin’ hard. Here today, gone tomorrow. Entropy FTW.

Step back even further. Consider VPs who meet certain team members for an hour a month. Or those “super important” high-level 1hr meetings where everyone is nodding and saying “great idea” … but then all the attendees march off and inadvertently sabotage each other? Makes complete sense. If the folks spending most of their working life together need to work so hard to wrestle with words…what might that mean for the managers, execs, CEOs, and partners?

It’s not really a deadline. Just a guideline. I really need to see the team step up. Acme is an important customer. We need to help them succeed. Everybody should succeed, especially the team players. Try to write up a quick overview by next week, along with a status check.Consider how much can go wrong there.

My experience is that many organizations routinely push employees to their absolute limit. It becomes a game of three dimensional chess you cannot win. Teams short-change the hard work required to build shared understanding. The organization rewards freneticism, velocity, and “stretch” goals. No one really understands each other. And no one is present enough — amidst the stress and adrenaline — to do the hard work of building shared understanding. Yet we plod on, because we identify with the myth of the multi-tasking, “great communicator” superhero.

Try the retro format and see what you come up with.

I truly believe that some percentage (>60%?) of software development is about leaving humans the room to build shared understanding continuously, work on communication, and make the environment safe to have meaningful conversations. Without making their heads explode. And without fooling yourself there is a silver bullet.