Un-Confusing Meetings

Ever left a meeting feeling like you are standing alone in a fog of confusion?

Lately I have been pondering what can turn around dysfunctional product inception meetings.

Over the last 20 years and in every company I worked for, I have been involved in great meetings that drive excitement and others where you can leave feeling not much was achieved.

As a lifelong learner, I wanted to verbalise what I think works as well as what I aim to do better as a participant and a leader.

One of the things I like about TUI is its digitalisation allows a lot of freedom to experiment. Agile and Dev Ops ideas have gone almost viral in some areas, driving a lot of creative thinking and re-evaluation about ways of working. A lot of testing and learning. In the last few years a lot of traditional processes have changed and with leadership that encourages challenge, there is a chance to overturn things that do not work.

In my view, a few simple changes in meetings can make all the difference. There is no need for total paradigm shift and months of training. But beware.

These changes are easy to talk about, but may be difficult to follow through.

They may require more listening, more humility and more vulnerability.

If you have a strong intuition for solutions you may feel you see ‘it’ and quickly want to get to details without triangulating with colleagues who come from very different backgrounds.

Say an executive calls a meeting to discuss a big, new idea.

And say that exec has already spent a time discussing it with a peer or two.

And say those peers know each other well and have a lot of mutual understanding in the unspoken.

This leads to an inception, where the progenitors of an idea are crystal clear.

Yet, like many busy executives, they may lack the time to nuance the detail in written form. Instead they may call a meeting with some of their direct reports. The objective will be to delegate the task as quickly as possible.

In the mind of the exec, the mental model of the idea is clear. However, over stressed teams, charged with making it reality, may lack the unspoken, unwritten understanding that existed when the exec discussed it with their peers. Everyone needs to be able to stand up and question or constructively challenge.

Confusion

Photo by Hans-Peter Gauster on Unsplash

During an unstructured meeting, people develop partial understanding, probably of all different areas.

Asking ‘stupid’ questions may appear weak or show lack of mastery in a topic. Especially if the idea is from the very top. Without delving into the detailed meaning, everyone could leave the meeting with completely different understandings of the idea and what should happen next.

Even when the meeting feels like a discussion and you collectively fill a white board with bullet points and pictures, have you ever concluded thinking everyone understood each other, then hours or days later realised there was still a lot confusion?

Then you need to have another meeting. And who wants to go back to their boss saying they actually did not ask the questions they should have in that first meeting? With complex topics, this can repeat and waste a lot of time.

Finding Clarity

Photo by David Travis on Unsplash

Language and pictures can be highly clarifying, or sow seeds of confusion.

Being willing to show vulnerability and ask (sometimes repeatedly), “what precisely do you mean by that?”, could make all the difference. Despite all the rich methodologies we have to choose from, in the early stages, getting from idea to the start of implementation can be a meandering process.

Asking this kind of question may break the ice and get a real clarifying discussion going. Often nobody wants to go first, so when you ask a question like this, your colleagues may be really grateful you were the one willing to open the discussion and put yourself out there. There is a whole separate topic of the politics of what people will and won't say. That's for another time.

In any kind of development, ambiguity really eats time.

In software development this has been well known for years. Developers can’t typically tell a computer to:

make_customers_happy(re_invent_experience(…));

If only.

Maybe when machine learning gets really good this might change, but we’re not there yet.

Wrong Direction

Photo by NeONBRAND on Unsplash

The classic IT failing is developers do get a clear message but it is not what the leadership believed would execute their strategy and bring value to their business. There is a damaging grey zone between projects that ‘fail’ because they were far off the vision and those that brought a watered down, distorted vision to life. They go live, they do get used, but they take a long time, cost too much and never really did what was envisioned. So the benefit never really comes.

Paraphrasing; The Mythical Man Month clearly told us that the longer we go without clarity the more it costs. Methodology is not the issue. Using "Agile" to constantly re write because the vision is not remotely detailed or understood is dysfunctional methodology dressed up and justified as Agile. Not to say we should spend months on requirements which can stealthily lead to Waterfall dressed as Agile. And not to say waterfall is always the wrong choice. Methodology depends on situation and any method should be thoughtfully adapted to the situation. Whatever, happens, there needs to be sufficient clarity to get going in the right direction.

There are some wonderful tools to collaborate, capture goals, needs, features etc. Yet the ancient adage of garbage in, garbage out still applies. All the tools in the world will not drive clarity if the people involved are not willing to ask questions of their leadership and of each other.

Even when the harder questions are being asked, if the tools themselves are not used with fluency and commitment, they can create even more confusion. We’ve all seen the kind of chaos that can quickly develop in un-managed wikis. How many times have you had to suspend normal working to spend days or even weeks cleaning up a backlog that is completely out of control? Lack of alignment on clarity leads to duplicated or conflicting features, unclear definitions and disconnection from the essence of the original thinking. Any kind of method needs to keep clarity throughout the project, Agile and Waterfall can equally suffer this way.

