There’s one totally non-technical skill that is indispensable in the life of any IT organization, at all levels. It is a great personal asset, likewise. A keen observer can use it as an accurate indicator of an individual’s professional intelligence. This skill is called the art of asking good questions.
We ask questions any time when we’re involved in an activity that requires input and knowledge of many people, at all kinds of meetings. Stakeholders, product owners, UX designers, developers, QA engineers, marketeers — all of them have to master this skill to be able to make their best contribution to the success of the whole company. I’m talking about a company that welcomes input from all team members. Unfortunately, more often than not, little attention is paid to the quality of the questions that people ask during discussions. As a consequence of such loose attitude, hundreds of hours are wasted as the group’s focus shifts to irrelevant things.
Usually, it can be felt on some gut level, if a question is spot-on, or if it’s pointless. Someone might ask a question with a conscious (or unconscious) intention to show off to the others how smart they are, and their question wouldn’t help at all to get to the core of the problem at hand. Or, one can see that this person lacks experience, required to solve this problem, as their questions might seem naive to someone who is competent in the subject discussed. It might make sense, then, to let this person gain more experience, prior to taking part in the group’s discussion. Or, it could be that someone with a different outlook asks a question, that looks clueless to the group involved in a discussion, but this question would somehow invoke a fresh perspective, helping this group come up with a solution eventually.
One can compose many volumes trying to cover all possible kinds of questions, and mapping them with professional skills, personal qualities and organizational contexts. I will only single out these two fundamental faults:
- Asking “how to” questions prior to “what for” questions. This is the surest indicator of a wrong focus. Here’s an example of such a question: “How to adopt… [agile, Kanban, Lean, XP, Scrum, ..] in our organization?” If a stakeholder asks this question and has a vague idea of the “what for” part, the “how to” question shifts focus further away from the heart of the matter. Or, “how to estimate in story points?” Again, what for? Actually, if someone in a team, or the whole team, is asking such a question, this is a sign that they haven’t done their homework with the “what for?” part. If a team feels the genuine need to estimate in story points, the “what for” has already been processed, producing an array of possible answers to the “how to” part. These answers would stem from the unique experience and production dynamics of this particular team; and there’s no one finite answer, as each of the possible options would have to be tested “live” to see if they work.
- Asking “what if” questions that involve some unrealistic or irrelevant scenarios. For example: “What if we fail to adopt Kanban this year”? This question has the double dose of “wrong” in it, because instead of an answer it generates 3 more questions: Who says we need to adopt Kanban? Why this year? What is our definition of “fail”? Such a question is the biggest time waster. Hypothetical questions might only have some value, a rather questionable one, in talk shows or in celebrity interviews. If a question asked at a group meeting or discussion triggers a chain of even more questions, that make no sense in the context of the current discussion, this question can be considered a waste.
The same logic can be used to hone this very art of asking questions. If someone understands the “what for” (I need to be able to ask good questions, what for?), the “how to ask good questions” part will naturally take care of itself. With time. It only takes learning by experience.
Meetings, meetings, meetings… Are you one of those who speak of meetings as of some uncontrollable natural disaster? Such as a snow storm, or a heat wave, or a flash flood or any other act of nature beyond human control? At times I get an impression that meetings come off exactly that way, and humans believe that it’s not in their power to get rid of meetings.
Well, meetings hardly deserve to be treated like acts of nature. Sometimes people complain that natural disasters ruin their plans, but there’s a secret pleasure in being able to use cold weather as an excuse to not commute on that day. For kids, bitter cold means no school, and they can enjoy their stay-at-home time. Some adults are happy about an excuse that gives them a chance to emulate busy activity without producing real results. Others, who have things to do, refer to meetings in the same tone as they would speak of weather mishaps, but something in the way they speak suggests that too many meetings are a real hindrance in their work.
Either way, I wonder why people meekly subdue to the rule of His Majesty Meeting and forget that meetings are not a given. There’s no such default option as meeting. There’s no way to show a meeting to a customer. There’s no way to incorporate a meeting to user interface.
A meeting is nothing more than one of the practices for:
What makes a meeting dysfunctional? Trying to fit both a) and b) into one meeting, and using meetings for anything other than a) or b). It’s that simple, albeit not compliant with how meetings are understood generally.
Async Knowledge Sharing = A Functional Decision-Making Meeting
Case: It’s a company board meeting. Stakeholders check quarterly reports. There are many numbers, someone has analyzed the stats before the meeting, someone sees those numbers for the first time. This is a typical knowledge-sharing meeting. What will happen, most likely, if this group is supposed to come up with strategic decisions right at this very meeting? As per the laws of cognition, the quality-thinking time interval takes about 45 min – 1 hr. With some crucial new information people need extra time to digest it, sleep on it, think about it, and then get together again for yet another meeting, only for decision-making. No, a 5-minute break will not do it. What’s really needed is to take some time away from everyone’s company to contemplate and to think. Regretfully, we don’t give much credit to the way our minds function. People sit in for hours in the same room, lose their cognitive sharp edge, and take tired decisions falling prey to groupthink.
Comment: Clearly, if stakeholders in this board studied the numbers and reports in private, in their best productive time, they would be able to come together for a compact and effective decision-making meeting. Unfortunately, people mostly forget how vital it is to make the bulk of knowledge-sharing async. At the end of the day, it all depends on the stakeholders’ being busy with the real to do’s. Young start-ups don’t have the luxury to afford such a huge time-waste as fuzzy meetings. There are too few hands to do the real work, so there’s a genuine desire to make meetings as compact as possible. Besides, it’s easy to share knowledge and stay in the loop if it’s a <10 people start-up. However, as the company gets bigger, this urgent need to be frugal with the corporate time might be forgotten and replaced with the game called “meetings, meetings, meetings..”.
Meetings Only For Knowledge-Sharing? Hmm…
I can’t say that meetings that have the sole purpose of knowledge-sharing are completely dysfunctional. A touch of personal interaction and informal discussion will never do much harm. However, if meetings are used as a primary knowledge-sharing practice, this is a suspicious trend. It shows the lack of this async infrastructure of keeping people informed of whatever they need to be informed about. In the worst case, this might lead to burn-outs because the time carelessly thrown into meetings is ripped off from the things that really need to get done (I mean, for those who do have such things). Emails have to be answered, code has to be written, logos and other graphics need to be designed. Another popular headline for knowledge-sharing meetings is “come up with new ideas”. The catch here is to watch out for how many ideas can a company process into execution. It’s the most frustrating thing in the world to come up with many ideas only to see them wane unfulfilled. Not only would that be a waste of everyone’s time, but the practice of shopping for ideas and then freezing them for an unknown period of time is so very treacherous and morale-killing.
The Ugliest Form of Dysfunctional Meetings
… is when someone snaps with power games and personal clashes. This is the case when a meeting is not anymore about knowledge-sharing or decision-making. First off, it means that the meeting participants prefer to get away with passive-aggressive behaviors, instead of sharing their concerns with a good composure. Meeting is the composite of the time of many people. If two participants pick up a verbal fight and throw tantrums ignoring the rest of the audience — this is an extreme example — the meeting becomes dysfunctional and fails to fulfill its main purpose. On the other hand, the unattended personal needs of those fighters are revealed that way. But who says that this most precious commodity called “the productive uninterrupted time” of others has to be wasted like that?
Skype Is (not) The Limit..?
Meetings: The PGP Conjunction
Soap, Laundry and Company Boards
There are quite many posts on visualization in our Edge of Chaos blog. While we haven’t emphasized the difference between visualizing data and visualizing information, mostly, there is still one between those two. Without delving into any greater depths of theory, one can assume that data visualization is more closely related to quantitative data. This means that figures rendered into a visually clear form make sense faster as compared to when one looks at figures only. Today I’d like to give a few examples of using visuals (namely, mind maps) as an aide in the cognitive processes of research and problem-solving; I will also share some thoughts on when mind maps work at their best to amplify cognition.
Mind maps are often used to put together concepts related to a certain problem. These visuals help to get to the core of a problem or a phenomenon that we explore. When we link concepts in a network, things seem to make more sense to us, and the process of binding those nodes somehow helps to bind pieces together in our heads. The following mind map represents a case of digging to root causes of a problem (problem-solving):
Another case of using a mind map visual is to make a summary of some information that one has already digested. A mind map conceptualizes this knowledge putting it into various perspectives. As learners and researchers, we often feel the need to re-arrange some previously acquired ideas based on our own thinking, to shuffle and to categorize them in some new ways. This mind map was used to write the Patterns for Information Visualization article:
The next example looks as a mind map on the surface, but in essence it’s not exactly that. Technically it is a mind map, as it consists of some nodes linked together. Such a visual, however, would seem more appropriate if drawn at a group meeting with people discussing the dynamics of their team work. We can say that this visual facilitates a group discussion:
Here’s another example of a mind map that could have been used as a graphic facilitation when discussing Scrum process:
It depends a lot on the personal preferences and the context whether a mind map would help to amplify cognition. For example, the team reflection and the Scrum process visuals might work better at a group discussion or in a conversation. It’s cool when a person that runs a meeting draws such images in the process of speaking, as the others look at the funny images, share a laugh and put their cognitive abilities to a better use through this distraction. As a solo researcher, one might draw such images automatically, focusing on the problem and thinking deeper.
Summing up, mind maps work well for an advanced solo research and problem-solving as people make graphic sketches in the process of thinking. They also work well for group meetings to facilitate discussions related to some common context, in a shared space. However, mind maps do NOT work well when someone totally new to a subject area hopes to learn all and everything from a mind map sketched by someone else. Depending on how new the student is to this subject, the mind map might make no sense to them at all, or it will just give them a general idea, at best.
It wouldn’t be an exaggeration to say that posts on daily stand-up meetings take a top standing (*pun intended*) among the blogs related to Scrum. Looks like I’m ready to put my two cents in as well.
When researching on some practice, I first look if there are any meaningful clues in its name. According to the classical definition, daily stand-up meetings are held with people in upright standing position for the reason that looks quite ridiculous: discomfort of standing for too long is supposed to keep the meetings short. Hmm… If there’s no other motive to keep the meetings short, rather than the urge to get seated faster, something must be missing in the whole concept of daily stand-ups. It means they can get so boring, that people would lose focus even in less than 5-10 minutes. Most likely, they would have trouble focusing on what the others are saying, because it’s in no way related to their current work (or related remotely). As a consequence of this boredom, the team skip preparation for the stand-ups since they know that it’s a formal thing, and sometimes all they have to share with the others is: “I was digging into some bugs, looking how to fix them, will go on with that today as well”. No commitments are made, and the same status updates are delivered for several days in a row.
All of the above are surefire signs that your daily stand-up meetings need a serious health check. If people go with the formal “what” (I’m doing), “how” (I’m progressing with my task), and “when” (will I complete the task), and this seems to be of no interest to everyone present at the stand-up, then it’s time to question the “who” (is attending), and “why” (the reasons for attending).
It might be that the crowd of folks at a stand-up gets too large, and as they still think of themselves as one development unit (and they are, on a higher level), their daily tasks have become more autonomous, and progress reports they share don’t seem relevant as daily updates anymore. Could be they’re each doing smaller features, or sub-projects; or it could be that your large team has inconspicuously turned into several smaller teams. Now, will the guys in those mini-teams be genuinely interested in sharing and listening to tiny details about the work that isn’t in their current focus? Daily? For sure, not. But they would want more meaningful high-level progress updates from the other mini-teams, as they are still interested in the bigger picture. It would never do harm for everyone else in a larger team to know what’s going on if those mini-teams report on their overall progress as one unit, not as standalone developers.
So, a daily stand-up meeting can morph into various shapes, depending on how your team morphs into various work landscapes. Boredom and lack of focus are sure signs that “who” and “why” need to be questioned. Naive hacks such as keeping meetings short by standing-up, or other trickster stuff like that will not get to the root of the issue. All the problems with daily stand-up meetings eventually boil down to sharing the irrelevant information. If you sense any single hint of boredom in the air, it’s time to do a health check. No need to make it time-specific: what good it is if you decide to re-frame stand-ups once a month, or once in 2 weeks, but something in the work changes, and adjustments have to be made right away?
Your daily stand-up may turn into a status meeting, nothing wrong with that. It’s just another example that the goal is not to follow some practice by the book (a daily stand-up is a recommended practice for Scrum), but tune it to the way you work, not the other way around. That’s what they call Agile, and that’s what the “work-get feedback-iterate-get feedback-iterate” loop is about. In this case, the feedback cycle would run in the context of daily stand-up practice.
Earlier this year I published several posts on meetings, uncovering some reasons why they can be a waste of time, or why they can be productive. This subject has many more perspectives than seen on the surface, and today I’d like to highlight one basic idea.
Any meeting includes the following 3 components, and its success would depend on how well those components fit together:
Problem — issues to be addressed;
Goal — the desired outcome;
People — they need to have a shared understanding of problems and goals.
The quirky green-red thing in the middle is supposed to visualize the volatility of the conjunction.The notorious feel of wasted time at meetings is usually related to the bad cohesion of those 3 components.
The so-called technical meetings is where the components fit best. Such meetings can happen on the fly as 2-3 experts discuss a clearly outlined technical problem, looking for a clearly outlined goal. This is straightforward, the technical problems are obvious, they are discussed openly, and with focus. The “instant” meetings always have the right people due to the very nature of the subject matter. This is a perfect setup, as all the three components share an overlap.
Misfits begin when at least one of the components breaks loose from the nucleus. This usually happens at decision-making meetings (non-technical). If not all people have a good understanding of the subject matter, however valuable their input might be, it would take extra time to bring them on the same page with the others. In this case, it would be reasonable to narrow down the selection of the participants OR take some time before the meeting to educate them. We all must have been at meetings where 3+ people are waiting until someone is catching up with what all the rest understand. The 3+ people are getting impatient and irritated while this education process takes place. It’s not bad to explain things to people though. But this has to be done elsewhere, at some other “educational” meeting, not at the decision-making one.
Next, the integrity of meetings is ruined by blurred goals. For non-technical meetings, the goal should clearly be identified as one of the following: is this meeting supposed to uncover any missing facts to back up the decision, or is it purely a decision-making meeting? Some strategic decisions might require a series of prep meetings, until it gets down to taking a group decision.
The key to successful decision-making meetings would be this: try to make them technical. Cut them down into pieces, and bring together as few people as possible to resolve a clearly outlined problem, with a clear goal in mind. It’s more effective and reasonable to break the subject matter into smaller problems, address them in turn, and take to the next decision-making level, and to the next meeting. The PGP abbreviation in the name of the post implies this approach with the play on words: PGP=Pretty Good Privacy.
Soap, Laundry and Company Boards
Skype Is (not) The Limit..?
Dissecting Dysfunctional Meetings
I’d like to write more about meetings today. It’s not a series of posts (officially), but looks like it’s evolving as one, since I’m picking up on my earlier posts on how to reduce the toxicity of meetings and how Skype works as on organic supplement for knowledge sharing in our company.
On top of the usual UX meetings and dev kick-start meetings, we’ve introduced a new kind of meetings recently. The company board meetings. We’re just in this phase of growth when it’s about time to try boards for decision making. At the moment, we’ve got the Product/UX Board, the Development Board and Marketing Board. The founders/stakeholders board (the Head Board) has been in action for several years by now; this board is responsible for taking decisions about the company policy, some strategic visions, etc. It’s those 3 new boards we’ve started just now. The boards, usually 5-7 people, work by a simple 5-2 vote (or a 4-1). The board members are of a mixed background: marketers and developers are sitting in the Product/UX board along with the UX people and feature owners (check who the feature owners are); developers and designers mingle with marketers in the Marketing Board. The good sign that confirms the integrity and the common shared vision of our team is that it rarely gets down to any other than 5-2 split-up of the votes. If it’s 4-3 or 3-4, this usually means that the subject requires more discussion, as some essential details might have been left out.
We’ve started the boards for several reasons. One of them is to be able to come up with unbiased visions. As a marketer, you tend to focus on the marketing things alone, so if developers infuse some of their blood into the veins of marketers, or if the UX people get involved in the decisions related to marketing — it’s good. From my experience, a more common case is when things are seen rather from the dev perspective, and developers need to be educated in marketing.
I’ve been at some of those board meetings but for the moment I prefer to keep a certain stance of cross-boardability. I try to make my point to people who sit in the board meetings, but I stay away from being too deeply immersed in the activities of any particular board. Why so? I have noticed one interesting trend. The boards start wearing out once they get into action (check the header image). It’s about the same, the more you rub the board washing your laundry, the more soap foam is generated, blurring the clarity of your vision. Well, this does not necessarily mean that the laundry will come out dirty, rather the other way round. But the laundry lady needs to clean the board from the used-up soap foam to be able to see if the laundry is clean. Not sure if someone actually does laundry this way — we’ve got washing machines after all — but, well, there’s no machine for the board’s decision-making, that’s why I’ve applied the soap-and-washboard metaphor here.
The intent behind creating our boards has been exactly that: to keep the vision fresh and clear, and consider things from all possible perspectives. Looks like some rotation is needed to maintain the freshness, and might be it has to be done more frequently than we supposed at first. Or, a fresh quick look from someone who is not a board member, but a keen observer could be helpful. If you’re not rinsing off the old soap foam, your vision will lack clarity and perspective, not to mention the notorious brain drain which would then creep in and poison your board meeting . Perhaps, we need to come out with more sophisticated rotation patterns. Or, perhaps at some point, we might need to merge the UX/Product Board and the Dev Board into one Production Board. Or, make it Marketing Board + Product Board and UX Board+Dev Board. We keep looking and trying.
P.S. Happy 8th of March, ladies :)
Competent Decision-Making and Rusty Tinman
Dissecting Dysfunctional Meetings
Meetings: The PGP Conjunction
In one of my previous posts, I contemplated why meetings are exhausting, and uncovered a possible reason for that: people get tired naturally when they try to share too much within too short a time frame. It appears that asynchronous communication in between meetings helps to minimize this drain, so I’ll tell more on how we do it in our company.
In general, this is searching for the most comfortable process of knowledge sharing, which wouldn’t interrupt the personal productive flow of people and at the same time keep them informed just enough of what the others are sharing, in the context of each other’s responsibilities. One of the traditional ways of asynchronous communication are all kinds of comment threads – just like in this blog, if you scroll down a bit. We have the threads of comments built-in into TargetProcess, and they work mostly as status or diagnostic messages, like “changed the code”, “need the design”, “rolled out to production”. For meetings and creative exchanges, something in the middle is needed. Not as slow as email, even not as slow as comments, but something that allows a delayed reaction and powers the dynamic exchange of ideas at the same time. Note, that I’m speaking only about the communication within a team of like-minded people here. Google Groups, Wikis – can you believe it, we even tried CampFire. Michael was tempted by its design, and decided it’s worth a try. It didn’t last long however. Just wasn’t as convenient as .. yes, you guessed it right, the good old Skype.
Whatever we tried, we ended up going back to Skype. Turns out it works best for our purposes, and in our environment. Of course, we’re not using it as an “instant” information machine-gun; people are not required to answer right away. We’ve set up a number of Skype chats. For example, there’s a “TargetProcess Design Folks” chat. The design people use this chat to build the collective taste in UX, they share links, discuss drafts and help each other come up with the UI concepts. I’m pretty sure, not any number of the formal UX meetings will cover the wealth of ideas and references that this Skype roll contains. So, for this creative exchange a Skype chat is a perfect tool. The only concern might be that every task has its due time: time to exchange ideas in the chat, and time to go deep into yourself to come up with your own thing. Fortunately, one can turn off instant notifications for Skype chats, or have the notifications sent out only if a certain word(s) is mentioned.
Among the other Skype chats, there’s one called “Product”. Anything related to TargetProcess as a product can be discussed here. Feedbacks, ideas, improvement suggestions, some of those suggestions can then be added to the backlog and implemented in TargetProcess. Our support and infrastructure team have their chat as well. Unlike the chats about UX or the Product, or the chats for various boards, this one quite often requires an instant reaction.
Skype chats are a good multi-purpose tool indeed. They provide instant notifications to support and infrastructure teams, and at the same time, they work as an optimal async communication tool, when it goes about ideas/knowledge exchange to back up the team thinking. The consistency of this async exchange keeps everyone on the same page when at a meeting, and people are less tired. There’s no way one can stay completely fresh after a meeting, sorry, I wouldn’t commit to a “how-to” here :)
The more I think of it, the more it looks like Skype has the features that an agile team needs to generate ideas from the common pool, to react quickly, and to get into action. It might be that Skype won’t appear that universal for a company less agile than ours. I’m just telling about our experience.
Over the last several months I’ve published 2 parts of the series on agile retrospectives, and the 3d part is supposed to come up as it gets closer to spring. By the way, the Groundhog Day will be this Saturday, so I’m eager to find out what the groundhog predicts :)
This whole work, research and observations led me to musing about meetings in general. Most probably you’re familiar with the “Meetings are Toxic” maxim from the “Getting Real” book by 37 signals. I tend to agree with it. In short, meetings are huge energy drainers and productivity flow breakers, so the deal is to figure out if this energy drain is actually worth it. However, there’s at least one great thing I’m very happy about when it goes about our meetings: there’s no space left for elephants in the room! Unlike in the picture below. :)
I’ve been a part of some meetings in our company, and I’ve talked to people asking if meetings are productive? What are the other ways to reach the desired outcome? As always, there’re pros and cons. If we try to follow 37 signals and their maxim, we will most likely miss something vital at the end of the day. People get together and talk at meetings. Getting together and talking is good, that’s for sure, but is it paying off the value? The answer would be “yes”, despite the subject drift-offs, someone holding the attention of the group for more than it’s appropriate, being poorly prepared due to the overload with other tasks and commitments, etc.
One note though: this “yes” holds true for our company, and it depends. Besides, there’re various kinds of meetings. Developers get together to discuss, sketch and define the way to do some functional feature. These meetings occur all the time, and they don’t seem to interrupt the productivity. They really do matter. What I’m getting at are product management meetings, UX meetings and other larger company meetings.
It appears that the core of the “it depends” is hiding in the ability to create an asynchronous loop of valuable inputs into the product vision and UX concepts. What if we all were able to see as one without the drain of a meeting? To give it a personal perspective, through all the years of working with clients I’ve felt a disconnect, a slight or at times a larger one, between what production does, and what leads and customers want and feel. We’re doing better now, which is great, and people who interface with leads and customers are able to make a meaningful input at the product board meetings. In our company, the product board is a 7-member decision-making unit, which includes developers, UX-ers and people who interface with leads and customers. The only nasty problem that persists is that meetings are a work in itself. If only someone’s job would be solely to attend meetings. There’re other tangible tasks to do. Designers need to actually create sketches and prototypes, developers need to build the architecture and write the code, and marketing/support people need probably even more energy as they are always in the trenches, talking to leads and customers. Oh. And product managers and feature owners are responsible for smart product decisions.
Unfortunately, smart product decisions are not 100% guaranteed by those meetings only. We’re sticking to the board meetings approach so far, and it’s definitely a step ahead in our evolution. Seven minds are always better than one mind. But is there a comfortable, slow-paced way for those 7 minds to unite in one vision? If seven people are trying to share their product perspectives over a short time frame, as in a meeting, that’s where the ultimate, never-mentioned source of this exhausting drain sits. It’s simply about the way we are wired. You just can’t pour your vision from your brain to someone else’s brain in one quick shot. It’s not like with whisky. It’s exactly for that reason that we inevitably face the need for building the gradual, asynchronous awareness of the product as a whole. This is related to Michael’s recent Specialize or Generalize post, and it goes beyond the boundaries of software development as such.
Back to 37 signals. Their “Meetings are Toxic” judgement is sharp, clear and perfectly correct in the context of their evolution. We’re doing things our way, as we try to back up meetings with various asynchronous ways of building and sharing a versatile product vision e.g. Google Groups, internal blogs, wikis, talks in the office kitchen, etc. Asynchronous exchanges are compulsory homework before the meetings; they work great for any knowledge work, for many reasons, and it would take a yet another blog post to tell more about that. For now, I will just reference this great article on asynchronous communication.