Month: May 2011
Some executives assume that they don’t need to have regular one-on-one meetings with their executive direct reports. The idea that such meetings aren’t really necessary “at our level” is short-sighted. What is not necessary is using the same one-on-one framework that you’d use if your direct reports were front-line staff. What is necessary is a framework more appropriate to the needs of an executive and his or her direct reports.
I highly recommend a weekly one-on-one with each of your executive direct reports (we’ll simply call them “managers” for this post), being flexible when needed. In addition to gaining valuable information that you need in order to be effective in your job, these meetings are a valuable way to help your managers understand the nature of your job and what you need in order to be successful. By doing this, you’ll not only get valuable information that you need, but you’ll be grooming your managers as part of your own succession planning.
Here’s the agenda I recommend, in this specific order (I’ll explain why shortly):
- Needs: How can I help you? What do you need from me in order to do your job?
- Updates: Make me smarter. What do you know that I need to know?
- Professional Development: How can we use opportunities in your current role to help you develop for your desired future role?
One of the three things that leaders owe their teams is to remove obstacles. Since execution and delivery are your team’s top priority, this is always the first item on the agenda. By so doing, you’ll know where you can add the most value NOW should your one-on-one meeting get cut short. They key question to be answered in this part of the meeting is, “What do you need from me in order to do your job?”
While you owe your team THREE things, your team owes you ONE thing; to make sure you have the opportunity to never make a mistake. Your managers can do this by providing you key updates, based on your needs. First, help your managers understand what you need to know, why you need to know it and what level of detail is required. Finally – and this is key – help your managers understand how you plan to use their updates.
Help your managers understand what “success” means at your level and how they can help make you successful. They do this by updating you on what’s happening in your area based on your needs as an executive, and to make sure you have the opportunity to never make a mistake. Don’t let them bury you in minutia; keep it focused and productive. This way, you not only get what you need to do your job but you make your managers smarter by helping them understand how they can help you.
Part of your role as a leader is to develop your staff to maximize their contribution to the business as well as to foster their personal development. Start by using the ‘Greed/Fear’ Framework to understand what each manager wants professionally and personally. Make sure you understand their short-term (current role) and long-term (overall career) goals.
Typically, business technology teams perform in one of three work streams:
- Operations and Production Support
- Policy and Procedures
- Projects and Initiatives
Frame each development opportunity within the relevant work stream so that you can provide feedback and development opportunities for your managers within the context of businesses needs.
Investing in our teams is an important part leadership. This is even more important when it comes to our executive level direct reports. A well-developed management team functions as your personal brain trust, helping you be a more effective leader. Such a management team also will earn the trust and confidence of your business partners and also from your managers’ respective organizations. You’ll also be grooming your managers so that you can ensure a smooth succession when your next opportunity arises within or without your current company. Take the time to meet with your managers on a regular basis and make sure you use a framework that meets your needs as a leader AND the needs of your managers as aspiring executives.
© 2011, Mark E. Calabrese
In Part I of this post, we said that the ‘Greed/Fear Framework’ is focused on understanding others and is driven by a genuine desire to invest in others by actively listening and by empathizing. This is easier on the ‘Professional’ level than on the ‘Personal level’. Let’s look at an example:
Your business partner is responsible for Call Center operations in your firm. The Call Center currently uses a legacy CRM system. While the system is fully paid-for, it runs on hardware that is no longer supported by the vendor and the CRM itself is also out of support (though partial support can be obtained through a third-party). Business operations depend on the predictable and reliable performance of the CRM. Your business partner has sponsored a project to replace this legacy system.
Your business partner has been with the firm for some time and has been in multiple roles within the organization. While not necessarily public knowledge, your business partner has been put in charge of this project as a ‘last chance’; should this project fail, part of the fallout may well be the elimination of your business partner’s job. Therefore, in addition to needing a reliable CRM for Call Center operations support, your business partner also needs a win.
This is how the example above might look in the Greed/Fear matrix:
The ‘Professional’ column is usually the easy part. An understanding of the business problem to be solved and the impact of doing nothing is generally enough, but it makes sense to gain a deeper understanding of the situation. What happened in the past? Why was the current system allowed to go so far out of support? What drove that decision (or lack of a decision)? These are all good questions to ask. The goal is not necessarily to fill out a framework; the goal is to gain the necessary understanding of the ‘Professional’ wants/don’t wants involved in the issue so that you have a solid context around the issue itself.
The ‘Personal’ column is often times more critical than the ‘Professional’ and presents its own unique set of problems. Most people at work want to look great and be successful in their job either because they want a promotion, want to get their full percentage of bonus or just because they get a deep personal satisfaction out of succeeding. But most people aren’t likely to share their ‘Personal/Fear’ and asking them is likely to damage your relationship.
Your only hope in “populating” the ‘Personal/Fear’ quadrant is to rely on your ability to ask the right questions, listen effectively, empathize, and ultimately, to trust your instincts. Some people are easier to read than others. Other people will be more than happy to share the content of their ‘Personal/Fear’ quadrant (sometimes more than you want!). Ultimately, you’re on your own to use your relationship-building skills to “populate” this key quadrant in the matrix.
You may also find similar challenges in “populating” the other quadrants. People are not always as candid as you’d like with the ‘Professional’, either. This is where the ability to build, maintain and leverage relationships becomes a key component in understanding the motivations of those with whom we work. Don’t assume that you can simply ask about the ‘Professional’ and it shall be given. You still need to sanity-check what you’ve heard against what you already know and what experience has taught you. Trust your instincts.
Keep in mind that the intent is to use the matrix as a mental framework to understand the motivation and actions of others. I don’t recommend telling others that you make use of this framework, as people may envision you analyzing them and writing down their motivations into little boxes. I’d also recommend that you not share the “contents” of your matrix. The purpose is to gain understanding so that you can communicate and work more effectively with others. Branding yourself as a workplace arm-chair psychologist is not a brand that inspires trust and confidence.
© 2011, Mark E. Calabrese
In 2008, I had an interesting dinner conversation with a business partner, Vin Deschamps, CEO at Echopass. Vin contends that humans are motivated by either “greed” or “fear” and I think he makes a valid point. Thinking about that, it occurred to me that understanding these motivators from a personal and professional perspective could yield a simple, but effective leadership and communication framework.
Understanding the Framework
‘Greed’ is a loaded word with negative connotations, but at root, it’s wholly appropriate. We may want more money, more free time to spend with our families, a new car, a better life for our children – any number of things – but ultimately we are motivated in part by what we WANT.
Conversely, we are also motivated by what we wish to AVOID – what we ‘Fear’. We may fear losing our jobs, poor health, a downturn in the economy – again, any number of things – but we are similarly motivated by what we do NOT want. If these observations don’t sound like rocket surgery to you so far, then we’re on the right track.
In the workplace, Greed and Fear come into play on two levels; the professional and the personal. The Professional level revolves around the job or function we are paid to perform – completing project X, running your department efficiently, etc.. The Personal level revolves around your own goals for yourself – your personal brand, your career objectives, your clout, etc.
The matrix below shows how the framework might look:
The goal of the framework is to gain an understanding others, which is at the core of building, maintaining and leveraging mutually beneficial relationships. Understanding people’s motivation (greed) and concerns (fear) at the personal and professional levels will help make sense of their words and actions, and how they interpret the words and actions of others.
The driver of the framework is genuine interest and the ability to listen and synthesize. This means employing active listening and getting invested in the relationship. You need to care about and have an interest in the other person. You have to flesh out the framework with REAL content.
In Part II, we’ll talk more about how to use the framework, as well as its limitations. As always, I welcome any comments either posted here or sent to me in email.
© 2011, Mark E. Calabrese
In Part I, we talked about setting up the postmortem meeting and in Part II, we discussed conducting the postmortem meeting itself. In Part III, we’ll focus on creating a deliverable that can be used to exploit both short-term and long-term opportunities through Action Items and Lessons Learned, respectively. Consider the following in completing your deliverable:
- Respect The Framework: The framework focuses on Pluses or Deltas in each phase of the project or incident. Therefore, only capture those practices that were successful and should be kept (Plus) or that were unsuccessful and should either be changed or discarded (Delta), by phase.
- Action Items or Lessons Learned: Every Plus or Delta captured in the postmortem must result in either an Action Item or a Lesson Learned. Action Items are specific actions that should be taken in the short-term and are assigned ONE owner and a due DATE. Lessons Learned are easy-to-understand guidelines or principles that are understandable on their own and do not require extensive knowledge of the project or incident in order to make sense. More on Action Items and Lessons Learned can be found below.
- Simplicity: Use a simple template and keep the contents pragmatic (I’ve attached a sample template, below). Some additional content, such as names/roles of participants, overview of the project or incident, etc., can be beneficial but the primary contents are Pluses and Deltas by phase and resulting Action Items and Lessons Learned. KEEP IT SIMPLE, creating a deliverable that is READABLE and USEFUL.
If you plan to submit your postmortem document to your business partners as part of project or incident closure, you may wish to include additional content. That said, strive to keep the content simple, direct and to the point unless circumstances DEFINITELY require otherwise.
ACTION ITEMS: Action Items can include, but are not necessarily limited to, any of the following:
- Meetings or Discussions: Meetings to discuss a process change or process development, a potential risk mitigation strategy, etc. In other words, setting up a meeting that might have otherwise have resulted in a problem-solving or sidebar discussion during the postmortem. Do NOT conduct such discussions in the postmortem; conduct them on their own, with the appropriate stakeholders in attendance, and call out an Action Item to make the meeting happen.
- Specific Actions: For example, any code changes, configuration changes, etc. Any specific actions required in the short-term to address any issues that were raised during the postmortem or immediately after project go-live or incident closure.
Action Items have ONE owner, who is accountable for completion. Even if multiple resources will be involved in completing the work, there is only ONE person accountable for ensuring the item is completed and closed by the due date.
Action Items have a Due DATE. The postmortem facilitator should have the Action Item owner set the due date, but if the owner hedges, suggest a due date to them and NAIL THEM DOWN. The due date can always change, but get a commitment during the postmortem and DOCUMENT IT.
LESSONS LEARNED: Lessons Learned should be archived in a single Lessons Learned Master Document (e.g., a simple MS Word document with bullet points). You can categorize Lessons Learned by phase, etc., but be careful; the more you play with the list, the more likely you’ll end up making a task out of maintaining the list. Better to maintain a simple list that can be printed out and reviewed at the start of every project as a reminder of what was learned in past projects and what should be considered in the current project.
Each Lesson Learned should be stated very clearly and concisely and should be understandable ON ITS OWN and on a FIRST READ. Lessons Learned should NOT require detailed knowledge of the project in order to gain context and understanding. Therefore, it’s important to edit each Lesson Learned to make sure they are well written. Have someone who is NOT familiar with the project or incident review the final Lessons Learned for readability before they’re added to the overall Lessons Learned Master Document.
Review the Lessons Learned Master Document after each project or incident to ensure there are no duplicates and also to ensure that, as noted above, each lesson is clear and understandable. Production support/service restoration issues will now allow the luxury of a review of the Master Document at issue identification, so support teams may wish to review the Document on a regular basis as a risk mitigation strategy.
The template below is a baseline document to be stolen/edited it as you see fit. As always, I welcome any comments, questions or thoughts and can be contacted at firstname.lastname@example.org. Good luck!
© 2011, Mark E. Calabrese