Transformers Cost a Lot

Photo by Samule Sun on Unsplash

Projects where the technical team have built in flexibility (maybe because they knew there was not a lot of clarity) may have a chance to still deliver something but it will still take longer and cost more. Where technology teams are in a silo rather than cross functional model, this can be much worse. Tech teams may then seek to buy the biggest most powerful tools possible because they want to be ready for anything. Total cost of ownership becomes way higher than planned. In general, my experience is smaller is faster and almost always cheaper.

Collaboration

Photo by Chris Montgomery on Unsplash

Collaborating with clarity on complex topics is not easy. In a COVID world, collaboration also means having all the right tools and the skills to apply them in a cross functional team. One potentially positive side effect of pervasive remote working is since people are not all in the same room, they may find it easier to raise their virtual hand and ask a question.

The interludes between the meetings are just as important. Where people talk informally and more freely. Learning how to find (and get comfortable with) the virtual equivalent of the casual kitchen/water cooler/coffee discussions is important topic. This needs to be solved so teams can bring new insights into the conversation.

The Big Idea

Photo by Aliane Schwartzhaupt on Unsplash

Ever felt like you’re just meant to listen and not ask questions?

So, back to our virtual kick off meeting. The exec is in full flow. To them, everything is clear. They are probably in a rush. And they are excited. To ask fundamental questions at this point may be intimidating. And can sometimes attract frustration because it may seem to slow down the meeting. Of course, it is important to be polite and find the right moment to ask, but if something seems unclear, do ask.

When an idea is interpreted, it is always in the context of a person’s experience and pre conceptions. Pure IT people will naturally assume one interpretation and pure business may see it a different way. For experienced Product people who have a good balance of business, IT and methodology, they may see more what is there (realistic, not impressionistic), than what they want to see. They may have the best chance of getting or driving clarity and consensus. That skill does not come by magic though, it takes experience, training and mental agility. Get them involved early. Developing critical thinking is important. For me, more listening and asking more questions is a skill I am still working on. I really got inspired by a podcast from The Knowledge Project that talks about listening. The interview with Adam Robinson brought a much wider perspective to interactions which I am still ingesting.

Product discussions inevitably stray into technical how-to but often at an unhelpfully high level. How often have we seen hand waving architecture along the lines of, 

“well-- we just add a block chain, some machine learning and micro services…”

“...how hard can it be?”

This is where it can be important to bring the discussion back to the what before the how. A phrase we developed recently to redirect a conversation is, “I trust you, but…” which is a nice polite way to ask for detail or redirect to a previous topic. E.g., “I trust you know precisely how to engineer this kind of solution, but can we just talk about what precisely we want to do?”

Emperor’s New Clothes

Photo by Paul Carroll on Unsplash

If some start to talk about deep reinforcement learning and get very excited by it, does anyone in the room want to show they might know less (or even nothing) about it? Or, is it just easier to nod along and try to clarify it after? If something doesn’t make sense, but the speaker is really entranced by their idea, it is still good to ask. Speaking personally, it can be difficult to be the one to be saying, “I don’t get it, can you explain?”

If people don’t raise their hand (so to speak, or actually is quite nice) to explain why it is not clear or as easy as it sounds, expectations can be wrong from the very start. In the virtual life we now live, I quite like the simple MS Teams feature of raising a hand.

Leaders may well want to set stretch goals and brush aside objections about lack of clarity or technical feasibility. But there can be a fine line between a stretch goal and the completely impossible. Leaders need to listen. Setting goals right, the team will challenge itself and find a way. Set wrong and the team will know it’s impossible from the get go and will never build up motivation.

Acronym Overload

Photo by Markus Spiske on Unsplash

Ever got lost half way through a new concept discussion and not wanted to ask what on earth an ABC or an XYZ is?

When discussions go overboard with acronyms, for the uninitiated, they may as well be encrypted. How can you not just tune out?

It’s worth remembering every domain has its own language and it is natural for people to find condensed forms of communication.

But when a new product is conceptualised, it may well bring together eclectic ideas from many domains that themselves are complex. When a product kicks off, it could be that most members understand their domain but not the others. Without stepping back and having patience to explain everything, this all leads to clarity death by acronym overload. For example;

Generalist IT people may have a superficial grasp of marketing technology but not understand the detail and therefore not grasp subtle ideas. Classics like COA, COS, CVR, CPM may be familiar but not really digested. So crossover between martech and IT can quickly lead to confusion without care and some willingness to say, “ok I sort of know what that is but please give me the deep dive.”

Converse example; marketing people may well have been exposed to Machine Learning and understand some of the language of Machine Learning, but not appreciate the finer points of implementation. E.g. managing 50 models at the same time. When conversations skew into activation functions, hidden layers, nodes, back propagation, gradient descent, these topics can all be hard to penetrate. And may not be relevant at that point. Sometimes the lesson is knowing when to be quiet. Something I am still working on.

