Technical Management
#14-10-26-06: Contextual Definition
Contextual Definition
”Define your context, get your management style!”
Posted by Steven Cerri on Thursday, October 26, 2006
Good evening!
So ultimately we get back to the fundamental, basic question and that is:
What is the best management style to use in a given situation?
By now, after reading my last three blogs, you probably get that achieving results and selecting the management style that best achieves results is not just about the qualifications of the direct report or team being managed. In fact, I’m finishing a book right now and I’ve sent pre-publication copies out to friends, colleagues, and clients. Recently in talking to one who has been reviewing my book I asked him what was the one main idea he thought he’d gotten out of the book. (He’s a newly promoted manager in a technical company.) His response was:
“I now know that to the question ‘What’s the best management style in a given situation?’ the only answer that makes sense is ‘It depends. It depends on those six parameters you list.’”
That is the answer to Andy Card’s situation. It’s the answer to what has happened at Hewlett Packard. It’s the difference between the Army sergeant and the software business development manager.
And the best management style depends on the “Context Definition” which is defined by the following six parameters:
1. The expertise of the manager as compared to the expertise of the individual or team being managed
2. The risk of the task or project
3. The time frame of the task or project
4. The complexity or interfaces of the task or project
5. The learning outcome desired by the manager for the individual or team being managed
6. The management style preferred by the individual or team being managed
These six parameters define the context and will direct a manager to the best management style for a given situation.
These six parameters make up the Contextual Definition©. The contextual definition then leads the manager to a sliding scale of management styles from authoritative/directive to participative/coaching. The more the expertise lies with the manager, the more the task has high risk or a short timeframe or is complex, the more the manager would want to lean toward an authoritative/directive management style. The more the expertise lies with the team, the risk is low, the timeframe is longer, and the task is less complex, the more the manager would lean toward a more participative/coaching management style.
It’s quite clear that in the case of the Army sergeant, the risks are high, the timeframe is short, and the expertise generally lies with the sergeant. Therefore, the more directive approach works best.
In the case of the software development manager, the immediate risks are low, the timeframe will be relatively long, the complexity of the immediate task is low, and the expertise lies with the team. Therefore, the better management style is a more participative/coaching style.
In the case of HP the same thought process holds true. When the HP board went looking for a replacement for Carli Fiorina, they went looking for someone with a “difffernet management style”. From my vantage point, it’s not even appropriate to ask what management style an HP CEO should have. Carli Fiorina shouldn’t have had one, major management style to work from. Mark Hurd shouldn’t have one, major management style to work from. Their management styles should be tailored to the specific task to be achieved based on the six parameters that define the Contextual Definition. Their management style should change. A leader or manager shouldn’t be capable of being “pigeon-holed” as this type of manager or that type of manager.
The downfall of Carli Fiorina is that she joined HP with the idea that a specific management style, hers, was what was needed. It wasn’t a fit and a match and she was ultimately forced out. Now Mark Hurd is at the helm and he seems to have been labeled with a specific management style, one that currently is a fit and a match. As HP changes will Mark Hurd change his management style as well? Does he change it now as the tasks change on a daily or hourly basis or is the culture in such a backlash that his general style will due, for now, even if it doesn’t vary much?
Watch the news and the results will tell us.
Be well
Steven Cerri
Posted by Steven Cerri on 10/26 at 06:57 PM Management • Engineering Management • Management for engineers • Management for technologists • Technical Management • (0) Comments • Permalink
#13-10-23-06: Mgnt Extremes
Management Extremes
”And the winner of the Best Management Style is….!”
Posted by Steven Cerri on Monday, October 23, 2006
Good evening!
In this blog, I want to continue the thread I started two blogs ago in the blog of 101606. The topic is how best to manage to get results. I’ve introduced Andy Card’s comments in the book “State of Denial” and the situations brought about by Carli Fiorina and Mark Hurd at Hewlett Packard.
The basic message is that different situations require different management styles to get results. I want to give you two more examples to bring this important topic home.
Example #1: “Who’s going to take that hill?”
Imagine you are a U.S. Army Sergeant. You have group of privates under your command. Your team comes over a rise and spots the enemy on top a three hundred foot hill about a thousand yards away. Your mission is to take that hill. Either capture or kill the enemy, but take that hill.
This is the situation.
The question is: What’s the best management style to get the job done?
The answer:
It’s probably self-evident that you can’t use a “coaching” or “participative” management style and get the mission accomplished. Can you imagine the sergeant huddling with his men discussing and asking the following questions: “Ok fellas, who thinks they can get to that hill first? Who has a family? Single guys, without wife and kids, you probably ought to go in front. What do you think? What’s the best approach here?” It becomes obvious that neither participative or coaching management styles wouldn’t be a very effective management here.
The rationale :
The risk to life is very high. The time frame is short and intense. The battle is immanent. The weapons are known and understood. The terrain is known fairly well. This is not a new and uncertain situation. While there may be uncertainties, the team has practiced for just this event over and over. The leadership style is very directive. The sergeant knows exactly what the best approach to success is. The sergeant knows what the choices are. And therefore, the best management style is one in which the choices are limited, the training is called into play, and the most effective management style is a directive, authoritative one.
Now let’s go to the other end of the spectrum.
Example #2: “How creative can you be?”
Imagine you are managing a software team and your goal is to come up with the functionality of a new software program to compete with Intuit’s Quicken program. What functions will you want to include in order to provide a better product than Quicken and what functions will you leave out? How do you know which functions fall into which category and why? How much work will the various functions take to implement?
This is the situation.
The question is: What’s the best management style to get the job done?
The answer:
It’s probably self-evident that you can’t use a directive, authoritative management style here (although a good number of managers try to). Can you imagine sitting around a conference table and “dictating” that people come up with ideas and forcing a specific process to get the answers? Can you imagine a manager saying something like, “OK, I want thirty incredible functions that Quicken doesn’t currently have that are going to make our customers switch to our product, and I want the product to be cheaper than Quicken. And I want this product out the door in six months.” It isn’t going to happen.
The rationale :
Using the parameters discussed in Example #1 we know that there is no risk to life. The timeframe, while short as projected by the manager, may not be as short as six months. There is no battle around the corner. The elements of success are not really known. The functionality that will provide success is not known. This whole project is filled with uncertainties and what is most needed is creativity and decision-making, or even action. The group needs “ideas”. Therefore, the best management style is a “participative” management style that allows everyone in the room to contribute their best AND worst ideas.
With these two extreme examples you can see that a management style that works in one case will fail in the other. These extremes are everywhere in our everyday work environments. In the morning you can faced with a discussion about what equipment to purchase for your intranet and in the afternoon you can be faced with a crashed server that has to be brought up as fast as possible. These two situations can require two very different management styles.
On Thursday I’ll generalize this across a broad spectrum of situations and tell you what a coaching client says about the best approach.
Be well
Steven Cerri
Posted by Steven Cerri on 10/23 at 04:43 PM Management • Engineering Management • Management for engineers • Management for technologists • Technical Management • (0) Comments • Permalink
#11-10-16-06: Micro-Management or Bust!
Micro-Management or Bust
Managing for results AND empowerment
Posted by Steven Cerri on Monday, October 16, 2006
Good evening!
It seems lately that everywhere I turn, much of what I read about management and leadership keeps pointing to the same set of management deficiencies. It may be the major issue of managers and leaders; not just technical managers and leaders, but all managers and leaders. And quite simply it’s the inability of managers to manage so as to achieve results. Do any of the following three scenarios ring true for you?
1. You are a new manager. You have been given responsibility for a project and you have also been given three direct reports. The direct reports are all technically competent people. They have been out of school for several years and have been accomplished individual contributors. You sit down with them, discuss the tasks they will each be doing and you then send them on their way to accomplish their tasks. At the end of their respective task schedules, none of them has completed their tasks as they said they would, either on time or to the level of detail they and you anticipated. What has gone wrong and what should you have done?
2. You have a disruptive direct report. This direct report is constantly challenging your authority when they are alone with you. When you and they are in a team meeting, the direct report seems cooperative. But when you are not there, this direct report tends to undermine you in front of other people. This direct report doesn’t seem to feel the sense of commitment regarding getting tasks done on time that you do. Missing a schedule is just not that big a deal.
3. You give a task to a direct report. This direct report has a mixed track record. The direct report sometimes completes tasks on schedule. Other times they miss their schedule. You don’t want to be known as a “micro-manager” but you are uncertain if the person will complete their task if you give them an independent hand. But you choose to give the person a good deal of independence anyway. The project slips and the direct report has an excuse for the inability to complete the task on time. After several attempts to give this person an independent hand you decide to step in and manage them closely so the task can get done. What went wrong? What should you do differently next time, if anything?
Do any of these scenarios sound familiar? Do you have direct reports who behave like this? Should you manage closely or manage loosely? Should you ignore how people want to be managed and just manage to get the task completed?
Over the last several months, much of what I’ve read in business and technology magazines, and much of what I’ve heard from my clients, points to this one issue; how does a technology manager manage to get results and build a sense of empowerment and independence in employees at the same time? Or should a manager even try to accomplish these seemingly competing outcomes?
WHAT TO DO?
In order to answer these questions I first want to establish some common ground. And the first area of common ground is this: I want us to agree that the only tool a manager has is communication. It doesn’t matter if you have hire and fire authority of if you don’t; you still only have your ability to communicate as your tool of influence. Threatening an employee with termination if they don’t get the job done is still just a means of communication. A means called “intimidation”. So let’s agree that as a manager your most powerful and only tool is communication.
If it is true that communication is your only tool, then the next question is “How do you use communication to manage for results without making an employee feel that you do not trust them, that you don’t want them to make decisions; basically how do you manage and yet make an employee feel that they are empowered to make certain decisions on their own?
These will be the questions I’ll address in the next couple of blogs and I’ll use the three examples I presented at the beginning of this blog as examples.
See you Thursday.
Be well
Steven Cerri
Posted by Steven Cerri on 10/16 at 09:26 PM Engineer to Technical Manager • Management • Engineering Management • Management for engineers • Management for technologists • Technical Management • Inter-Personal People Skills • Communication for engineers • Soft Skills for engineers • Soft Skills for Technologists • (0) Comments • Permalink
