If someone asked you to name the most important single process in a large organization, especially an organization deeply dependent on software, what would you say? Budgeting and forecasting? Sales? Product planning? Hiring and people management
All of these are important, of course. But I would contend that the most important single process, critical to all these areas, is the much-reviled, hated, boring, confusing, and absolutely critical-to-everything  meeting .
Large-scale technology development demands a new kind of leadership, which I’ve dubbed “leadership for agility.” It requires:

Rigor — large numbers of people making good decisions
Alignment  – input from all who have something to add and broad agreement on chosen paths
Efficiency  — it’s done with respect for the time of all participants


Having extraordinarily prepared and executed meetings is a powerful leverage point. When done well, the purpose of the meeting is clear to participants going in. The ground is well prepared, and the background and context is widely shared. In the meeting, participants themselves do the work of developing and considering options in a rigorous way. At its best, this kind of meeting can result in a broad alignment around a common plan, enabling dispersed decision making to move the team forward in relative harmony.
Poor meetings, on the other hand, are annoying and wasteful. The most effective way to avoid them is to just not meet. Since we don’t want to throw out the baby (great meetings which catapult agility) with the bathwater (bad meetings), let’s consider five reasons to  not  have a meeting, keeping rigor, alignment, and efficiency in mind:
1. The meeting is to gather information so someone else can make a decision.  This is a common pattern in financial management. Judy on the finance team needs to understand each group’s spending and forecasts, so she calls a monthly meeting that includes each cost center manager. One by one the managers go over their finances. There is little to no interaction among the teams, and no joint decision-making. Very convenient for Judy, but inefficient for everyone else.
2. The decision-maker is unclear and the meeting isn’t about that.  Even the best prepared and led meeting can fail if the path to a decision is unclear. A struggling business process cuts across three departments, and Henry, a leader in one of them, undertakes repair. Henry is a capable analyst, so he gathers the necessary data, lays out some options, and develops a recommendation matrix to share. The meeting itself nevertheless goes nowhere – the three department managers are not aligned that there is a problem or who should decide among the various solutions he has proposed. Henry, probably with the help of his manager, needs to prepare the field more effectively to efficiently gain alignment around his rigorous work.
3. An analyst or small team should do the work, not a meeting.   This is a common pattern in system analysis work. Sandra is charged with doing the data mapping from an existing system to a new service.   She calls a meeting of the developers of both systems, a selection of business analysts and testers, a few to-be users of the new capability – in short, everyone she can identify who might be able to help get the mapping done. This could be useful for Sandra but is inefficient for everyone else. She could get a lot of this done by doing the simple maps herself, working directly with key experts for items she can’t do on her own, and if alignment is needed on some complex concepts call focused meetings on those items.
4. Not enough preparation has been done.  Amazon has a cultural framework that reduces this risk: each meeting is to start with a quiet time for each participant to read a 2-6 page memorandum. Most of us are not fortunate enough to work in this kind of culture. Instead, we are often subjected to meetings with an agenda as the full extent of the preparation: Discuss the problem; identify options; agree on path forward. Don’t hold a meeting without proper analysis beforehand. Doing so is a sure path to failing the rigor test, and if alignment results it is likely to be around the wrong path.
5. There’s an inappropriate focus on process over people.   Underlying many bad meetings is a misplaced belief in process. A company was working with a potential partner to scope a development/implementation project. The work wasn’t proceeding as well as hoped, so during a governance status call the leaders set a date a few weeks out to get together and make the decisions on what would be in or out, and who would pay for what. The meeting was a colossal waste of time. No process or senior leadership involvement could compensate for the fundamental inability of the team to do the needed analysis work. A meeting wasn’t needed; a change in team leadership was required. In retrospect this was evident in the failure to put anyone on point to prepare for the meeting – there was no obvious effective leader to ask!
Broad disdain for bad meetings can undermine the enthusiasm we need to have for great meetings. Take the first step and determine if a meeting is the right tool for the problem at hand. If it isn’t, then don’t hold a meeting.

Michael K. Levine  is an expert on lean and agile software development and information technology. He’s worked at the US Commerce Department, First Bank System, and Norwest Banks; was CTO of a real estate software firm; and led Wells Fargo servicing technology through the default crisis. In 2011 he joined US Bank to deploy a new branch banking system; then was technology lead at US Bank Home Mortgage. He now leads all consumer lending and business banking technology. His latest book is  People Over Process: Leadership for Agility  (Productivity Press, September 30, 2019). He lives in St. Paul, Minnesota. Learn more at  TheTalesofAgility.com
", "image":{"@type": "ImageObject","url": "http://www.yibinjiudian.cn/uploads/cancel-meeting.jpg", "width":250,"height":167} }