A more subtle but equally challenging example: Agile methodology specialists may not be properly understood by anyone because so many think they know what it is already. How often have you seen the perspective of Agile = JFDI? Unfortunately this is still alive and well in some quarters. How often has Minimum Viable Product become Maximum Viable Product because every stakeholder must have their needs met in the first version?

Some people who made a career in technology may feel their role connotes a generalised expertise in the whole industry. Which of course is next to impossible. But it can still lead to not asking questions.

Sometimes Pictures Help

Photo by Charles Deluvio on Unsplash

And sometimes they don't.

Words are not the only form of communication that present challenges.

Have you ever watched someone throw up a diagram which they think defines everything but you find it hard to understand? You can clearly be witness to a big intellect at work and may feel the problem in understanding is with you. I have found myself getting carried away doing what one colleague politely called “street art” on a wall sized white board. The number of lines and boxes certainly can give a measure of complexity but can also be quite unhelpful. Personal lesson here was scheduling a meeting at the end of the day when you had way to much coffee is not the most respectful way to introduce a colleague to a new topic. If it was street art, I like to think it was more in the style of Mondrian than Banksy but this was actually a great piece of feedback. As I said, lifelong learning.

After you get a ton of information dropped, maybe you then think you will have to study it after because you don’t want to break the presentation flow and query it. Indeed, letting someone talk and draw might be the right thing to do sometimes. Yet it might be best to stop them before they get too deep and might get frustrated if you ask them to go six steps back.

Managing a meeting to drive clarity should not be interrupting every person after every statement to cross analyse it. The process of pulling clarity out a discussion requires method subtlety, endurance and patience.

The potential issue of picture clarity depends on the situation. Some people draw on white boards with a near da Vinci level of precision, while others tend more towards the abstraction of Picasso. The point is, with any subject matter expert, the picture brings complex ideas into view, but some forms may be need experience or help to interpret. Another good piece of feedback I had was simply flat architectures are easier to read than full systems diagrams. Showing off your knowledge of how everything communicates may not actually be helpful. Drawing the lines between the APIs and flow of events may be enough.

A product concept meeting could conclude with pictures, words, exhaustion, relief and not much consensus. Or it can go a very different way.

The Way of Clarity

Photo by Wesley Tingey on Unsplash

Taking time and resource during a meeting to write up on a screen what is meant by terms, define a problem statement, objectives, assumptions, KPIs, clear requirements and solution elements and next steps is basic process. It may mean several sessions but at least moving forward instead of repeating the last one.

In going through this kind of approach, there is a big difference between transcribing the conversation and clarifying all the points, by saying, where needed, “what do we mean by that?” or, “Can we clean up and simplify that diagram?”

If a meeting is run in English but has a lot of non-native speakers, this is also an important consideration. In an international business environment many people are probably at least B2 English but B2 to C2 is a big difference and it may not be easy to tell the difference if you cannot speak the other languages. Sometimes you can think you are getting your point across but be aware, people may be extremely polite and not want to ask you to clarify. Consider getting key people through cultural awareness training. I am always very glad when someone asks me, “can you just repeat that?”

It takes concentration, diligence and rigour to run this kind of meeting in a way that brings understanding and benefit to all.

Drawing pictures in a flexible and quick to manage tool like Miro (or there are many other options) can add a great deal of clarity. Though clear pictorial communication takes practice. And needs people to ask questions to drive clarity in the model.

When applied diligently to a complex topic, in the earliest meetings, pictures can transform those discussions.

The alternative could be a longer term approach to educate sponsors in more specific methodology but sometimes this may not always be practical. In a large company going through digital transformation, process changes can ebb and flow. The everyday of meetings and talking about ideas and solutions continues unabated.

Before ideas get taken into whatever process is being run, it is always helpful to get the concept captured as clearly as possible. Ask questions, drive specificity in meetings and get feedback from all the attendees and maybe a wider group.

For leaders, ensure people feel able to and do ask good questions and raise concerns. Make sure concepts are clearly captured and understood.

For me, one of the biggest lessons and hardest to implement is to not bring the stress of the previous, probably unconnected meeting into the next one. You can seriously slow down the process by coming in excited, but rushed and stressed and end up giving off a clear unspoken message, of, don’t ask too many questions.

The change in meeting approach may frustrate some people as it takes longer. For so many people who are packing in meetings and getting no thinking time, they just want to get in and get out. For the really stretched, it is easy to fall into the trap of feeling their purpose in a meeting is to be give an opinion and not to part of a group, finding its way to understanding and approach for a new idea.

Having the willingness to be a participant (not always the leader), to listen, to be vulnerable, to ask may be to the advantage of all.

It might take longer but sometimes, slower is faster.

(Made a couple of edits after posting to fix typos and added a link to explain a reference.)