皇冠|足球即时比分网

                        Five Reasons to Cancel That Meeting

                        by Michael Levine

                        Last Updated: Feb 14, 2020
                        Author Michael K. Levine reveals the secret to knowing when to hold and when to cancel a meeting, based on the principles of Leadership for Agility — rigor, alignment, and efficiency. He shares the five key factors that determine if a meeting is worth it, or a waste of everyone’s time and energy. 

                        five reasons to cancel a meeting
                        Image source: iStock.com

                        If someone asked you to name the most important single process in a large organization, especially an organization deeply dependent on software, what would you say? Budgeting and forecasting? Sales? Product planning? Hiring and people management

                        All of these are important, of course. But I would contend that the most important single process, critical to all these areas, is the much-reviled, hated, boring, confusing, and absolutely critical-to-everything meeting.

                        Large-scale technology development demands a new kind of leadership, which I’ve dubbed “leadership for agility.” It requires:

                        • Rigor — large numbers of people making good decisions
                        • Alignment – input from all who have something to add and broad agreement on chosen paths
                        • Efficiency — it’s done with respect for the time of all participants

                        Having extraordinarily prepared and executed meetings is a powerful leverage point. When done well, the purpose of the meeting is clear to participants going in. The ground is well prepared, and the background and context is widely shared. In the meeting, participants themselves do the work of developing and considering options in a rigorous way. At its best, this kind of meeting can result in a broad alignment around a common plan, enabling dispersed decision making to move the team forward in relative harmony.

                        Poor meetings, on the other hand, are annoying and wasteful. The most effective way to avoid them is to just not meet. Since we don’t want to throw out the baby (great meetings which catapult agility) with the bathwater (bad meetings), let’s consider five reasons to not have a meeting, keeping rigor, alignment, and efficiency in mind:

                        1. The meeting is to gather information so someone else can make a decision. This is a common pattern in financial management. Judy on the finance team needs to understand each group’s spending and forecasts, so she calls a monthly meeting that includes each cost center manager. One by one the managers go over their finances. There is little to no interaction among the teams, and no joint decision-making. Very convenient for Judy, but inefficient for everyone else.

                        2. The decision-maker is unclear and the meeting isn’t about that. Even the best prepared and led meeting can fail if the path to a decision is unclear. A struggling business process cuts across three departments, and Henry, a leader in one of them, undertakes repair. Henry is a capable analyst, so he gathers the necessary data, lays out some options, and develops a recommendation matrix to share. The meeting itself nevertheless goes nowhere – the three department managers are not aligned that there is a problem or who should decide among the various solutions he has proposed. Henry, probably with the help of his manager, needs to prepare the field more effectively to efficiently gain alignment around his rigorous work.

                        3. An analyst or small team should do the work, not a meeting.  This is a common pattern in system analysis work. Sandra is charged with doing the data mapping from an existing system to a new service. She calls a meeting of the developers of both systems, a selection of business analysts and testers, a few to-be users of the new capability – in short, everyone she can identify who might be able to help get the mapping done. This could be useful for Sandra but is inefficient for everyone else. She could get a lot of this done by doing the simple maps herself, working directly with key experts for items she can’t do on her own, and if alignment is needed on some complex concepts call focused meetings on those items.

                        4. Not enough preparation has been done. Amazon has a cultural framework that reduces this risk: each meeting is to start with a quiet time for each participant to read a 2-6 page memorandum. Most of us are not fortunate enough to work in this kind of culture. Instead, we are often subjected to meetings with an agenda as the full extent of the preparation: Discuss the problem; identify options; agree on path forward. Don’t hold a meeting without proper analysis beforehand. Doing so is a sure path to failing the rigor test, and if alignment results it is likely to be around the wrong path.

                        5. There’s an inappropriate focus on process over people.  Underlying many bad meetings is a misplaced belief in process. A company was working with a potential partner to scope a development/implementation project. The work wasn’t proceeding as well as hoped, so during a governance status call the leaders set a date a few weeks out to get together and make the decisions on what would be in or out, and who would pay for what. The meeting was a colossal waste of time. No process or senior leadership involvement could compensate for the fundamental inability of the team to do the needed analysis work. A meeting wasn’t needed; a change in team leadership was required. In retrospect this was evident in the failure to put anyone on point to prepare for the meeting – there was no obvious effective leader to ask!

                        Broad disdain for bad meetings can undermine the enthusiasm we need to have for great meetings. Take the first step and determine if a meeting is the right tool for the problem at hand. If it isn’t, then don’t hold a meeting.

                        Michael K. Levine is an expert on lean and agile software development and information technology. He’s worked at the US Commerce Department, First Bank System, and Norwest Banks; was CTO of a real estate software firm; and led Wells Fargo servicing technology through the default crisis. In 2011 he joined US Bank to deploy a new branch banking system; then was technology lead at US Bank Home Mortgage. He now leads all consumer lending and business banking technology. His latest book is People Over Process: Leadership for Agility (Productivity Press, September 30, 2019). He lives in St. Paul, Minnesota. Learn more at TheTalesofAgility.com

                        report this ad
                         
                         

                        Follow Us and Share

                        Subscribe to Our Free Newsletter
                        Enter your primary email address 

                        report this ad
                        report this ad
                        report this ad

                                              Finance

                                              Blog

                                              Real estate

                                              aviation

                                              Finance

                                              explore

                                              Super League

                                              aviation

                                              explore