Here is the reason managers get paid for their "judgment!"
be well,
Dwika-ExecuTrain
"What does a manager get paid for?"
by: Steven Cerri
I know, I know....
A manager gets paid for results!
or maybe it's.....
A manager gets paid for the results of the people he/she manages!
or maybe it's....
A manager gets paid to manage things!
or maybe it's....
A manager gets paid to worry!
I could go on and on... but... here is the reason managers get paid that I want to talk about....
Managers get paid for their "judgment!"
That's right...
Managers get paid for their judgment.
What is judgment?
Well, I'm not even going to go there. I'll discuss what judgment is in a future blog.
However, what I really want to turn you on to are the answers to these two questions... "How do you improve your judgment and what is the source of judgment?"
Well, neurologically, the source of judgment seems to be two lobes that you and everyone else has. However, not everyone's lobes are equally developed. In fact, if your lobes are not very well developed it seems pretty certain from research that you won't have good judgment.
However, if your lobes are well developed, your judgment will be pretty good. The better developed, the better your judgment.
These lobes are the "frontal lobes" of your brain. They are the seat of risk aversion, risk assessment, judgment, the interpretation of feedback from the environment, and the projection of consequences into the future, among other functions.
If your frontal lobes are not well developed, if something during childhood or later years impaired their development, then your judgment may not be what you'd like it to be.
Also, if your frontal lobes are well developed then you probably make good decisions and have a capability of assessing how the future will turn out.
You probably know people who have had a great deal of experience and still don't seem to have "good judgment". You also probably know young people who seem to have very good judgment. In fact, the phrase about someone being an "old soul" may be a colloquial way of unknowingly acknowledging good judgment in someone and therefore, the development of their frontal lobes.
There is a great new website that addresses frontal lobe development, judgment, and exercises to strengthen the frontal lobes for the specific development of judgment.
Check it out. It's at: Sharp Brains
Tampilkan postingan dengan label Steven Cerri. Tampilkan semua postingan
Tampilkan postingan dengan label Steven Cerri. Tampilkan semua postingan
Selasa, 30 November 2010
Teaching moment
Young managers to build a team, and go there together. The contrast between their natural response was an important teaching moment.
be well,
Dwika-ExecuTrain
"The more we change the more we stay the same."
by: Steven Cerri
Stuff just keeps repeating, and repeating, and repeating, and repeating, and......
Did you ever wonder why history keeps repeating itself?
Not just the history of our nation or the history of nations of the world... but did you ever notice how some aspects of your career keep repeating? How certain aspects of your professional life keep repeating?
Have you ever taken note of what aspects of your professional life keep repeating?
Is it the:
• maximum level at which your career can advance?
• type of boss you can work for or can't work for?
• type of colleague you can't abide or work best with?
• type of project you excel at or you crash on?
If there is repeatability in your career either positive or negative then this may be a sign that you aren't making these particular choices in your life, your apparent choices are really nothing more than personal programs that run themselves over and over and you're along for the ride.
But have heart... you're not alone. We all are driven, in part, by our "internal programming" and it often keeps real choice from showing up in our lives with both positive and negative results.
And what causes this repeating pattern you might ask?
Actually there are several causes.
The first cause is that the patterns we currently have, at some point in our lives really did work and maybe some of them still do. In the past, these patterns helped us to succeed and without anything to replace them we assume they will continue to help us succeed. And so we continue to use the same patterns.
The second cause is that all around us is a culture, a philosophy, an underlying "dialogue" that convinces us that we are to behave in a certain way. Whether it is to purchase a bigger house, or to trade in that old tube television set for a flat screen, or to buy music one song at a time over the Internet instead of buying 12 at once on a CD, or to eat fast food because we haven't time to cook and eat, the underlying dialogue is there.
Whatever the message it is a low-level noise that continues to move us toward a specific outcome.
And one of those low-level dialogues that consistently shows up in American business environments is what it means to be a leader, or manager, or what it means to be "in charge".
I never cease to be amazed at how powerful this underlying whisper is in our business environment and even in our schools. This week I conducted a class at the University of California at Santa Barbara, UCSB. I teach there regularly in their Technology Management Program (TMP). The TMP is part of the curriculum in the UCSB Engineering School. The title of my course is "So you want to be a technical manager?"
I usually give my students a case study to work on, as I again did in this class. The case study is a true situation that happened to me when I was director of engineering in a software company. In the case study, I had just been hired and I "inherited" four software programs, managed by four different program managers. Two programs were on schedule and in budget, one was months behind schedule and over budget, and one was behind schedule and out of money.
I gave my class the case study in which the program was behind schedule and out of money. The contract also had a subcontractor that was behind schedule and out of money?
Now my basic philosophy is that we should alter our management style depending upon the situation we are attempting to manage. One of the parameters I use to make this decision is the risk of the project and another is the expertise of the manager compared to the expertise of the team members. (There are six parameters that I use to determine the optimum management style. I call the process "Contextual Definition").
I laid out to the class the conditions of the situation as I found them when I joined the company.
In the the actual business situation the expertise did not rest with me, it rested with the team I inherited. Likewise, in this case study, the expertise did not rest with the students since they were assuming my role as director of engineering.
Because of the specifics of the situation a management style that was more participative seemed in order. How can a manager who doesn't understand the workings of the project nor the technology expect to step into the management role and "dictate" or "direct" what needs to be done.
I laid out the situation to the students and their task was to manage the program back to health.
Now a very interesting thing occurred. They opted to show they were in control instead of building a team that worked together. They resorted to the Donald Trump approach... "You fix this OR ELSE!"
There is no doubt in my mind that this is a fear-based management approach. In fact, they all indicated in one way or another that they were afraid they didn't know how to fix the situation and since the team didn't deliver up until taking over the program they're best approach was to brow-beat the workers into doing a better job.
The message here is that even business and engineering majors in their early 20s have already been conditioned to feel so insecure when leading that they have to take an authoritative position.
In my situation, when I took over the project, I used a more participative approach and got both my team and the subcontractor to contribute their own time to finish the project, something that, I'm sure, would not have happened if I had taken an authoritative approach.
In the face of uncertainty, the underlying management dialogue or noise is that leaders "get tough" and tell people what to do... or else.
Instead, in the face of uncertainty, I teach our young managers to build a team, and go there together. The contrast between their natural response and what I teach and what had worked for me was an important teaching moment.
be well,
Dwika-ExecuTrain
"The more we change the more we stay the same."
by: Steven Cerri
Stuff just keeps repeating, and repeating, and repeating, and repeating, and......
Did you ever wonder why history keeps repeating itself?
Not just the history of our nation or the history of nations of the world... but did you ever notice how some aspects of your career keep repeating? How certain aspects of your professional life keep repeating?
Have you ever taken note of what aspects of your professional life keep repeating?
Is it the:
• maximum level at which your career can advance?
• type of boss you can work for or can't work for?
• type of colleague you can't abide or work best with?
• type of project you excel at or you crash on?
If there is repeatability in your career either positive or negative then this may be a sign that you aren't making these particular choices in your life, your apparent choices are really nothing more than personal programs that run themselves over and over and you're along for the ride.
But have heart... you're not alone. We all are driven, in part, by our "internal programming" and it often keeps real choice from showing up in our lives with both positive and negative results.
And what causes this repeating pattern you might ask?
Actually there are several causes.
The first cause is that the patterns we currently have, at some point in our lives really did work and maybe some of them still do. In the past, these patterns helped us to succeed and without anything to replace them we assume they will continue to help us succeed. And so we continue to use the same patterns.
The second cause is that all around us is a culture, a philosophy, an underlying "dialogue" that convinces us that we are to behave in a certain way. Whether it is to purchase a bigger house, or to trade in that old tube television set for a flat screen, or to buy music one song at a time over the Internet instead of buying 12 at once on a CD, or to eat fast food because we haven't time to cook and eat, the underlying dialogue is there.
Whatever the message it is a low-level noise that continues to move us toward a specific outcome.
And one of those low-level dialogues that consistently shows up in American business environments is what it means to be a leader, or manager, or what it means to be "in charge".
I never cease to be amazed at how powerful this underlying whisper is in our business environment and even in our schools. This week I conducted a class at the University of California at Santa Barbara, UCSB. I teach there regularly in their Technology Management Program (TMP). The TMP is part of the curriculum in the UCSB Engineering School. The title of my course is "So you want to be a technical manager?"
I usually give my students a case study to work on, as I again did in this class. The case study is a true situation that happened to me when I was director of engineering in a software company. In the case study, I had just been hired and I "inherited" four software programs, managed by four different program managers. Two programs were on schedule and in budget, one was months behind schedule and over budget, and one was behind schedule and out of money.
I gave my class the case study in which the program was behind schedule and out of money. The contract also had a subcontractor that was behind schedule and out of money?
Now my basic philosophy is that we should alter our management style depending upon the situation we are attempting to manage. One of the parameters I use to make this decision is the risk of the project and another is the expertise of the manager compared to the expertise of the team members. (There are six parameters that I use to determine the optimum management style. I call the process "Contextual Definition").
I laid out to the class the conditions of the situation as I found them when I joined the company.
In the the actual business situation the expertise did not rest with me, it rested with the team I inherited. Likewise, in this case study, the expertise did not rest with the students since they were assuming my role as director of engineering.
Because of the specifics of the situation a management style that was more participative seemed in order. How can a manager who doesn't understand the workings of the project nor the technology expect to step into the management role and "dictate" or "direct" what needs to be done.
I laid out the situation to the students and their task was to manage the program back to health.
Now a very interesting thing occurred. They opted to show they were in control instead of building a team that worked together. They resorted to the Donald Trump approach... "You fix this OR ELSE!"
There is no doubt in my mind that this is a fear-based management approach. In fact, they all indicated in one way or another that they were afraid they didn't know how to fix the situation and since the team didn't deliver up until taking over the program they're best approach was to brow-beat the workers into doing a better job.
The message here is that even business and engineering majors in their early 20s have already been conditioned to feel so insecure when leading that they have to take an authoritative position.
In my situation, when I took over the project, I used a more participative approach and got both my team and the subcontractor to contribute their own time to finish the project, something that, I'm sure, would not have happened if I had taken an authoritative approach.
In the face of uncertainty, the underlying management dialogue or noise is that leaders "get tough" and tell people what to do... or else.
Instead, in the face of uncertainty, I teach our young managers to build a team, and go there together. The contrast between their natural response and what I teach and what had worked for me was an important teaching moment.
Motivational maps 1
By understanding the motivational maps of colleagues, direct reports, and customers, you can have impact beyond that provided by positional authority.
be well,
Dwika-ExecuTrain
Case Study #1: "Sam Won't Give Up His Software because it just isn't perfect!
by: Steven Cerri
(less than 5 minute read)
Sam was a young programmer with a BS in computer science. He'd been with our company for about three years. He was sharp, confident, personable, and a good programmer. He was our chief engineer in charge of the development of the user interface for a large database we were developing for a very important customer.
The contract called for rapid prototyping of the user interface, allowing us to receive customer feedback on the human-machine interaction as early in the development cycle as possible; at least that was the plan. Sam had agreed to a three-month prototype development schedule. But five weeks had passed and Sam was a week behind schedule on the delivery of the first iteration of the prototype interface. The program manager asked Sam when the prototype would be delivered to the customer for interface input and Sam said; "Just a few more days." A few more days passed and again Sam indicated that the interface was not ready. He needed "a few more days". This went on for another week until six and a half weeks had passed since the beginning of the contract. Sam was close to being three weeks behind schedule, and the customer was getting worried, as was the program manager. Tom seemed reluctant to release the prototype interface to the customer.
The program manager asked for my help, pleading that Sam must release the prototype interface immediately. Unfortunately, the program manager didn't understand the software well enough to know if Sam was being reasonable or if he was being a perfectionist. Reasonable was fine. A perfectionist we didn't need. This was after all the rapid prototyping phase to get customer feedback.
What would you have done in this situation? Would you have ordered Sam to deliver the prototype software? Would you have given him all the time he wanted? Would you have renegotiated the contract? Would you have threatened Sam? Would you have put an expert with Sam to evaluate the software status? Would you have reasoned with Sam? What would you have done?
My Actions: This is what I did. First, my basic assumption is always that people are doing what they think is right. I don't believe people are trying to be difficult. I believe people are always doing what, in their mind, is the best, most reasonable thing for them to do. That meant that Sam's hesitation in releasing the software had some reasonable rationale in Sam's mind.
So I wanted to understand why Sam was unwilling to release the software, and since I believe people will basically tell you the truth. I asked him. I said: "Sam, I understand you aren't yet willing to release the prototype software to the customer. What are you attempting to accomplish?" Then I listened and I just let him talk.
He responded that he wanted the prototype interface loaded with enough ideas so he could get all the feedback he possibly could from the customer before developing the final program. Now I knew that Sam was after the same thing we all were; good customer input.
This was the key. If I could find a way to satisfy Sam's goal and get the software in the customer's hands immediately, everybody wins. So I next said to Sam; "You know Sam, you have just about enough time, if you give the software to the customer tomorrow, to actually get one more iteration of the customers' input. Seems to me that rather than delaying delivery and getting only one iteration, you could release it tomorrow and actually get a second opportunity for the customers' input. That would make your interface much more of a match with what the customer really wants, because they'll get smarter as the project goes along, and so will you. Just think about it Sam." And I walked away. The software was in the customer's hands the next day.
What did I do in my conversation with Sam? I actually matched what Sam wanted with what our company and our customer wanted. I could have ordered Sam to deliver the software but that was only one choice. By my conversation with Sam, I refocused Sam's intention so that he was motivated to release the software as soon as possible. Why be autocratic when I could just as easily motivate Sam to deliver the software using his own internal motivation? Internal motivation can often be much more powerful than external motivation.
By understanding the motivational maps of colleagues, direct reports, and customers, you can have impact beyond that provided by positional authority.
be well,
Dwika-ExecuTrain
Case Study #1: "Sam Won't Give Up His Software because it just isn't perfect!
by: Steven Cerri
(less than 5 minute read)
Sam was a young programmer with a BS in computer science. He'd been with our company for about three years. He was sharp, confident, personable, and a good programmer. He was our chief engineer in charge of the development of the user interface for a large database we were developing for a very important customer.
The contract called for rapid prototyping of the user interface, allowing us to receive customer feedback on the human-machine interaction as early in the development cycle as possible; at least that was the plan. Sam had agreed to a three-month prototype development schedule. But five weeks had passed and Sam was a week behind schedule on the delivery of the first iteration of the prototype interface. The program manager asked Sam when the prototype would be delivered to the customer for interface input and Sam said; "Just a few more days." A few more days passed and again Sam indicated that the interface was not ready. He needed "a few more days". This went on for another week until six and a half weeks had passed since the beginning of the contract. Sam was close to being three weeks behind schedule, and the customer was getting worried, as was the program manager. Tom seemed reluctant to release the prototype interface to the customer.
The program manager asked for my help, pleading that Sam must release the prototype interface immediately. Unfortunately, the program manager didn't understand the software well enough to know if Sam was being reasonable or if he was being a perfectionist. Reasonable was fine. A perfectionist we didn't need. This was after all the rapid prototyping phase to get customer feedback.
What would you have done in this situation? Would you have ordered Sam to deliver the prototype software? Would you have given him all the time he wanted? Would you have renegotiated the contract? Would you have threatened Sam? Would you have put an expert with Sam to evaluate the software status? Would you have reasoned with Sam? What would you have done?
My Actions: This is what I did. First, my basic assumption is always that people are doing what they think is right. I don't believe people are trying to be difficult. I believe people are always doing what, in their mind, is the best, most reasonable thing for them to do. That meant that Sam's hesitation in releasing the software had some reasonable rationale in Sam's mind.
So I wanted to understand why Sam was unwilling to release the software, and since I believe people will basically tell you the truth. I asked him. I said: "Sam, I understand you aren't yet willing to release the prototype software to the customer. What are you attempting to accomplish?" Then I listened and I just let him talk.
He responded that he wanted the prototype interface loaded with enough ideas so he could get all the feedback he possibly could from the customer before developing the final program. Now I knew that Sam was after the same thing we all were; good customer input.
This was the key. If I could find a way to satisfy Sam's goal and get the software in the customer's hands immediately, everybody wins. So I next said to Sam; "You know Sam, you have just about enough time, if you give the software to the customer tomorrow, to actually get one more iteration of the customers' input. Seems to me that rather than delaying delivery and getting only one iteration, you could release it tomorrow and actually get a second opportunity for the customers' input. That would make your interface much more of a match with what the customer really wants, because they'll get smarter as the project goes along, and so will you. Just think about it Sam." And I walked away. The software was in the customer's hands the next day.
What did I do in my conversation with Sam? I actually matched what Sam wanted with what our company and our customer wanted. I could have ordered Sam to deliver the software but that was only one choice. By my conversation with Sam, I refocused Sam's intention so that he was motivated to release the software as soon as possible. Why be autocratic when I could just as easily motivate Sam to deliver the software using his own internal motivation? Internal motivation can often be much more powerful than external motivation.
By understanding the motivational maps of colleagues, direct reports, and customers, you can have impact beyond that provided by positional authority.
The best at the time
Everyone is doing what they think is best at the time. Therefore, if someone is resisting, it's probably because they truly believe that they are doing what is best for them, for the company, and for the task.
be well,
Dwika-ExecuTrain
"Motivation By Reference."
by: Steven Cerri
(10 minute read)
Have you ever noticed how people make decisions? Most of us haven't analyzed this topic. But how we and others make decisions is directly tied to motivation. And the way we process data directly relates to how we make those decisions to be motivated to do something or not.
Let me give you an example. Many years ago I purchased my first single-lens-reflex (SLR) camera. I was at a point in my life where I wanted to buy an SLR and as a college student it was a big investment. So I wanted to buy a camera that I knew would be what I wanted.
And that was the major question. "What do I want and why?" Perhaps because I was an engineer I decided to build a matrix. The matrix was on a large piece of paper (2' x 3') so I could view all the information at once. I took every conceivable parameter that I could evaluate and compared those parameters in twenty different SLR cameras.
Using the matrix and all the parameters in my matrix, I narrowed my search down to three cameras. Then I went to a camera store and asked to see and hold each of the three finalists. I held each camera as if I was using it to take pictures. I played with the controls. I took off each of the lenses. I asked the attendant questions. Finally, I selected the one that "felt" the best in my hands. I purchased that camera and I've loved it ever since.
That is how I made my decision to buy my camera. But was it a random process or was their some predictability to it? Do I do that every time I buy something? Have you noticed how you make decisions or is it something that you don't give any thought too?
I can tell you that the process is not random. It is predictable. In fact, if you watch closely you will notice that there are certain people who make decisions based on reviewing evidence, talking to people, and gathering information. They gather as much "external" data as possible before making a decision. If they want to buy a car, they read magazines, they go on-line to read reviews, they talk to people who own the cars they are considering. They believe the idea that word of mouth is the most important type of marketing and the most important source of accurate information. This is exactly what I did in the first part of my decision process by doing research and constructing a matrix.
You've probably noticed other people who seek information from no one, but instead make decisions based on a set of rules "inside their heads"? They want a personal experience or they go through a personal, internal process to make their decisions. If they are interested in buying a car they'll go for a test drive. They'll rent the car for a week and see how it feels, how it drives. They'll decide what car to buy based on their own experience of the car. This is what I did in the second portion of my camera buying decision by holding each of the cameras and running scenarios as if I was taking pictures with each.
Therefore, in the first portion of my decision-making process I sought out external information, while in the second portion I wanted to experience it for myself.
Now you might say, "Well that was about buying a camera and that was a long time ago. That probably doesn't have much to do with the present or with management in my technical organization." Well, let's see.
Lets fast-forward from my college days to just a couple of years ago and see if my purchasing strategies had changed over time.
Several years ago I wanted to buy a kayak. I decided to make my decision by learning all I could about kayaks. This seemed reasonable since there a many different types of kayaks and I wanted to understand what my choices were.
I searched the Internet, read magazines, and talked to dozens of people about the different types of kayaks. In the course of a couple of weeks, I had accumulated more than enough "research" information for my decision and although I didn't make a matrix of the data I had a "sense" of the groups I would choose from. But I didn't know how to choose the right kayak from the narrowed field I had developed. I felt overwhelmed by the different choices and I didn't have an innate sense of how to prioritize and filter the remaining choices.
My next step was to attempt to find some way to "personally" experience the various kayaks I had placed in the final group. That meant I had to do something that would give me the personal experience I needed to filter and prioritize and decide which kayak to buy. I needed to actually use each kayak that I thought would be a choice.
I sought out an opportunity to use several different kayaks. I found an outdoor store that was sponsoring a day on the water with kayaks. Potential customers could use as many kayaks as they wanted for the day to get a sense of what kayaking was all about. I now had my chance to actually use several different kayaks. So I jumped at the chance to spend a day on the bay.
It soon became clear to me which kayak I wanted to buy. Not because someone told me but because of my personal experience using it. I could now make my decision based on my own experience, my own "internal" experience.
If you look closely at my two buying strategies, for the camera and the kayak, you'll notice that they are the same. In both cases I did "external" research until I reduced the possible candidates down to something I could experience, and then I had an "internal" experience of each. From there it was easy to make my decision.
In the vocabulary of communication, management and linguistics, we say that when I was doing research I was being "externally referenced" and when I was gathering information from my own personal experience I was being "internally referenced".
Therefore, my buying strategy for purchasing both the camera and the kayak was to be "externally referenced" first, by seeking information from the outside world and to be "internally referenced" second, by gaining a personal experience. This allowed me to feel comfortable that I understand my choices and then to feel confident in my decision.
Why is this such a big deal?
The reason I'm spending time on these examples is that I want you to understand that decision-making strategies are not arbitrary, they are predictable. Human beings have "processes" that we use over and over again because, from our personal perspective, they work.
And I'm not making arbitrary distinctions. Just as a computer has software applications that we run to solve certain types of problems, each of us has a set of internal mental programs I call Personal Behavioral Sub-Routines (PBSR) that we "run" when we want to solve problems or make decisions. Some people use certain PBSRs that allow them to make their decisions using "external references". That is, they seek information from the outside world. They want to know what others think, what others have experienced. Other people use PBSRs that rely instead on their own "internal experience" to decide. They rely on an "internally referenced" program to make a decision. And some people use a combination of both and in different order.
Does this has to do with management?
What does this have to do with technical management and with motivation? Actually, everything. Whether we are talking about your technical customer, your boss, your direct reports, or your colleagues, each person makes decisions using data from a specific set of sources and by a specific set of processes. People also use these processes (their PBSRs) to either be motivated to do something or to not do it. People either gather data from certain types of external sources or they use their own internal source and / or some combination of both, but the process is predictable.
And here is the significant point; if a person can't get the information the way they want it (i.e., either internally or externally referenced in the way they want it) then they won't make the decision or they won't be motivated. As in the examples of my camera and kayak purchases, if I had been unable to get the internally referenced information, I would not have made the decision. In your business world, if your boss, your colleagues, or your customer, can't get their information the way they want it, they won't make the decision they and you want them to make. This means that if you don't motivate someone according to their "motivation" Personal Behavioral Sub-Routine they won't get motivated. It's that simple and that subtle.
Therefore, what makes this so important for management is that if you attempt to convince a person by using a strategy that doesn't match theirs, one that doesn't match their PBSRs, you will frustrate them and they will resist your influence.
My basic premise in management is that everyone is doing what they think is best at the time. Therefore, if someone is resisting you it's not because they want to be difficult. It's probably because they truly believe that they are doing what is best for them, for the company, and for the task. If this assumption is true then it is your responsibility, the person who is trying to motivate them, to change your motivation strategy to fit what they need to see, hear, and know in order to be motivated. In reality, this is the way it works all the time, even if you don't know it on a conscious level. Everyone is motivated to do anything; have dinner with you; take your direction; vote for a presidential candidate; like a specific song; all because the communication and the data they receive resonates and matches the data they want in the way they want it.
Some Examples: Let's take several examples. Let's say you have a client to whom you are trying to sell your product. If your client is internally referenced they will want a personal experience of your product or service, or they'll want to understand the subject for themselves. If you keep offering them the names and phone numbers of your other satisfied customers for them to contact, you are giving them external references. That's not what they want and they will become frustrated. They want to experience and understand your product for themselves.
On the other hand, if your client is externally referenced, they will want to talk to others who have used your services or your product. If you attempt to give them a direct experience of your service or product, or if you keep explaining your product to them you will frustrate them as well. They are being externally referenced and you are feeding them internally referenced information.
This is also be important when motivating people. If you are managing an internally referenced employee, you will frustrate them by giving them too much direction. You'll be thinking that you are helping them and they'll be thinking, "Just let me start. I'll figure it out once I get into it."
However, an externally referenced employee will want to know everything you can tell them about the task before they start. They'll take the position, "There's no use reinventing the wheel. I might as well get as much information as possible before I start."
Without understanding these two differences, you may be communicating in ways that make your desired outcome harder to achieve. Imagine giving too much guidance to an internally referenced employee or giving too little to an externally referenced employee.
You'll also find that highly externally referenced people want to have meetings with all the potentially affected departments before making a major decision. Whereas highly internally referenced people make decisions on their own, and then wonder why other departments are so upset for not being included.
Imagine putting a highly externally referenced person on a team with a highly internally referenced person and making them relatively equal in power and authority. (This is exactly what happened in one major company I was working with.) The internally referenced person will want to move forward based on their internal understanding of what they believe is right. The externally referenced person will want to talk to all potentially affected people and departments and then make the decision. The internally referenced person will think that the externally referenced person is incapable of making a decision, and the externally referenced person will think the internally referenced person "shoots from the hip" and is not a team player.
The bottom line is that if you attempt to influence in a way that is not aligned with the way a person makes decisions, you will often frustrate them and therefore, fail to influence them. This may not be because your argument is weak, or because you haven't enough information. It may be because you've packaged your message in a way that is counter to the way the listener wants to receive it.
Those of you who are more externally referenced will want to read more about this topic.
Those of you who are more internally referenced are probably wondering what your own PBSRs and strategies are.
Which approach feels better to you?
be well,
Dwika-ExecuTrain
"Motivation By Reference."
by: Steven Cerri
(10 minute read)
Have you ever noticed how people make decisions? Most of us haven't analyzed this topic. But how we and others make decisions is directly tied to motivation. And the way we process data directly relates to how we make those decisions to be motivated to do something or not.
Let me give you an example. Many years ago I purchased my first single-lens-reflex (SLR) camera. I was at a point in my life where I wanted to buy an SLR and as a college student it was a big investment. So I wanted to buy a camera that I knew would be what I wanted.
And that was the major question. "What do I want and why?" Perhaps because I was an engineer I decided to build a matrix. The matrix was on a large piece of paper (2' x 3') so I could view all the information at once. I took every conceivable parameter that I could evaluate and compared those parameters in twenty different SLR cameras.
Using the matrix and all the parameters in my matrix, I narrowed my search down to three cameras. Then I went to a camera store and asked to see and hold each of the three finalists. I held each camera as if I was using it to take pictures. I played with the controls. I took off each of the lenses. I asked the attendant questions. Finally, I selected the one that "felt" the best in my hands. I purchased that camera and I've loved it ever since.
That is how I made my decision to buy my camera. But was it a random process or was their some predictability to it? Do I do that every time I buy something? Have you noticed how you make decisions or is it something that you don't give any thought too?
I can tell you that the process is not random. It is predictable. In fact, if you watch closely you will notice that there are certain people who make decisions based on reviewing evidence, talking to people, and gathering information. They gather as much "external" data as possible before making a decision. If they want to buy a car, they read magazines, they go on-line to read reviews, they talk to people who own the cars they are considering. They believe the idea that word of mouth is the most important type of marketing and the most important source of accurate information. This is exactly what I did in the first part of my decision process by doing research and constructing a matrix.
You've probably noticed other people who seek information from no one, but instead make decisions based on a set of rules "inside their heads"? They want a personal experience or they go through a personal, internal process to make their decisions. If they are interested in buying a car they'll go for a test drive. They'll rent the car for a week and see how it feels, how it drives. They'll decide what car to buy based on their own experience of the car. This is what I did in the second portion of my camera buying decision by holding each of the cameras and running scenarios as if I was taking pictures with each.
Therefore, in the first portion of my decision-making process I sought out external information, while in the second portion I wanted to experience it for myself.
Now you might say, "Well that was about buying a camera and that was a long time ago. That probably doesn't have much to do with the present or with management in my technical organization." Well, let's see.
Lets fast-forward from my college days to just a couple of years ago and see if my purchasing strategies had changed over time.
Several years ago I wanted to buy a kayak. I decided to make my decision by learning all I could about kayaks. This seemed reasonable since there a many different types of kayaks and I wanted to understand what my choices were.
I searched the Internet, read magazines, and talked to dozens of people about the different types of kayaks. In the course of a couple of weeks, I had accumulated more than enough "research" information for my decision and although I didn't make a matrix of the data I had a "sense" of the groups I would choose from. But I didn't know how to choose the right kayak from the narrowed field I had developed. I felt overwhelmed by the different choices and I didn't have an innate sense of how to prioritize and filter the remaining choices.
My next step was to attempt to find some way to "personally" experience the various kayaks I had placed in the final group. That meant I had to do something that would give me the personal experience I needed to filter and prioritize and decide which kayak to buy. I needed to actually use each kayak that I thought would be a choice.
I sought out an opportunity to use several different kayaks. I found an outdoor store that was sponsoring a day on the water with kayaks. Potential customers could use as many kayaks as they wanted for the day to get a sense of what kayaking was all about. I now had my chance to actually use several different kayaks. So I jumped at the chance to spend a day on the bay.
It soon became clear to me which kayak I wanted to buy. Not because someone told me but because of my personal experience using it. I could now make my decision based on my own experience, my own "internal" experience.
If you look closely at my two buying strategies, for the camera and the kayak, you'll notice that they are the same. In both cases I did "external" research until I reduced the possible candidates down to something I could experience, and then I had an "internal" experience of each. From there it was easy to make my decision.
In the vocabulary of communication, management and linguistics, we say that when I was doing research I was being "externally referenced" and when I was gathering information from my own personal experience I was being "internally referenced".
Therefore, my buying strategy for purchasing both the camera and the kayak was to be "externally referenced" first, by seeking information from the outside world and to be "internally referenced" second, by gaining a personal experience. This allowed me to feel comfortable that I understand my choices and then to feel confident in my decision.
Why is this such a big deal?
The reason I'm spending time on these examples is that I want you to understand that decision-making strategies are not arbitrary, they are predictable. Human beings have "processes" that we use over and over again because, from our personal perspective, they work.
And I'm not making arbitrary distinctions. Just as a computer has software applications that we run to solve certain types of problems, each of us has a set of internal mental programs I call Personal Behavioral Sub-Routines (PBSR) that we "run" when we want to solve problems or make decisions. Some people use certain PBSRs that allow them to make their decisions using "external references". That is, they seek information from the outside world. They want to know what others think, what others have experienced. Other people use PBSRs that rely instead on their own "internal experience" to decide. They rely on an "internally referenced" program to make a decision. And some people use a combination of both and in different order.
Does this has to do with management?
What does this have to do with technical management and with motivation? Actually, everything. Whether we are talking about your technical customer, your boss, your direct reports, or your colleagues, each person makes decisions using data from a specific set of sources and by a specific set of processes. People also use these processes (their PBSRs) to either be motivated to do something or to not do it. People either gather data from certain types of external sources or they use their own internal source and / or some combination of both, but the process is predictable.
And here is the significant point; if a person can't get the information the way they want it (i.e., either internally or externally referenced in the way they want it) then they won't make the decision or they won't be motivated. As in the examples of my camera and kayak purchases, if I had been unable to get the internally referenced information, I would not have made the decision. In your business world, if your boss, your colleagues, or your customer, can't get their information the way they want it, they won't make the decision they and you want them to make. This means that if you don't motivate someone according to their "motivation" Personal Behavioral Sub-Routine they won't get motivated. It's that simple and that subtle.
Therefore, what makes this so important for management is that if you attempt to convince a person by using a strategy that doesn't match theirs, one that doesn't match their PBSRs, you will frustrate them and they will resist your influence.
My basic premise in management is that everyone is doing what they think is best at the time. Therefore, if someone is resisting you it's not because they want to be difficult. It's probably because they truly believe that they are doing what is best for them, for the company, and for the task. If this assumption is true then it is your responsibility, the person who is trying to motivate them, to change your motivation strategy to fit what they need to see, hear, and know in order to be motivated. In reality, this is the way it works all the time, even if you don't know it on a conscious level. Everyone is motivated to do anything; have dinner with you; take your direction; vote for a presidential candidate; like a specific song; all because the communication and the data they receive resonates and matches the data they want in the way they want it.
Some Examples: Let's take several examples. Let's say you have a client to whom you are trying to sell your product. If your client is internally referenced they will want a personal experience of your product or service, or they'll want to understand the subject for themselves. If you keep offering them the names and phone numbers of your other satisfied customers for them to contact, you are giving them external references. That's not what they want and they will become frustrated. They want to experience and understand your product for themselves.
On the other hand, if your client is externally referenced, they will want to talk to others who have used your services or your product. If you attempt to give them a direct experience of your service or product, or if you keep explaining your product to them you will frustrate them as well. They are being externally referenced and you are feeding them internally referenced information.
This is also be important when motivating people. If you are managing an internally referenced employee, you will frustrate them by giving them too much direction. You'll be thinking that you are helping them and they'll be thinking, "Just let me start. I'll figure it out once I get into it."
However, an externally referenced employee will want to know everything you can tell them about the task before they start. They'll take the position, "There's no use reinventing the wheel. I might as well get as much information as possible before I start."
Without understanding these two differences, you may be communicating in ways that make your desired outcome harder to achieve. Imagine giving too much guidance to an internally referenced employee or giving too little to an externally referenced employee.
You'll also find that highly externally referenced people want to have meetings with all the potentially affected departments before making a major decision. Whereas highly internally referenced people make decisions on their own, and then wonder why other departments are so upset for not being included.
Imagine putting a highly externally referenced person on a team with a highly internally referenced person and making them relatively equal in power and authority. (This is exactly what happened in one major company I was working with.) The internally referenced person will want to move forward based on their internal understanding of what they believe is right. The externally referenced person will want to talk to all potentially affected people and departments and then make the decision. The internally referenced person will think that the externally referenced person is incapable of making a decision, and the externally referenced person will think the internally referenced person "shoots from the hip" and is not a team player.
The bottom line is that if you attempt to influence in a way that is not aligned with the way a person makes decisions, you will often frustrate them and therefore, fail to influence them. This may not be because your argument is weak, or because you haven't enough information. It may be because you've packaged your message in a way that is counter to the way the listener wants to receive it.
Those of you who are more externally referenced will want to read more about this topic.
Those of you who are more internally referenced are probably wondering what your own PBSRs and strategies are.
Which approach feels better to you?
Both Win
A manager wants "both sides to win". Management is about judgment and often right or wrong doesn't exist as a black or white condition.
be well,
Dwika-ExecuTrain
The Answer to Last Month's Case Study #2
**Steven Cerri
(10 minute read)
I was the general manager of a corporate division office. Our company developed large software systems. I had four program managers reporting to me, each with a program worth between $3 and $5 million. Bob was one of those program managers.
I arrived at work one Monday morning at 8:00am. By 8:01am every member of the finance department was lined up outside my office complaining that someone had stolen all their PC's right off their desks.
The first question I asked was, "Had we been robbed?" By 8:15am we knew the answer. No robbery had occurred. The PCs weren't taken from the building, they had just been moved. All the PCs from the finance department had been found on the desks of Bob's engineering team. Bob's team was made up of 15 system analysts and programmers working on a 2-year program worth about $3.5 million.
I instructed the financial staff to leave the computers on the engineer's desks for now, until we could figure out exactly what happened. The financial staff was understandably ready to tar and feather Bob, while my job was to keep everybody calm. Without any real information, my goal was to make sure everybody remained calm and didn't come to their own conclusions.
By 8:30am Bob had arrived at the office, but none of his team had yet arrived. When Bob arrived I asked to see him in my office, alone. "What the heck happened, Bob?" I didn't yell it out, I just said it with emphasis on the word "What".
Bob calmly explained that his team had committed to the customer that a specific deliverable would be in the customer's hands by Monday morning. The team decided the only way to get it done was to work through the weekend. By Saturday afternoon they realized they were not going to get it done unless they had more computing power. So they took the computers off the desks of the finance department. They worked through Sunday and late into Sunday night and got the product delivered to the customer on time, Monday morning. When they left Sunday evening they were just too tired to put the PCs back on the desks of the financial staff. So Monday morning when the financial staff arrived they found no messages, no thank-you notes, no explanations, and no computers.
Bob's team had worked hard, and had delivered the product to the customer on time. The financial staff was upset but the customer was happy.
There you have the case. What would you do? Would you chastise Bob for not anticipating the problem and tell him he should have foreseen the problem? Would you praise him for getting the product to the customer on time regardless of the consequences to the staff?
Would you tell the financial staff to "just forget about it", or "get over it"? Would you stay out of it and let Bob and his team and the financial department solve their own issue to get past this? Would you get in the middle of this situation or stay out? What would you have told Bob? What would you have told the financial team?
- - - - - -My Response- - - - - - - - - - - - - - - - - - -
I told Bob about the situation he had placed me in. I honestly told him that I was in a quandary; on the one hand, I liked the fact that he took initiative to satisfy the customers' needs and his teams' commitment to deliver the software on schedule. On the other hand, he couldn't just take actions without attempting to smooth out the implications of those actions.
I asked him what he could have done to make things smoother. He said he could have called me to tell me what he wanted to do. I said, "True, but suppose you couldn't reach me, then what would you do?" He then said that he could have called the manager of the finance department. I then said, "True, but suppose you couldn't reach anyone from the finance department, then what?" He didn't have an answer.
I then said, "Bob lets make this simple. If you can't return everyone's computer before you and your team leave the building, then you leave a note on each desk from which you've taken a computer and you come in first thing in the morning and meet the finance people as they arrive and you make it right. It's not a big deal to make this effort. He understood and agreed.
I then told him that I did expect him to meet individually with each person in the finance department and explain and apologize for not returning the computers promptly.
I then met with all the finance department and explained what I had told Bob. I told the finance department that in fact we should all be appreciative that Bob and his team took the initiative on behave of the company and the customer, but we should at least hold Bob's feet to the fire for not communicating it better. They understood that Bob did the right thing but he just should have taken one more step in the communication process.
Bob apologized to each finance member (remember not for taking the computers but for not communicating better), the finance people understood and accepted Bob's apology, and by the end of the day, it was all forgotten. Piece of cake!
Some managers would have taken a side. Bob was right or Bob was wrong. Management is about judgment and often right or wrong doesn't exist as a black or white condition. Sometimes a manager wants "both sides to win". This was one of those situations.
be well,
Dwika-ExecuTrain
The Answer to Last Month's Case Study #2
**Steven Cerri
(10 minute read)
I was the general manager of a corporate division office. Our company developed large software systems. I had four program managers reporting to me, each with a program worth between $3 and $5 million. Bob was one of those program managers.
I arrived at work one Monday morning at 8:00am. By 8:01am every member of the finance department was lined up outside my office complaining that someone had stolen all their PC's right off their desks.
The first question I asked was, "Had we been robbed?" By 8:15am we knew the answer. No robbery had occurred. The PCs weren't taken from the building, they had just been moved. All the PCs from the finance department had been found on the desks of Bob's engineering team. Bob's team was made up of 15 system analysts and programmers working on a 2-year program worth about $3.5 million.
I instructed the financial staff to leave the computers on the engineer's desks for now, until we could figure out exactly what happened. The financial staff was understandably ready to tar and feather Bob, while my job was to keep everybody calm. Without any real information, my goal was to make sure everybody remained calm and didn't come to their own conclusions.
By 8:30am Bob had arrived at the office, but none of his team had yet arrived. When Bob arrived I asked to see him in my office, alone. "What the heck happened, Bob?" I didn't yell it out, I just said it with emphasis on the word "What".
Bob calmly explained that his team had committed to the customer that a specific deliverable would be in the customer's hands by Monday morning. The team decided the only way to get it done was to work through the weekend. By Saturday afternoon they realized they were not going to get it done unless they had more computing power. So they took the computers off the desks of the finance department. They worked through Sunday and late into Sunday night and got the product delivered to the customer on time, Monday morning. When they left Sunday evening they were just too tired to put the PCs back on the desks of the financial staff. So Monday morning when the financial staff arrived they found no messages, no thank-you notes, no explanations, and no computers.
Bob's team had worked hard, and had delivered the product to the customer on time. The financial staff was upset but the customer was happy.
There you have the case. What would you do? Would you chastise Bob for not anticipating the problem and tell him he should have foreseen the problem? Would you praise him for getting the product to the customer on time regardless of the consequences to the staff?
Would you tell the financial staff to "just forget about it", or "get over it"? Would you stay out of it and let Bob and his team and the financial department solve their own issue to get past this? Would you get in the middle of this situation or stay out? What would you have told Bob? What would you have told the financial team?
- - - - - -My Response- - - - - - - - - - - - - - - - - - -
I told Bob about the situation he had placed me in. I honestly told him that I was in a quandary; on the one hand, I liked the fact that he took initiative to satisfy the customers' needs and his teams' commitment to deliver the software on schedule. On the other hand, he couldn't just take actions without attempting to smooth out the implications of those actions.
I asked him what he could have done to make things smoother. He said he could have called me to tell me what he wanted to do. I said, "True, but suppose you couldn't reach me, then what would you do?" He then said that he could have called the manager of the finance department. I then said, "True, but suppose you couldn't reach anyone from the finance department, then what?" He didn't have an answer.
I then said, "Bob lets make this simple. If you can't return everyone's computer before you and your team leave the building, then you leave a note on each desk from which you've taken a computer and you come in first thing in the morning and meet the finance people as they arrive and you make it right. It's not a big deal to make this effort. He understood and agreed.
I then told him that I did expect him to meet individually with each person in the finance department and explain and apologize for not returning the computers promptly.
I then met with all the finance department and explained what I had told Bob. I told the finance department that in fact we should all be appreciative that Bob and his team took the initiative on behave of the company and the customer, but we should at least hold Bob's feet to the fire for not communicating it better. They understood that Bob did the right thing but he just should have taken one more step in the communication process.
Bob apologized to each finance member (remember not for taking the computers but for not communicating better), the finance people understood and accepted Bob's apology, and by the end of the day, it was all forgotten. Piece of cake!
Some managers would have taken a side. Bob was right or Bob was wrong. Management is about judgment and often right or wrong doesn't exist as a black or white condition. Sometimes a manager wants "both sides to win". This was one of those situations.
Most Meetings
A reasonable question is how does a leader deal with a something missing situation in a meeting. The answer is by not dealing with it at all, but rather setting a stage of thinking and a set of beliefs that make this bickering absolutely out of place.
be well,
Dwika-ExecuTrain
Something Is Missing From Most Meetings!
by: Steven Cerri
(10 minute read)
I want to talk to you about meetings.
People often complain about meetings. "Too many meetings." "Out meetings don't accomplish anything." "I don't understand why I have to attend these meetings?"
The interesting thing is that the people who often complain about meetings are the attendees. Seldom do we hear the people who convene the meetings being the people who complain about meetings.
So right here I want to talk to the people who convene meetings. This means everyone up and down the chain from the CEO to the floor supervisor. If you convene meetings ever, this is for you!
First, I'm not going to talk about how to make meetings efficient. While I have my own process which makes meetings efficient, there a plenty of models out there that you can learn that, IF YOU FOLLOW THEM, will make your meetings efficient and effective.
Here I want to talk to you about some that very few people use meetings for. It's the very seldom used key, not to effective meetings, but to effective management.
You see, meetings often have a management component to them. The person who is calling the meeting is often attempting to "manage something". But 99% of the time they miss an opportunity that would make management easier and more effective. And here it is.
Most managers do not use the meeting to reinforce the behaviors, the beliefs, the values, and the focus of attention they want people to display. Most meeting managers focus on the "problems" but they miss the opportunity to reinforce what they want.
For example. Say you are having a meeting and Susan has delivered a product to another department on time and on schedule. Most managers would probably praise Susan for delivering the product on time and on schedule, or they should. But suppose Susan delivered that product to a department that has a reputation for being difficult to deal with. Suppose Susan spent some time establishing a smooth relationship, perhaps the only smooth relationship in existence with that department, and no one really paid much attention to that fact, but the manager knows that is did occur. This is a perfect opportunity for the manager to say something like: "I want to point out something that might go unnoticed. Department X has a reputation for being difficult to work with. You all know that. However, Susan spent some time up front building a relationship with person Y in that department and when she delivered the product the acceptance process went very smoothly. In fact, got a phone call from that department's manager telling me how effective Susan was in the process. Now this is a behavior and a philosophy I want us to display. I think it is really important that we establish positive working relationships with other departments, even those that, at first glance, we wouldn't want to. Susan has set the kind of example that I want all of us to aspire to. To be able to build positive working bridges between ourselves and others in this company."
Notice, this message is telling the team not just how to behave but also how to view the world, how to think about the world. Many managers and meeting leaders focus on problem solving, and at most, focus on the behaviors they want by praising those behaviors they want more of. However, action is the result of thoughts, beliefs, and a focus of attention on specific aspects of the world. Therefore, an important component of meetings is often missed when the leader fails to talk about the beliefs, values, attitudes, relationships, and view of the world that he or she wants the meeting participants to display.
Here is an example. Many engineers fight for their ideas. They fight to be right. Therefore, it's not uncommon for a meeting filled with engineers and technologists to degenerate into nit-picking over technical issues. One person defending some arcane position while another discounts it and postulates his or her own. A reasonable question is how does a meeting leader deal with a situation like this.
The answer is by not dealing with it at all, but rather setting a stage of thinking and a set of beliefs that make this bickering absolutely out of place. The way I did it is that if I had an inkling that because I had a room filled with technical professionals and engineers I might have a nit-picking session I would start the meeting off with the following statement. "All right, as you can see we have a variety of technologies represented at this meeting and the goal today is to come up with some ideas and maybe the best idea as a solution to our current situation. My philosophy is that our goal is to put all the ideas on the table. You may have the idea and once it's one the table, it no longer your idea, the idea now belongs to the group. And as we work with each idea my position is that the best idea will actually become evident to all of us. Once the idea is on the table there is no need to defend it. It stands or falls on it's own merit and as we add to it and take away from it, by the end of the day, it should be evident to all of us that one idea stands out as the best, the most efficient, whatever the important parameters are, one or maybe two will be at the top of everybody's list. That is what I want us to accomplish today at this meeting."
With that introduction the stage is set for a good, honest, intense exchange, without personal ownership of any single idea taking over the meeting.
Be well,
be well,
Dwika-ExecuTrain
Something Is Missing From Most Meetings!
by: Steven Cerri
(10 minute read)
I want to talk to you about meetings.
People often complain about meetings. "Too many meetings." "Out meetings don't accomplish anything." "I don't understand why I have to attend these meetings?"
The interesting thing is that the people who often complain about meetings are the attendees. Seldom do we hear the people who convene the meetings being the people who complain about meetings.
So right here I want to talk to the people who convene meetings. This means everyone up and down the chain from the CEO to the floor supervisor. If you convene meetings ever, this is for you!
First, I'm not going to talk about how to make meetings efficient. While I have my own process which makes meetings efficient, there a plenty of models out there that you can learn that, IF YOU FOLLOW THEM, will make your meetings efficient and effective.
Here I want to talk to you about some that very few people use meetings for. It's the very seldom used key, not to effective meetings, but to effective management.
You see, meetings often have a management component to them. The person who is calling the meeting is often attempting to "manage something". But 99% of the time they miss an opportunity that would make management easier and more effective. And here it is.
Most managers do not use the meeting to reinforce the behaviors, the beliefs, the values, and the focus of attention they want people to display. Most meeting managers focus on the "problems" but they miss the opportunity to reinforce what they want.
For example. Say you are having a meeting and Susan has delivered a product to another department on time and on schedule. Most managers would probably praise Susan for delivering the product on time and on schedule, or they should. But suppose Susan delivered that product to a department that has a reputation for being difficult to deal with. Suppose Susan spent some time establishing a smooth relationship, perhaps the only smooth relationship in existence with that department, and no one really paid much attention to that fact, but the manager knows that is did occur. This is a perfect opportunity for the manager to say something like: "I want to point out something that might go unnoticed. Department X has a reputation for being difficult to work with. You all know that. However, Susan spent some time up front building a relationship with person Y in that department and when she delivered the product the acceptance process went very smoothly. In fact, got a phone call from that department's manager telling me how effective Susan was in the process. Now this is a behavior and a philosophy I want us to display. I think it is really important that we establish positive working relationships with other departments, even those that, at first glance, we wouldn't want to. Susan has set the kind of example that I want all of us to aspire to. To be able to build positive working bridges between ourselves and others in this company."
Notice, this message is telling the team not just how to behave but also how to view the world, how to think about the world. Many managers and meeting leaders focus on problem solving, and at most, focus on the behaviors they want by praising those behaviors they want more of. However, action is the result of thoughts, beliefs, and a focus of attention on specific aspects of the world. Therefore, an important component of meetings is often missed when the leader fails to talk about the beliefs, values, attitudes, relationships, and view of the world that he or she wants the meeting participants to display.
Here is an example. Many engineers fight for their ideas. They fight to be right. Therefore, it's not uncommon for a meeting filled with engineers and technologists to degenerate into nit-picking over technical issues. One person defending some arcane position while another discounts it and postulates his or her own. A reasonable question is how does a meeting leader deal with a situation like this.
The answer is by not dealing with it at all, but rather setting a stage of thinking and a set of beliefs that make this bickering absolutely out of place. The way I did it is that if I had an inkling that because I had a room filled with technical professionals and engineers I might have a nit-picking session I would start the meeting off with the following statement. "All right, as you can see we have a variety of technologies represented at this meeting and the goal today is to come up with some ideas and maybe the best idea as a solution to our current situation. My philosophy is that our goal is to put all the ideas on the table. You may have the idea and once it's one the table, it no longer your idea, the idea now belongs to the group. And as we work with each idea my position is that the best idea will actually become evident to all of us. Once the idea is on the table there is no need to defend it. It stands or falls on it's own merit and as we add to it and take away from it, by the end of the day, it should be evident to all of us that one idea stands out as the best, the most efficient, whatever the important parameters are, one or maybe two will be at the top of everybody's list. That is what I want us to accomplish today at this meeting."
With that introduction the stage is set for a good, honest, intense exchange, without personal ownership of any single idea taking over the meeting.
Be well,
Trust
Whatever the situation, when a manager lays out this thought process to a direct report, and explains the management style selection process, and emphasizes that trust is not the driver, but the situation, the "context" is, the concern for "trust me by leaving me alone" just disappears. It has always worked.
be well,
Dwika-ExecuTrain
Article #1: "Trust Is A Big Deal."
by: Steven Cerri
(10 minute read)
I gave a presentation at the San Francisco chapter of the American Institute of Aeronautics and Astronautics (AIAA) last week on the 10 Pitfalls that can keep engineers and technical professionals from advancing up the technology management ladder. During the presentation I mentioned the word "trust" and I tend to down play the importance of trust in management, much to the surprise of many. I'd rather play up the need and use of open and frequent communication as a management tool instead of trust.
The reason for this is that many engineers equate trust with "leave me alone to do my work". Well, as much as managers might like to leave some direct reports alone to succeed, there are plenty of direct reports, who if left alone, will do the opposite. So I resist the idea of, "If my manager trusts me, he or she will leave me alone to do my work and not hound me, or ask for status reports every week, or ask for a project review once a month. Just let me do my work and I'll come back with the finished product."
In my presentation I made the statement that I don't put much attention on "trust". In fact, I focus on communication and I think trust is overrated.
A few minutes after this statement an audience member asked me a question. The question essentially was, "Do you really think that trust is not very important? Don't you think that people want to feel trusted? I know people want to feel trusted in their work environment."
My response was essentially something like this: "I sometimes make statements that are a little provocative to make a point, and my statement about trust was such a statement. However, my point is that people often equate trust with "blind trust". If you trust me you'll leave me alone. I know we all want to be trusted. I want to be trusted. But what does being trusted mean? If it means leave me alone, it won't work."
I then went on to indicate that there were seven parameters that I have developed through my career that I use to determine what management style I will use in a given situation. They include:
1. Where the expertise resides, with the direct report or with the manager or somewhere else
2. The risk of the task or project
3. The timeframe of the task or project.
etc. to the 7th parameter.
I then went on to show that depending on the parameter and depending on the answer to the question regarding the parameter, I might be driven to select a different management style than might be expected. For example, if the project was a high risk project, that would lead me to manage more tightly than if the project were very low risk. And in this way, I evaluate the seven parameters and emerge with a management style for success in that "context".
That was essentially my answer. And yet I thought more about it on the drive home. The next day I realized that there was another piece to this explanation that I had not included that I'd now like to include and here it is.
If we look at the seven parameters I call "Contextual Definition" which comprise the assessment of the management situation, we find that of the seven parameters only one, I repeat, only one pertains to the direct report. That parameter is the "location" of the expertise. Does the expertise lie with the direct report or with the manager? Once again, this is the only parameter that relates to the the direct report and therefore, it is the only parameter that relates to "trust".
What I'm saying is that when I assess a situation in order to determine what the best management style is for success, only one of seven variables I'm taking into account has anything to do with trusting the direct report. The other six parameters have more to do with the cold, hard facts of the project or task. From this perspective, it becomes obvious that trust and therefore, the management style based on trust, i.e., "leave me alone to do my work" can end up far down the list of priorities in determining the optimum management style. And in fact, when the direct report understands this, micromanagement and any concern for "trust" actually disappears.
Here is a perfect example. The night I gave my presentation, I sat at a table with several other members. One colleague I knew was preparing to move from full-time employment to part-time employment. He was moving into semi-retirement. I asked him if his move to semi-retirement was on schedule and he said that it was a little behind, but it was indeed moving forward. Now this man is what I would call a technical manager. He is a manager but is also up on the technology enough to be able to add value not only from the management perspective but also from the technical perspective.
I asked him if he had found his replacement yet and he indicated that he had and he was in fact, presently training him. I incorrectly assumed that the new manager would be a younger person and so I asked, "How old is your replacement?" My friend responded that his replacement was in his "early to mid-fifties". He then went on to say that this new manager that he was training was a seasoned manager but didn't know the department and the technology that well, and so the departing manager, my colleague, was training the new manager in these areas.
Now how do we interpret this situation and the explanation? I think there are several possible interpretations as follows:
1. The new manager could feel micromanaged because, come on, this is a seasoned manager. He can certainly be left alone to figure out the department and come up to speed on the technology. Why does he need to be "trained" by the outgoing manager?
2. The new manager could feel grateful because he doesn't understand the department and the technology all that well yet, and any help would be appreciated.
3. Or, my colleague could be applying absolutely the best management approach because the situation calls for it as follows:
a. Were is the expertise? It is with my colleague. The new manager is not the expert in the department nor the technology. Therefore, close management supervision is absolutely what is called for. (By the way, this is the only parameter of the seven that anything to do with trust.)
b. What is the risk? The risk is relatively high. Putting a new person in this position could jeopardize current projects. Therefore, close management supervision initially is absolutely what is called for.
c. What is the timeframe? Well, my colleague is already behind his schedule to move to part-time. The sooner this new manager comes up to speed, the better. Therefore, close management supervision is absolutely what is called for.
The other four parameters likewise call for close supervision or are at the least, neutral. Therefore, the most effective management approach is the one my colleague is currently using. Now I don't know if he explained his thought processes to the new manager, or if he even went through this thought process. He may just have a gut sense of what to do. And in fact, the two managers may both be good enough to understand with a few words that this is the best approach. Whatever the situation, when a manager lays out this thought process to a direct report, and explains the management style selection process, and emphasizes that trust is not the driver, but the situation, the "context" is, the concern for "trust me by leaving me alone" just disappears. I've used this approach over and over and it always, and I mean always, works. I've coached people in the specific use of this approach in their situations and it has always worked, so far....
This then is why I say, "I just don't focus much on the trust issue".
Be well,
Steven
be well,
Dwika-ExecuTrain
Article #1: "Trust Is A Big Deal."
by: Steven Cerri
(10 minute read)
I gave a presentation at the San Francisco chapter of the American Institute of Aeronautics and Astronautics (AIAA) last week on the 10 Pitfalls that can keep engineers and technical professionals from advancing up the technology management ladder. During the presentation I mentioned the word "trust" and I tend to down play the importance of trust in management, much to the surprise of many. I'd rather play up the need and use of open and frequent communication as a management tool instead of trust.
The reason for this is that many engineers equate trust with "leave me alone to do my work". Well, as much as managers might like to leave some direct reports alone to succeed, there are plenty of direct reports, who if left alone, will do the opposite. So I resist the idea of, "If my manager trusts me, he or she will leave me alone to do my work and not hound me, or ask for status reports every week, or ask for a project review once a month. Just let me do my work and I'll come back with the finished product."
In my presentation I made the statement that I don't put much attention on "trust". In fact, I focus on communication and I think trust is overrated.
A few minutes after this statement an audience member asked me a question. The question essentially was, "Do you really think that trust is not very important? Don't you think that people want to feel trusted? I know people want to feel trusted in their work environment."
My response was essentially something like this: "I sometimes make statements that are a little provocative to make a point, and my statement about trust was such a statement. However, my point is that people often equate trust with "blind trust". If you trust me you'll leave me alone. I know we all want to be trusted. I want to be trusted. But what does being trusted mean? If it means leave me alone, it won't work."
I then went on to indicate that there were seven parameters that I have developed through my career that I use to determine what management style I will use in a given situation. They include:
1. Where the expertise resides, with the direct report or with the manager or somewhere else
2. The risk of the task or project
3. The timeframe of the task or project.
etc. to the 7th parameter.
I then went on to show that depending on the parameter and depending on the answer to the question regarding the parameter, I might be driven to select a different management style than might be expected. For example, if the project was a high risk project, that would lead me to manage more tightly than if the project were very low risk. And in this way, I evaluate the seven parameters and emerge with a management style for success in that "context".
That was essentially my answer. And yet I thought more about it on the drive home. The next day I realized that there was another piece to this explanation that I had not included that I'd now like to include and here it is.
If we look at the seven parameters I call "Contextual Definition" which comprise the assessment of the management situation, we find that of the seven parameters only one, I repeat, only one pertains to the direct report. That parameter is the "location" of the expertise. Does the expertise lie with the direct report or with the manager? Once again, this is the only parameter that relates to the the direct report and therefore, it is the only parameter that relates to "trust".
What I'm saying is that when I assess a situation in order to determine what the best management style is for success, only one of seven variables I'm taking into account has anything to do with trusting the direct report. The other six parameters have more to do with the cold, hard facts of the project or task. From this perspective, it becomes obvious that trust and therefore, the management style based on trust, i.e., "leave me alone to do my work" can end up far down the list of priorities in determining the optimum management style. And in fact, when the direct report understands this, micromanagement and any concern for "trust" actually disappears.
Here is a perfect example. The night I gave my presentation, I sat at a table with several other members. One colleague I knew was preparing to move from full-time employment to part-time employment. He was moving into semi-retirement. I asked him if his move to semi-retirement was on schedule and he said that it was a little behind, but it was indeed moving forward. Now this man is what I would call a technical manager. He is a manager but is also up on the technology enough to be able to add value not only from the management perspective but also from the technical perspective.
I asked him if he had found his replacement yet and he indicated that he had and he was in fact, presently training him. I incorrectly assumed that the new manager would be a younger person and so I asked, "How old is your replacement?" My friend responded that his replacement was in his "early to mid-fifties". He then went on to say that this new manager that he was training was a seasoned manager but didn't know the department and the technology that well, and so the departing manager, my colleague, was training the new manager in these areas.
Now how do we interpret this situation and the explanation? I think there are several possible interpretations as follows:
1. The new manager could feel micromanaged because, come on, this is a seasoned manager. He can certainly be left alone to figure out the department and come up to speed on the technology. Why does he need to be "trained" by the outgoing manager?
2. The new manager could feel grateful because he doesn't understand the department and the technology all that well yet, and any help would be appreciated.
3. Or, my colleague could be applying absolutely the best management approach because the situation calls for it as follows:
a. Were is the expertise? It is with my colleague. The new manager is not the expert in the department nor the technology. Therefore, close management supervision is absolutely what is called for. (By the way, this is the only parameter of the seven that anything to do with trust.)
b. What is the risk? The risk is relatively high. Putting a new person in this position could jeopardize current projects. Therefore, close management supervision initially is absolutely what is called for.
c. What is the timeframe? Well, my colleague is already behind his schedule to move to part-time. The sooner this new manager comes up to speed, the better. Therefore, close management supervision is absolutely what is called for.
The other four parameters likewise call for close supervision or are at the least, neutral. Therefore, the most effective management approach is the one my colleague is currently using. Now I don't know if he explained his thought processes to the new manager, or if he even went through this thought process. He may just have a gut sense of what to do. And in fact, the two managers may both be good enough to understand with a few words that this is the best approach. Whatever the situation, when a manager lays out this thought process to a direct report, and explains the management style selection process, and emphasizes that trust is not the driver, but the situation, the "context" is, the concern for "trust me by leaving me alone" just disappears. I've used this approach over and over and it always, and I mean always, works. I've coached people in the specific use of this approach in their situations and it has always worked, so far....
This then is why I say, "I just don't focus much on the trust issue".
Be well,
Steven
Great working relationships
Managers who want to establish great working relationships with their direct reports. It can be done. It is easy if you know where and how to tap.
be well,
Dwika-ExecuTrain
How Easy Is All This?
by : Steven Cerri
(10 minute read)
As you read my blogs and my Newsletters/E-zines, you might be thinking, "Oh sure. You say it as if it's so easy, but what I want to know Steven is, How easy is it to keep my manager from micromanaging me? How easy is it for me, a direct report, to control my managers' perception and behavior. It's got to be easier said than done."
Well, those are important questions and I'm sure many of you are wondering the same thing. Well, my answer is that it is very easy to manage your managers' behavior if you know what to do and how to do it.
It's very much like the story of the ship that had a problem with its steam engine. You may have heard this story before but it bears repeating in this instance.
There was a ship that was in the harbor and it was discovered that it's steam engine wasn't working. No one seemed to know what to do to get it to work. "Expert" after "Expert" was brought in and none of them knew what to do to fix it.
Finally, the owner of the ship hired an old man who specialized in steam engines. He looked over the steam engine, put his ear against the boiler here and there, then in one spot on the steam engine he used his hammer and gave it a "tap". The steam engine fired up and began to work perfectly.
The old man presented the owner with a bill for $10,000. The owner was flabbergasted. "How can you present me with a bill of $10,000. You just gave the steam engine a little tap with your hammer and you want $10,000 for that?"
The old man replied, "It's $500 for the tap and $9,500 for knowing where and how to tap."
The same applies to what I've been talking about with micromanagement and managing your manager. Let me give you an example.
Several months back, I was having dinner with a prospective client. In casual conversation she was bemoaning her manager's behavior. She indicated that he didn't give her independence. He wasn't really allowing her to contribute the way she could. He wasn't taking her advice in areas where she had significant experience compared to everyone else in the office. And with the economy beginning to affect her company's revenues, she feared the situation would only get more intense and more restrictive. She feared she would not get a good review which was coming up and things seemed gloomy as far as she was concerned.
So I gave her specific suggestions. I explained a new way for her to think about her manager. I explained a new way for her to think about his motives. Then I gave her specific behaviors to exhibit. I explained how to talk to her manager. What to say. Questions to ask. I gave her new ways to be in partnership with her manager; ways to behave that would allow him to recognize that she was indeed attempting to help the organization and him. And we continued to have an enjoyable dinner.
She apparently went back and implemented my suggestions. The results of which are as follows:
1. Her relationship with her manager has changed completely and changed for the better.
2. He did conduct her performance review, and he gave her the highest rating possible and the highest pay raise allowed.
3. He has given her much more autonomy resulting in her proposing a new program for the group.
The point of this case is that working effectively with your manager doesn't take a miracle. It's takes knowledge and a willingness to be flexible enough to implement that knowledge.
And, by the way, the same applies to managers who want to establish great working relationships with their direct reports. It can be done. It is easy... if you know where and how to tap.
Be well,
Steven
be well,
Dwika-ExecuTrain
How Easy Is All This?
by : Steven Cerri
(10 minute read)
As you read my blogs and my Newsletters/E-zines, you might be thinking, "Oh sure. You say it as if it's so easy, but what I want to know Steven is, How easy is it to keep my manager from micromanaging me? How easy is it for me, a direct report, to control my managers' perception and behavior. It's got to be easier said than done."
Well, those are important questions and I'm sure many of you are wondering the same thing. Well, my answer is that it is very easy to manage your managers' behavior if you know what to do and how to do it.
It's very much like the story of the ship that had a problem with its steam engine. You may have heard this story before but it bears repeating in this instance.
There was a ship that was in the harbor and it was discovered that it's steam engine wasn't working. No one seemed to know what to do to get it to work. "Expert" after "Expert" was brought in and none of them knew what to do to fix it.
Finally, the owner of the ship hired an old man who specialized in steam engines. He looked over the steam engine, put his ear against the boiler here and there, then in one spot on the steam engine he used his hammer and gave it a "tap". The steam engine fired up and began to work perfectly.
The old man presented the owner with a bill for $10,000. The owner was flabbergasted. "How can you present me with a bill of $10,000. You just gave the steam engine a little tap with your hammer and you want $10,000 for that?"
The old man replied, "It's $500 for the tap and $9,500 for knowing where and how to tap."
The same applies to what I've been talking about with micromanagement and managing your manager. Let me give you an example.
Several months back, I was having dinner with a prospective client. In casual conversation she was bemoaning her manager's behavior. She indicated that he didn't give her independence. He wasn't really allowing her to contribute the way she could. He wasn't taking her advice in areas where she had significant experience compared to everyone else in the office. And with the economy beginning to affect her company's revenues, she feared the situation would only get more intense and more restrictive. She feared she would not get a good review which was coming up and things seemed gloomy as far as she was concerned.
So I gave her specific suggestions. I explained a new way for her to think about her manager. I explained a new way for her to think about his motives. Then I gave her specific behaviors to exhibit. I explained how to talk to her manager. What to say. Questions to ask. I gave her new ways to be in partnership with her manager; ways to behave that would allow him to recognize that she was indeed attempting to help the organization and him. And we continued to have an enjoyable dinner.
She apparently went back and implemented my suggestions. The results of which are as follows:
1. Her relationship with her manager has changed completely and changed for the better.
2. He did conduct her performance review, and he gave her the highest rating possible and the highest pay raise allowed.
3. He has given her much more autonomy resulting in her proposing a new program for the group.
The point of this case is that working effectively with your manager doesn't take a miracle. It's takes knowledge and a willingness to be flexible enough to implement that knowledge.
And, by the way, the same applies to managers who want to establish great working relationships with their direct reports. It can be done. It is easy... if you know where and how to tap.
Be well,
Steven
Supportive and concerned manager
One person's micromanagement is another person's supportive and concerned manager. One person's concerned and supportive manager is another person's over-bearing, overly-controlling manager.
be well,
Dwika-ExecuTrain
"Micromanagement seems to be everywhere!"
by: Steven Cerri
(10 minute read)
Did you every purchase a new car and all of a sudden you see your make, model, and color car on the road everywhere. Now that you have one, it seems so does everyone else.
Well, the same phenomenon has occurred with me and the topic of "micromanagement". Now that I've completed my 3-CD set titled "Succeeding Without Micromanagement", it seems that everyone I talk to is complaining about being micromanaged or is concerned about being perceived as a micromanager.
So since it seems like such a common phenomenon, I'm going to devote this issue to micromanagement and I'm going to give you some concrete ways to avoid it.
Let's begin with a discussion of what micromanagement looks like, The primary questions are; "How do you know when you are micromanaged?" What's the evidence in your mind that you are being micromanaged?"
1. Is it because your manager calls you every day?
2. Is it because you manager calls you three times a day?
3. Is it that your manager wants to know at 8 in the morning what you intend to accomplish by the end of the day, and at the end of the day wants to know what you did accomplish?
4. Is it that your manager wants a weekly status report by close of business on Friday for the previous week?
5. Is it that your manager wants a plan, schedule, and budget before your begin your project.
6. Is it that your manager wants a monthly status meeting regarding your progress?
What is clear in my mind is that micromanagement is always very, very personal. What sets off your button regarding micromanagement may not set off mine, or may not set of the other people on your team.
Micromanagement is personal.
That's the first principle I want to convey. Micromanagement is very personal it is not the same for everyone.
In fact, I coach direct reports and managers who are upset that their managers don't manage them "close enough or often enough". They are actually complaining to me that they are not be managed ENOUGH!
So it's very important to get clear that....
One person's micromanagement is another person's supportive and concerned manager. One person's concerned and supportive manager is another person's over-bearing, overly-controlling manager.
Therefore, micromanagement doesn't have a "general" or "universal" definition. It doesn't have a baseline behavior that defines it. So if you are going to talk about it, be clear about exactly what you mean.
This leads us to the very critical point. This is the biggest fact about micromanagement... micromanagement is all about the structure of the relationship between the direct report and the manager. That is the key. Micromanagement is in the relationship.
If you are a manager and you want to avoid being a micromanager, then you must structure a manager-direct report relationship that is the right mix of management and freedom based on you, the manager, the direct report, and the situation.
And here is the "kicker".... very often when I'm coaching engineers and technical professionals who think they are being managed too closely, I will actually coach them to give the manager what the manager wants.
The first response from the engineer is that I must be crazy. "How can giving my manager what he or she wants, all this information and reporting, get me the autonomy and freedom I seek?" That's what they usually say.
My response to that question is always the same and here it is:
I believe people are always doing the best they can. They are always attempting to do what they think is the right behavior for the situation even if you don't think so. Therefore, my approach is to assume the manager has a good intention. I don't automatically assume that the manager is a vindictive, control freak.
In fact, if we can find that "good intention" that is motivating the manager, we might be able to find a way to provide the manager with what he or she wants AND provide the engineer/direct report with the freedom and independence that he or she wants. We just might be able to find a win-win scenario.
Case in point. I'm going to share with you a case of a direct report that I coached through a difficult situation. This direct report works for a small business and has been managed relatively closely by his manager for some time. He has felt micromanaged and he complained to me that he wanted to be managed less closely. He wanted more autonomy and freedom than his manager was willing to give him and the more he attempted to get autonomy the more his manager tightened her grip and made his reporting even more onerous.
My first coaching point with this direct report was that the manager was doing this for some reason, probably legitimate in the manager's mind. So that is where we started. The direct report's task was to give the manager what she was asking for without fighting over it.
At first the direct report didn't understand how this was going to get him the autonomy he wanted. But he agreed to follow my suggestions and instructions.
He began to provide reports on the status of his tasks as the manager requested. He even suggested ways to improve the status reports.
I suggested other forms he could use to transmit data regarding the status of his tasks and projects. The manager appreciated these efforts on the part of the direct report.
After several months of this support for the manager, which by the way, turned out not to be very difficult or imposing on the direct report, the manager began to give the direct report more autonomy.
The outcome is that now the direct report and the manager have become much more of a team. The direct report is still providing the manager with the project reports but the format is streamlined and easy and doesn't take much time at all. The manager is so comfortable with the relationship that she has actually begun to manage him less closely. She actually gave him the autonomy he was originally seeking.
The direct report recently asked me, "So what happened here? How did this actually occur?"
My response was, "By giving your manager what she asked for and seeming to give up your drive for autonomy, you actually allowed the manager to be so comfortable with the communication between the two of you that she was willing to give you the autonomy you originally asked for."
By enhancing the relationship, the direct report actually reduced the level of micromanagement the manager thought she needed to feel comfortable. By "giving up the drive for autonomy, and by enhancing the manager/direct-report relationship, the direct report actually got more autonomy."
So the bottom line is that, in my experience, micromanagement is not something anyone has to live with. Engineers, scientists, and direct reports don't have to tolerate micromanagement if they understand how to set up the relationship with their manger. And managers don't have to worry about being perceived as micromanagers if they understand how to set up the relationship with their direct reports.
In my experience, micromanagement it's just not a big deal. That's why you'll often hear me say, "micromanagement doesn't really exist".
Be well,
Steven
be well,
Dwika-ExecuTrain
"Micromanagement seems to be everywhere!"
by: Steven Cerri
(10 minute read)
Did you every purchase a new car and all of a sudden you see your make, model, and color car on the road everywhere. Now that you have one, it seems so does everyone else.
Well, the same phenomenon has occurred with me and the topic of "micromanagement". Now that I've completed my 3-CD set titled "Succeeding Without Micromanagement", it seems that everyone I talk to is complaining about being micromanaged or is concerned about being perceived as a micromanager.
So since it seems like such a common phenomenon, I'm going to devote this issue to micromanagement and I'm going to give you some concrete ways to avoid it.
Let's begin with a discussion of what micromanagement looks like, The primary questions are; "How do you know when you are micromanaged?" What's the evidence in your mind that you are being micromanaged?"
1. Is it because your manager calls you every day?
2. Is it because you manager calls you three times a day?
3. Is it that your manager wants to know at 8 in the morning what you intend to accomplish by the end of the day, and at the end of the day wants to know what you did accomplish?
4. Is it that your manager wants a weekly status report by close of business on Friday for the previous week?
5. Is it that your manager wants a plan, schedule, and budget before your begin your project.
6. Is it that your manager wants a monthly status meeting regarding your progress?
What is clear in my mind is that micromanagement is always very, very personal. What sets off your button regarding micromanagement may not set off mine, or may not set of the other people on your team.
Micromanagement is personal.
That's the first principle I want to convey. Micromanagement is very personal it is not the same for everyone.
In fact, I coach direct reports and managers who are upset that their managers don't manage them "close enough or often enough". They are actually complaining to me that they are not be managed ENOUGH!
So it's very important to get clear that....
One person's micromanagement is another person's supportive and concerned manager. One person's concerned and supportive manager is another person's over-bearing, overly-controlling manager.
Therefore, micromanagement doesn't have a "general" or "universal" definition. It doesn't have a baseline behavior that defines it. So if you are going to talk about it, be clear about exactly what you mean.
This leads us to the very critical point. This is the biggest fact about micromanagement... micromanagement is all about the structure of the relationship between the direct report and the manager. That is the key. Micromanagement is in the relationship.
If you are a manager and you want to avoid being a micromanager, then you must structure a manager-direct report relationship that is the right mix of management and freedom based on you, the manager, the direct report, and the situation.
And here is the "kicker".... very often when I'm coaching engineers and technical professionals who think they are being managed too closely, I will actually coach them to give the manager what the manager wants.
The first response from the engineer is that I must be crazy. "How can giving my manager what he or she wants, all this information and reporting, get me the autonomy and freedom I seek?" That's what they usually say.
My response to that question is always the same and here it is:
I believe people are always doing the best they can. They are always attempting to do what they think is the right behavior for the situation even if you don't think so. Therefore, my approach is to assume the manager has a good intention. I don't automatically assume that the manager is a vindictive, control freak.
In fact, if we can find that "good intention" that is motivating the manager, we might be able to find a way to provide the manager with what he or she wants AND provide the engineer/direct report with the freedom and independence that he or she wants. We just might be able to find a win-win scenario.
Case in point. I'm going to share with you a case of a direct report that I coached through a difficult situation. This direct report works for a small business and has been managed relatively closely by his manager for some time. He has felt micromanaged and he complained to me that he wanted to be managed less closely. He wanted more autonomy and freedom than his manager was willing to give him and the more he attempted to get autonomy the more his manager tightened her grip and made his reporting even more onerous.
My first coaching point with this direct report was that the manager was doing this for some reason, probably legitimate in the manager's mind. So that is where we started. The direct report's task was to give the manager what she was asking for without fighting over it.
At first the direct report didn't understand how this was going to get him the autonomy he wanted. But he agreed to follow my suggestions and instructions.
He began to provide reports on the status of his tasks as the manager requested. He even suggested ways to improve the status reports.
I suggested other forms he could use to transmit data regarding the status of his tasks and projects. The manager appreciated these efforts on the part of the direct report.
After several months of this support for the manager, which by the way, turned out not to be very difficult or imposing on the direct report, the manager began to give the direct report more autonomy.
The outcome is that now the direct report and the manager have become much more of a team. The direct report is still providing the manager with the project reports but the format is streamlined and easy and doesn't take much time at all. The manager is so comfortable with the relationship that she has actually begun to manage him less closely. She actually gave him the autonomy he was originally seeking.
The direct report recently asked me, "So what happened here? How did this actually occur?"
My response was, "By giving your manager what she asked for and seeming to give up your drive for autonomy, you actually allowed the manager to be so comfortable with the communication between the two of you that she was willing to give you the autonomy you originally asked for."
By enhancing the relationship, the direct report actually reduced the level of micromanagement the manager thought she needed to feel comfortable. By "giving up the drive for autonomy, and by enhancing the manager/direct-report relationship, the direct report actually got more autonomy."
So the bottom line is that, in my experience, micromanagement is not something anyone has to live with. Engineers, scientists, and direct reports don't have to tolerate micromanagement if they understand how to set up the relationship with their manger. And managers don't have to worry about being perceived as micromanagers if they understand how to set up the relationship with their direct reports.
In my experience, micromanagement it's just not a big deal. That's why you'll often hear me say, "micromanagement doesn't really exist".
Be well,
Steven
Bad Management
The bad management is just about to catch up with the incompetent manager.
All and the engineering staff are ready to leave.
Be well,
Dwika=ExecuTrain
"Why do mediocre or even incompetent managers survive?"
by: Steven Cerri
(10 minute read)
Remember the Merovingian in the second installment of The Matrix? He was fond of saying, "Cause and Effect. Cause and Effect".
Or we could say, "A body in motion remains in motion unless acted upon by a force." Cause and Effect.
However, many events follow sequential patterns without being casually related. For example, a solar eclipse. Assume a solar eclipse occurs. I beat my drum to tell the gods to give back the sun. The sun returns. See, my drum beating worked!
Obviously, this type of reasoning is the basis for many superstitions and erroneous beliefs.
There is even a Latin name for it: "post hoc ergo propter hoc" (after this therefore because of this). This Latin phrase essentially ties an initial event#1 to a subsequent event#2 and states that event#1 caused event#2 without any proof of a connection.
The unfortunate point is that this approach to life is everywhere. Post hoc ergo propter hoc is everywhere!
It's in the advertisements that tell us that buying a new car will help us more easily get to the grocery store. It's in political discussions about what got us from Situation A to Situation B. It's in our discussions about how to become rich... stop buying coffee every morning (and you are on the way to becoming wealthy!).
Beware, post hoc ergo propter hoc is everywhere. IN FACT, it's even in management. Yes, management is filled with these false connections.
One of the places it shows up in management is in the management books that are written by "observers" of management. Books written by people who have followed executives around, or who have "questioned" executives of companies about their motives and actions, or those books written by people who have done a post-event analysis of the "causes" of the event. In many cases, these books are filled with examples of post hoc ergo propter hoc. The only way to know what goes on in the executive's head is to be an executive or to have been an executive. We must be very careful making or accepting connections that only "appear" to be.
Let me give you a real-world example of what I mean by post hoc ergo propter hoc in management. I'll set the stage carefully with this example.
Imagine a software company. It's a relatively small company, a startup. The people of interest in this story are the software development manager and the software development team of 6 programmers. The programmers are a combination of full-time employees and contract employees.
By most standards, (except those of the software development manager and the CEO...remember this, it will be important later) the software development manager is incompetent. Not only does this manager lack software development experience, he also lacks management training and experience and he lacks management temperament. He is incompetent but he and the CEO belive his management skills to be adequate and therefore he is in charge of software development.
The software team has been working for a couple of years on a new product. The product is getting close to completion. A potential client has emerged from the market to test the software and a date has been set for an implementation.
A glitch is found in the software. Additional work is necessary to get the software ready and it's going to be a lot of work. The installation was originally scheduled for a month from now.
The software development manager proclaims the following (I only paraphrase slightly): "The next month is going to be hard work. Seven days a week, twelve hours a day. This is going to be like the death march! This is going to be like the Battle of Stalingrad. Get ready."
A month later, the software is completed, the installation is on schedule.
Now here are the questions: "Did the management approach of "this is like the death march" and "this is going to be like the Battle of Stalingrad" contribute to or actually make the software developers meet the schedule? Did that management approach motivate the programmers to work as hard as they did? Was that management approach instrumental in achieving software development success in the last month?
Did the management style cause the successful completion of the project on time?
Post Hoc Ergo Propter Hoc!
Now I can guarantee you that in the manager's mind the answer is a resounding "YES! My management style worked! See we got the job done on time."
The CEO, I can guarantee you, will also answer, "YES! My manager is a good manager! Whatever he did he got the job done. Well done! Keep up the good work."
In my mind the answer is NO! They manager and the CEO, both, are guilty of Post Hoc Ergo Propter Hoc!
Why do I say this? Because most people actually want to do a good job. This applies to both full-time employees who would like to keep their jobs and to contractors who survive by doing good work.
Also most people, especially technical people, are often internally motivated regarding their work. The programmer decides when the code is finished. The programmer decides when the code is well enough documented. Much of the decision-making process regarding the quality of programming code is decided by the programmer. This is called "internal referencing".
Now add to this the fact that from the time we are all children in school, we are trained and taught to do good work, REGARDLESS of our teacher. How many children heard from their parents or others, "Don't complain to me about your teacher. Do your homework." Or, "I don't care if your teacher is nice or not, that's no excuse for these poor grades."
We are trained from an early age to do good work regardless and in spite of the circumstances, regardless of our treatment (up to a point) and as engineers we take a great deal of pride in our work (as do many, many others as well).
This means that we will do good work IN SPITE of the managers we have. And you know this is the case. How many times have you done a good job even though you've had a poor manager? How many times have you had an attitude "I'll show him or I'll show her"?
Just look around and you'll see that people often do good work REGARDLESS of the quality of their managers and this is due, in large measure, to the educational system we are all put through. People will complain and still do good work. Until they reach a threshold. Then they will either fight back or leave.
They might fight back by complaining, slowing down their work, no longer doing good work, or by sabotaging their project. By this point you've lost the employee. And as you know, the good employees leave sooner than the less competent ones. The less competent employees will attempt to fight back, the better employees will leave to find a better home and get on with their lives.
Is it any wonder then that most manager's believe their personal management styles work well? Most management styles seem to work because most management styles don't matter... up to a point. Most management styles don't have any power compared to the personal sense of pride in accomplishing good work that most employees have early in the process.
Be aware however, this is generational. Past generations, older workers, are much more willing to put up with poor management and still do good work. The younger generations are not so generous. In fact, it's a little ironic that the younger generations, which want more autonomy, also will demand better managers.
So for managers and would-be managers, here is your tip for the day: "Management style doesn't matter until it does. In many situations, the drive of the individual direct report to do a good job is so high, that even incompetent managers can be successful.... until their incompetence wears down the pride of the employee. And then the employee will either leave or rebel.
But! because the manager has achieved successes in the past with the specific employee(s) in question, it appears that the employee is the one who has cracked. It appears that the manager has been doing a good job and the employee is the one who is at fault for this "shift" in attitude. In reality, the employee is just finally fed up. The employee has reached his or her threshold. A threshold that has been slowly approached ... the slowness is in direct relation to the pride and will of the employee to do good work in spite of the poor management style of the manager.
Just as many children grow up to be decent people in spite of their parents, many employees do good work in spite of their managers. However, just as a parent can put a child over the edge and the child can become a delinquent, an incompetent manager can push an employee over the edge and the employee leaves or becomes disruptive. Your job is not to be an incompetent manager and rely on the desire of the direct report to do good work, as the manager in this example is doing. Your job as a manager is to inspire employees to do good work not just for themselves, but also for the team, for the manager, for the company, for sheer job of it. Bad management will catch up with you. Good management will have you trying to catch up with your team.
So back to my example company. The bad management is just about to catch up with the incompetent manager.
All, and I do mean all, of the engineering staff are ready to leave. Most of them are actively looking for new jobs, and one has already left. They strategist about how to tell the CEO of the manager's incompetence. They talk each other out of quitting on a weekly basis. It's only a matter of time. When they decide that the company won't collapse with their departure (see, there's that desire to do good work cropping up again) or when they get fed up, they'll leave. Maybe they'll tell the incompetent manager off, as did one employee who recently resigned. Or maybe they'll just resign and be done with it. They'll leave and move on with their careers.
The only unfortunate outcome of their leaving however, regardless of "how they resign" will be that the management (the CEO and the incompetent manager) are very likely to say, "It's just as well. They were just fickle and disgruntled employees anyway and they were just too difficult to manage."
Be well,
Steven
All and the engineering staff are ready to leave.
Be well,
Dwika=ExecuTrain
"Why do mediocre or even incompetent managers survive?"
by: Steven Cerri
(10 minute read)
Remember the Merovingian in the second installment of The Matrix? He was fond of saying, "Cause and Effect. Cause and Effect".
Or we could say, "A body in motion remains in motion unless acted upon by a force." Cause and Effect.
However, many events follow sequential patterns without being casually related. For example, a solar eclipse. Assume a solar eclipse occurs. I beat my drum to tell the gods to give back the sun. The sun returns. See, my drum beating worked!
Obviously, this type of reasoning is the basis for many superstitions and erroneous beliefs.
There is even a Latin name for it: "post hoc ergo propter hoc" (after this therefore because of this). This Latin phrase essentially ties an initial event#1 to a subsequent event#2 and states that event#1 caused event#2 without any proof of a connection.
The unfortunate point is that this approach to life is everywhere. Post hoc ergo propter hoc is everywhere!
It's in the advertisements that tell us that buying a new car will help us more easily get to the grocery store. It's in political discussions about what got us from Situation A to Situation B. It's in our discussions about how to become rich... stop buying coffee every morning (and you are on the way to becoming wealthy!).
Beware, post hoc ergo propter hoc is everywhere. IN FACT, it's even in management. Yes, management is filled with these false connections.
One of the places it shows up in management is in the management books that are written by "observers" of management. Books written by people who have followed executives around, or who have "questioned" executives of companies about their motives and actions, or those books written by people who have done a post-event analysis of the "causes" of the event. In many cases, these books are filled with examples of post hoc ergo propter hoc. The only way to know what goes on in the executive's head is to be an executive or to have been an executive. We must be very careful making or accepting connections that only "appear" to be.
Let me give you a real-world example of what I mean by post hoc ergo propter hoc in management. I'll set the stage carefully with this example.
Imagine a software company. It's a relatively small company, a startup. The people of interest in this story are the software development manager and the software development team of 6 programmers. The programmers are a combination of full-time employees and contract employees.
By most standards, (except those of the software development manager and the CEO...remember this, it will be important later) the software development manager is incompetent. Not only does this manager lack software development experience, he also lacks management training and experience and he lacks management temperament. He is incompetent but he and the CEO belive his management skills to be adequate and therefore he is in charge of software development.
The software team has been working for a couple of years on a new product. The product is getting close to completion. A potential client has emerged from the market to test the software and a date has been set for an implementation.
A glitch is found in the software. Additional work is necessary to get the software ready and it's going to be a lot of work. The installation was originally scheduled for a month from now.
The software development manager proclaims the following (I only paraphrase slightly): "The next month is going to be hard work. Seven days a week, twelve hours a day. This is going to be like the death march! This is going to be like the Battle of Stalingrad. Get ready."
A month later, the software is completed, the installation is on schedule.
Now here are the questions: "Did the management approach of "this is like the death march" and "this is going to be like the Battle of Stalingrad" contribute to or actually make the software developers meet the schedule? Did that management approach motivate the programmers to work as hard as they did? Was that management approach instrumental in achieving software development success in the last month?
Did the management style cause the successful completion of the project on time?
Post Hoc Ergo Propter Hoc!
Now I can guarantee you that in the manager's mind the answer is a resounding "YES! My management style worked! See we got the job done on time."
The CEO, I can guarantee you, will also answer, "YES! My manager is a good manager! Whatever he did he got the job done. Well done! Keep up the good work."
In my mind the answer is NO! They manager and the CEO, both, are guilty of Post Hoc Ergo Propter Hoc!
Why do I say this? Because most people actually want to do a good job. This applies to both full-time employees who would like to keep their jobs and to contractors who survive by doing good work.
Also most people, especially technical people, are often internally motivated regarding their work. The programmer decides when the code is finished. The programmer decides when the code is well enough documented. Much of the decision-making process regarding the quality of programming code is decided by the programmer. This is called "internal referencing".
Now add to this the fact that from the time we are all children in school, we are trained and taught to do good work, REGARDLESS of our teacher. How many children heard from their parents or others, "Don't complain to me about your teacher. Do your homework." Or, "I don't care if your teacher is nice or not, that's no excuse for these poor grades."
We are trained from an early age to do good work regardless and in spite of the circumstances, regardless of our treatment (up to a point) and as engineers we take a great deal of pride in our work (as do many, many others as well).
This means that we will do good work IN SPITE of the managers we have. And you know this is the case. How many times have you done a good job even though you've had a poor manager? How many times have you had an attitude "I'll show him or I'll show her"?
Just look around and you'll see that people often do good work REGARDLESS of the quality of their managers and this is due, in large measure, to the educational system we are all put through. People will complain and still do good work. Until they reach a threshold. Then they will either fight back or leave.
They might fight back by complaining, slowing down their work, no longer doing good work, or by sabotaging their project. By this point you've lost the employee. And as you know, the good employees leave sooner than the less competent ones. The less competent employees will attempt to fight back, the better employees will leave to find a better home and get on with their lives.
Is it any wonder then that most manager's believe their personal management styles work well? Most management styles seem to work because most management styles don't matter... up to a point. Most management styles don't have any power compared to the personal sense of pride in accomplishing good work that most employees have early in the process.
Be aware however, this is generational. Past generations, older workers, are much more willing to put up with poor management and still do good work. The younger generations are not so generous. In fact, it's a little ironic that the younger generations, which want more autonomy, also will demand better managers.
So for managers and would-be managers, here is your tip for the day: "Management style doesn't matter until it does. In many situations, the drive of the individual direct report to do a good job is so high, that even incompetent managers can be successful.... until their incompetence wears down the pride of the employee. And then the employee will either leave or rebel.
But! because the manager has achieved successes in the past with the specific employee(s) in question, it appears that the employee is the one who has cracked. It appears that the manager has been doing a good job and the employee is the one who is at fault for this "shift" in attitude. In reality, the employee is just finally fed up. The employee has reached his or her threshold. A threshold that has been slowly approached ... the slowness is in direct relation to the pride and will of the employee to do good work in spite of the poor management style of the manager.
Just as many children grow up to be decent people in spite of their parents, many employees do good work in spite of their managers. However, just as a parent can put a child over the edge and the child can become a delinquent, an incompetent manager can push an employee over the edge and the employee leaves or becomes disruptive. Your job is not to be an incompetent manager and rely on the desire of the direct report to do good work, as the manager in this example is doing. Your job as a manager is to inspire employees to do good work not just for themselves, but also for the team, for the manager, for the company, for sheer job of it. Bad management will catch up with you. Good management will have you trying to catch up with your team.
So back to my example company. The bad management is just about to catch up with the incompetent manager.
All, and I do mean all, of the engineering staff are ready to leave. Most of them are actively looking for new jobs, and one has already left. They strategist about how to tell the CEO of the manager's incompetence. They talk each other out of quitting on a weekly basis. It's only a matter of time. When they decide that the company won't collapse with their departure (see, there's that desire to do good work cropping up again) or when they get fed up, they'll leave. Maybe they'll tell the incompetent manager off, as did one employee who recently resigned. Or maybe they'll just resign and be done with it. They'll leave and move on with their careers.
The only unfortunate outcome of their leaving however, regardless of "how they resign" will be that the management (the CEO and the incompetent manager) are very likely to say, "It's just as well. They were just fickle and disgruntled employees anyway and they were just too difficult to manage."
Be well,
Steven
Merge behaviors
Your two teams began to merge in their behaviors toward a more collegial approach. One team had to be dissolved because they could not make the transition.
Be well,
Dwika-ExecuTrain
"How can two teams work together when they are so different?"
by: Steven Cerri
Here's the situation.
Imagine you are a Director in a technical company. The company designs, develops, manufactures, distributes, and supports software for a vertical market. You are managing two teams. One is co-located with you and you have worked with them for a long time. You understand them and they understand you. We'll call this team, Home-Team. The Home-Team has worked together for some time and know how to work successfully to get things done.
You have also, just recently, been tasked to manage a team that is located half-way around the world. We'll call this team, Away-Team. Away-Team has worked together for a long time as well, and they too know how to work well to get things done. You, however, have not worked with the Away-Team before.
Your job now is to get Home-Team and Away-Team to work together as a Combined-Team. Combined-Team is being tasked to contribute the respective expertise of the two teams so that the whole team is successful. Home-Team has an expertise that it must contribute for success and Away-Team has an expertise that it must also contribute for success.
In most cases this seems like a "no-brainer". Both teams have been successful in their respective pasts. Both teams work well with their respective team members. How difficult can it be for these two teams to work together?
That's the set-up. Now I'll tell you what happens.
The reality is different than your expectations. After the first several meetings with just you and the Away-Team you begin to notice something. You begin to notice that Away-Team seems very aggressive and argumentative. They argue with you about everything. They disagree with you about everything. It seems that you can't say anything without someone from the Away-Team saying the opposite or telling you that you "can't". The really interesting thing is that the Away-Team members argue amongst themselves as well. They treat each other as they treat you.
You don't think too much of it at first even though you notice this behavior in the Away-Team. You decide that it's just a difference in style and you don't think it deserves much more attention than just a notice. It will work itself out you think.
So you continue on and decide that it's time for the two teams to have their first joint meeting. You set up a phone conference with everyone from Home-Team and Away-Team. During the meeting it is clear to you that the Home-Team is more collegial and the Away-Team is much more combative, critical, and aggressive.
In fact, as the meeting continues one of the members of the Away-Team makes a comment that can be interpreted as a strong and direct criticism of one of the members of Home-Team. You decide not to say anything. Neither does anyone else. Everyone seems to just bury the tension that was generated by the comment. The meeting ends and some of the other members of Home-Team ask you what you thought about the statement at the end of the meeting. You respond first by asking them what they thought.
They tell you that they think that the Home-Team member who was apparently criticized will probably feel unfairly stepped on. You go to the Home-Team member in question and you ask her what she thought about the meeting. She singles-out the statement you were concerned about and makes the comment that the statement seemed to be overly critical of her.
You talk to a few other people from the Home-Team and you feel that you've gathered enough information to come to the following conclusions:
1. The Home-Team believes that one of their members was criticized unfairly.
2. From your past experience, you are now convinced that this behavior is standard for the Away-Team team.
3. Whatever the Away-Team thinks, the Home-Team does not appreciate this kind of behavior and doesn't know how to participate effectively when this approach is used.
Your general conclusions are the following. The two teams have distinctly different styles of communication, interaction, and team participation. Home-Team utilizes a much more collegial communication process. Away-Team utilizes a much more combative team participation process. One approach is not right and the other wrong. One approach is not even better than the other. They are merely different.
The two teams are not going to get along in the long run using these distinctly different approaches, however. The two teams have such different communication styles that the collegial process used by Home-Team is seen by Away-Team as being "wimpy and weak." Whereas, the combative style of the Away-Team is viewed by the Home-Team as being "unnecessarily combative and unproductive".
You decide you have to do something. You decide that you have to bring both teams into alignment regarding their communication processes. But how? What do you do?
Obviously you have several choices. You could:
1. Just address the person on Away-Team who made the critical comment and attempt to rectify his mode of communication.
2. You could do nothing and wait for another event in order to address this situation.
3. You could do nothing and hope that the situation will rectify itself.
4. You could call a phone meeting of both teams and address the issue.
5. You could write an email to everyone.
6. You could wait until the next regularly scheduled meeting and address it then.
7. You could tell the direct report who felt criticized to get "thicker skin" and forget about it.
There are probably plenty of other choices I have not listed here that you might add to my list. But this is probably enough.
Here is my suggested approach.
First, as the leader of both teams you must decide how you want the Combined-Team to behave. This is the critical first step. You must decide how you want the members of each team to behave toward the other team. Since this is your team, you are the one to decide what it means to be a team. You are the one to decide what behaviors will be rewarded and what behaviors will not. That is your job.
Here is what I did.
In this case, I decided that I wanted to err on the side of Home-Team. I wanted a more collegial team process than a more combative one. I wanted this, not because it is better, but because it is very difficult to separate our own preferences from our management and leadership styles. I personally, like the more collegial processes and I shy away from the more combative processes. Therefore, it is reasonable that I would want the Combined-Team to be more like the Home-Team than the Away-Team. It's my preference. I wanted the Away-Team to move more toward the behaviors of the Home-Team. The Away-Team was going to have to change.
Next I had to decide how best to convey to the two teams the information and the acceptable behaviors that I wanted.
These were my intentions!
1. What did I want to accomplish?
(I wanted the Combined-Team to function more like the Home-Team. This meant that the Away-Team would have to change their style.)
2. What did I want to say.
(I wanted to explain to both teams the concept of collegial and combative behavior and what I wanted as a combined team. I also wanted to define acceptable and unacceptable behaviors, unequivocally.)
3. How would I best convey this information to the two teams? (Should I use phone, email, or try to communicate this in-person?)
4. What was I going to do?
(I was going to reward collegial behavior and not reward combative, aggressive, and negative behavior.)
5. What reactions could I expect?
(I could expect the Away-Team to resist. It is in their behavioral nature to resist. It was going to take some time and some "punishment" from me to get them to move toward the behaviors I wanted. Because of their very nature of being a combative team, they would not go willingly to the behaviors I wanted.)
6. How would I respond to those reactions?
(This process would require a great deal of patience on my part. I would have to stay consistent, persistent, calm, and resolute. They would have to see that no matter how much they resisted, I was not going to change my mind and I was also not going to get upset. My goal was that ultimately they would see that collegial behavior was as good or better than combative behavior.
These were my actions!
I decided I wanted to communicate to everyone, at the same time. I had three choices regarding communication protocol.
1. I could have a face-to-face meeting. (This was too expensive because I couldn't fly everyone to one location, so this approach was out.)
2. I could have a video conference. (We didn't have the equipment for this approach either, so this approach was out.)
3. I could use a telephone meeting. (This is a reasonable approach except that if I can't see the facial expressions and body language I'd probably elect the fourth approach listed next. I decided against this approach.)
4. I could use email to convey the message to everyone at once. (I ultimately selected this approach.)
I picked option number 4, email. Now, I have very little respect for email when it comes to conveying important, non-quantifiable information. So you can legitimately ask why I selected email in this case?
The reason I picked email is because I wanted this communication to "feel" like a one-on-one communication process. I wanted everyone on both teams to "hear" and "get" the same message. I didn't want any discussion in this first communication. This was to be, generally, a one-way communication. Me to all the team members. If I couldn't have a face-to-face meeting with everyone at once, then email was the next best thing... only in this case!
So my email was a long message. It laid out my philosophy of team building. I explained the two processes used by the respective teams. I explained what I wanted. I explained what behaviors would be expected and rewarded and not rewarded. I ended by stating that everyone would have the opportunity to discuss this with me one-on-one and in the group. I also indicated that we would be discussing this topic and the associated processes in the future.
I followed this up with a consistent and constant reference to this approach at nearly every meeting we had. I believe this is something most managers fail to do. They fail to utilize their general meetings as an opportunity to reinforce their philosophy of how they want the team to relate. During any meeting you have as a manager with your team, you have the opportunity to reinforce with examples, appreciation for an employee's behavior, or general statements of what you think is important, those behaviors you want to see exhibited by your team. Remember also that you must exhibit those same behaviors that you want in your team.
Slowly and surely, the two teams began to merge in their behaviors toward a more collegial approach. But not all teams have worked out well. In one case, one team had to be dissolved because they could not make the transition. Welcome to the world of management.
Good luck and be well,
Steven
Be well,
Dwika-ExecuTrain
"How can two teams work together when they are so different?"
by: Steven Cerri
Here's the situation.
Imagine you are a Director in a technical company. The company designs, develops, manufactures, distributes, and supports software for a vertical market. You are managing two teams. One is co-located with you and you have worked with them for a long time. You understand them and they understand you. We'll call this team, Home-Team. The Home-Team has worked together for some time and know how to work successfully to get things done.
You have also, just recently, been tasked to manage a team that is located half-way around the world. We'll call this team, Away-Team. Away-Team has worked together for a long time as well, and they too know how to work well to get things done. You, however, have not worked with the Away-Team before.
Your job now is to get Home-Team and Away-Team to work together as a Combined-Team. Combined-Team is being tasked to contribute the respective expertise of the two teams so that the whole team is successful. Home-Team has an expertise that it must contribute for success and Away-Team has an expertise that it must also contribute for success.
In most cases this seems like a "no-brainer". Both teams have been successful in their respective pasts. Both teams work well with their respective team members. How difficult can it be for these two teams to work together?
That's the set-up. Now I'll tell you what happens.
The reality is different than your expectations. After the first several meetings with just you and the Away-Team you begin to notice something. You begin to notice that Away-Team seems very aggressive and argumentative. They argue with you about everything. They disagree with you about everything. It seems that you can't say anything without someone from the Away-Team saying the opposite or telling you that you "can't". The really interesting thing is that the Away-Team members argue amongst themselves as well. They treat each other as they treat you.
You don't think too much of it at first even though you notice this behavior in the Away-Team. You decide that it's just a difference in style and you don't think it deserves much more attention than just a notice. It will work itself out you think.
So you continue on and decide that it's time for the two teams to have their first joint meeting. You set up a phone conference with everyone from Home-Team and Away-Team. During the meeting it is clear to you that the Home-Team is more collegial and the Away-Team is much more combative, critical, and aggressive.
In fact, as the meeting continues one of the members of the Away-Team makes a comment that can be interpreted as a strong and direct criticism of one of the members of Home-Team. You decide not to say anything. Neither does anyone else. Everyone seems to just bury the tension that was generated by the comment. The meeting ends and some of the other members of Home-Team ask you what you thought about the statement at the end of the meeting. You respond first by asking them what they thought.
They tell you that they think that the Home-Team member who was apparently criticized will probably feel unfairly stepped on. You go to the Home-Team member in question and you ask her what she thought about the meeting. She singles-out the statement you were concerned about and makes the comment that the statement seemed to be overly critical of her.
You talk to a few other people from the Home-Team and you feel that you've gathered enough information to come to the following conclusions:
1. The Home-Team believes that one of their members was criticized unfairly.
2. From your past experience, you are now convinced that this behavior is standard for the Away-Team team.
3. Whatever the Away-Team thinks, the Home-Team does not appreciate this kind of behavior and doesn't know how to participate effectively when this approach is used.
Your general conclusions are the following. The two teams have distinctly different styles of communication, interaction, and team participation. Home-Team utilizes a much more collegial communication process. Away-Team utilizes a much more combative team participation process. One approach is not right and the other wrong. One approach is not even better than the other. They are merely different.
The two teams are not going to get along in the long run using these distinctly different approaches, however. The two teams have such different communication styles that the collegial process used by Home-Team is seen by Away-Team as being "wimpy and weak." Whereas, the combative style of the Away-Team is viewed by the Home-Team as being "unnecessarily combative and unproductive".
You decide you have to do something. You decide that you have to bring both teams into alignment regarding their communication processes. But how? What do you do?
Obviously you have several choices. You could:
1. Just address the person on Away-Team who made the critical comment and attempt to rectify his mode of communication.
2. You could do nothing and wait for another event in order to address this situation.
3. You could do nothing and hope that the situation will rectify itself.
4. You could call a phone meeting of both teams and address the issue.
5. You could write an email to everyone.
6. You could wait until the next regularly scheduled meeting and address it then.
7. You could tell the direct report who felt criticized to get "thicker skin" and forget about it.
There are probably plenty of other choices I have not listed here that you might add to my list. But this is probably enough.
Here is my suggested approach.
First, as the leader of both teams you must decide how you want the Combined-Team to behave. This is the critical first step. You must decide how you want the members of each team to behave toward the other team. Since this is your team, you are the one to decide what it means to be a team. You are the one to decide what behaviors will be rewarded and what behaviors will not. That is your job.
Here is what I did.
In this case, I decided that I wanted to err on the side of Home-Team. I wanted a more collegial team process than a more combative one. I wanted this, not because it is better, but because it is very difficult to separate our own preferences from our management and leadership styles. I personally, like the more collegial processes and I shy away from the more combative processes. Therefore, it is reasonable that I would want the Combined-Team to be more like the Home-Team than the Away-Team. It's my preference. I wanted the Away-Team to move more toward the behaviors of the Home-Team. The Away-Team was going to have to change.
Next I had to decide how best to convey to the two teams the information and the acceptable behaviors that I wanted.
These were my intentions!
1. What did I want to accomplish?
(I wanted the Combined-Team to function more like the Home-Team. This meant that the Away-Team would have to change their style.)
2. What did I want to say.
(I wanted to explain to both teams the concept of collegial and combative behavior and what I wanted as a combined team. I also wanted to define acceptable and unacceptable behaviors, unequivocally.)
3. How would I best convey this information to the two teams? (Should I use phone, email, or try to communicate this in-person?)
4. What was I going to do?
(I was going to reward collegial behavior and not reward combative, aggressive, and negative behavior.)
5. What reactions could I expect?
(I could expect the Away-Team to resist. It is in their behavioral nature to resist. It was going to take some time and some "punishment" from me to get them to move toward the behaviors I wanted. Because of their very nature of being a combative team, they would not go willingly to the behaviors I wanted.)
6. How would I respond to those reactions?
(This process would require a great deal of patience on my part. I would have to stay consistent, persistent, calm, and resolute. They would have to see that no matter how much they resisted, I was not going to change my mind and I was also not going to get upset. My goal was that ultimately they would see that collegial behavior was as good or better than combative behavior.
These were my actions!
I decided I wanted to communicate to everyone, at the same time. I had three choices regarding communication protocol.
1. I could have a face-to-face meeting. (This was too expensive because I couldn't fly everyone to one location, so this approach was out.)
2. I could have a video conference. (We didn't have the equipment for this approach either, so this approach was out.)
3. I could use a telephone meeting. (This is a reasonable approach except that if I can't see the facial expressions and body language I'd probably elect the fourth approach listed next. I decided against this approach.)
4. I could use email to convey the message to everyone at once. (I ultimately selected this approach.)
I picked option number 4, email. Now, I have very little respect for email when it comes to conveying important, non-quantifiable information. So you can legitimately ask why I selected email in this case?
The reason I picked email is because I wanted this communication to "feel" like a one-on-one communication process. I wanted everyone on both teams to "hear" and "get" the same message. I didn't want any discussion in this first communication. This was to be, generally, a one-way communication. Me to all the team members. If I couldn't have a face-to-face meeting with everyone at once, then email was the next best thing... only in this case!
So my email was a long message. It laid out my philosophy of team building. I explained the two processes used by the respective teams. I explained what I wanted. I explained what behaviors would be expected and rewarded and not rewarded. I ended by stating that everyone would have the opportunity to discuss this with me one-on-one and in the group. I also indicated that we would be discussing this topic and the associated processes in the future.
I followed this up with a consistent and constant reference to this approach at nearly every meeting we had. I believe this is something most managers fail to do. They fail to utilize their general meetings as an opportunity to reinforce their philosophy of how they want the team to relate. During any meeting you have as a manager with your team, you have the opportunity to reinforce with examples, appreciation for an employee's behavior, or general statements of what you think is important, those behaviors you want to see exhibited by your team. Remember also that you must exhibit those same behaviors that you want in your team.
Slowly and surely, the two teams began to merge in their behaviors toward a more collegial approach. But not all teams have worked out well. In one case, one team had to be dissolved because they could not make the transition. Welcome to the world of management.
Good luck and be well,
Steven
Stay emotional and physiological state
You should put your attention on what customers were trying to accomplish; get a good product that you could all be proud of into the hands of the customer. You should stay in an emotional and physiological state that allowed you to act in a way to move the team and the product forward.
Be well,
Dwika-ExecuTrain
"Stop complaining. I've had enough of it!"
by: Steven Cerri
Here's the situation.
Imagine you are a product manager. You are in charge of a small team, say five people. Your team is in charge of designing, building, and delivering a commercial, high-tech product to the market.
(For for the sake of this example, that's the situation. But you realize that I could be talking about any product or program manager and any team designing and producing a piece of hardware or software. This could be any team.)
Every Monday morning you meet with your team to discuss the status of the work everyone is doing and what is on schedule for the upcoming week. In this meeting your goal is to find out if any one needs your help for the upcoming week or if anyone needs help from any other team member or any other department. It also gives you visibility if there is anything you should be aware of. (Monday morning team meetings are extremely important and I highly recommend them.)
Your Monday meeting is attended by the following team members: the mechanical engineer, the programmer, the marketing person, the customer service person, and your quality person.
You and your team are getting very close to releasing your first product and you are just gearing up the manufacturing process. So it's going to be a slow and progressive production ramp up.
The team is "on board" and ready.
You begin delivering the first units into the customers hands.
And then... the customers are on the phone complaining to your customer service team member, Tom, that things aren't working as they are supposed to.
Tom is fielding all the customer calls and he's getting an "ear full". Customers are irate. About 10% of the products aren't working as they should.
That 10% are not happy and are complaining to Tom that "This isn't working!"; and "That isn't working!"; and "I thought I could do this and I can't!".
Tom is having a difficult time handling the calls. He has a tendency to take the attacks personally and very seriously, so he is brining the intense complaints of the customers to the Monday morning meetings.
In fact, now that the product is being delivered into the customers waiting hands, and some of the customers are upset, Tom is coming to the Monday morning meetings as upset with your company as are the customers.
That's the set-up. Now I'll tell you what happens.
At every Monday morning meeting, your process is to open the meeting and then ask each team member in turn, how things are going, what they need from you or from others on the team or from others in the company, and what's on their agenda for the upcoming week.
Since product delivery began, when you get to Tom's portion of the meeting, Tom begins his review of the previous week with a tirade about how customers are upset and how it's the company's fault. He says things like:
"Our customers are so upset with us! The hardware doesn't work and the software doesn't do what it's supposed to."
"How could we be delivering a product with so many problems."
"Our company has no integrity if we deliver this type of product."
"How much longer are we going to deliver such a poor product?"
"I'm embarrassed to talk to our customers. We have no integrity as a company."
And on and on he goes, delivering his statements on behalf of the customers with more than enough emotional punch.
Tom is coming to the Monday morning meetings and he is complaining and ranting and raving and getting very emotional. He is not being generally very productive, he is just complaining. And from his point of view he is representing the customers' position.
Your general conclusions are the following.
Tom is exaggerating a little, maybe even a lot. Most of the customers are satisfied. Yet there is no doubt that the product has some problems. Tom is documenting the problems as the customers call and so you know that he is capturing whatever issues the product might have.
As I stated previously, about 10% of the customers are calling Tom and complaining. Your team is working on the problems. The software is being fixed but not fast enough for Tom and his irate customers. The hardware is being modified but, once again, not fast enough for Tom and his irate customers.
So what do you do?
Do you shut Tom down? Do you tell him to stop complaining, the problems will be fixed?
Do you tell Tom to tell the customers that the fixes are in the works? It will be another month before all fixes are released and the customers will get the upgrades then. Meanwhile they'll have to do what they can.
Do you tell Tom to shut up? You are quite aware of the problems and they are being fixed?
Do you tell Tom to have more respect for his team and for the company?
Do you join Tom in complaining about the company?
Do you ignore Tom?
What would you do?
My suggested approach.
Here is my philosophy... my map of the world.
I believe very strongly that a manager and leader has to lead by example. But I don't mean that like most people think of it. I mean that a manager must "model" the behavior they want.
Next, I believe that people's intentions are mostly honorable. That their actions are an attempt to uphold something fundamentally good in them and that my job, as the manager and leader, is to understand what that purpose is and to tap into it and use it to point them in the direction of the desired outcome, the goal.
This is where I put my attention.
I did not put my attention on Tom's irate protestations. I did not put my attention on how Tom was yelling about our company.
I put my attention on what Tom was trying to accomplish; get a good product that we could all be proud of into the hands of the customer.
What was my emotional and physiological state?
I remained calm. I stayed in an emotional and physiological state that allowed me to act in a way to move the team and the product forward.
These were my actions!
My actions were probably very different than many people would expect.
I let Tom continue complaining and protesting and often I didn't say anything. I just listened. I acknowledged what Tom was saying; I acknowledged that the customers were having problems; I acknowledged that we were fixing the problems; and that is all I said.
I did not tell Tom that he was wrong in getting upset on the customers' behalf. I did not tell Tom not to raise his voice.
I let Tom be Tom.
Why these actions?
Why did I pick these behaviors?
Because of two fundamentals values and outcomes I was going for:
1. I wanted all the team members to believe that they could express themselves honestly, openly, and in accord with their own integrity. If I shut Tom down for being passionate about his customers, I'd be sending the message to the other team members that they would not be safe expressing themselves. I knew that whatever message I sent to Tom, I would be sending to the rest of the team as well. By giving Tom the freedom to be Tom, I was sending the message to the whole team that I trusted their "voices".
2. I knew that if Tom felt this way about the problems our customers were having, when the time ultimately came that Tom said, "You know, we really have a good product now", I'd know that we really did have a good product. If we could satisfy Tom we could satisfy all our customers.
What ultimately happened?
About six weeks into product delivery the new software was delivered, the hardware modifications went into products and the complaints from customers dropped to, essentially, zero.
Finally, Tom came into a Monday morning meeting and said, "Well, I think we've done it. We finally have a great product that we can be proud of. Our customers are happy."
Now there was no doubt in my mind that it was so.
(P.S. Throughout our existence as a product development team, our team had the reputation of having the best team relationships and the best response time to product development and product issues of any team in the company.)
What would you have done?
Email me with your suggestions. I'm very interested in your thoughts.
Good luck and be well,
Steven
Be well,
Dwika-ExecuTrain
"Stop complaining. I've had enough of it!"
by: Steven Cerri
Here's the situation.
Imagine you are a product manager. You are in charge of a small team, say five people. Your team is in charge of designing, building, and delivering a commercial, high-tech product to the market.
(For for the sake of this example, that's the situation. But you realize that I could be talking about any product or program manager and any team designing and producing a piece of hardware or software. This could be any team.)
Every Monday morning you meet with your team to discuss the status of the work everyone is doing and what is on schedule for the upcoming week. In this meeting your goal is to find out if any one needs your help for the upcoming week or if anyone needs help from any other team member or any other department. It also gives you visibility if there is anything you should be aware of. (Monday morning team meetings are extremely important and I highly recommend them.)
Your Monday meeting is attended by the following team members: the mechanical engineer, the programmer, the marketing person, the customer service person, and your quality person.
You and your team are getting very close to releasing your first product and you are just gearing up the manufacturing process. So it's going to be a slow and progressive production ramp up.
The team is "on board" and ready.
You begin delivering the first units into the customers hands.
And then... the customers are on the phone complaining to your customer service team member, Tom, that things aren't working as they are supposed to.
Tom is fielding all the customer calls and he's getting an "ear full". Customers are irate. About 10% of the products aren't working as they should.
That 10% are not happy and are complaining to Tom that "This isn't working!"; and "That isn't working!"; and "I thought I could do this and I can't!".
Tom is having a difficult time handling the calls. He has a tendency to take the attacks personally and very seriously, so he is brining the intense complaints of the customers to the Monday morning meetings.
In fact, now that the product is being delivered into the customers waiting hands, and some of the customers are upset, Tom is coming to the Monday morning meetings as upset with your company as are the customers.
That's the set-up. Now I'll tell you what happens.
At every Monday morning meeting, your process is to open the meeting and then ask each team member in turn, how things are going, what they need from you or from others on the team or from others in the company, and what's on their agenda for the upcoming week.
Since product delivery began, when you get to Tom's portion of the meeting, Tom begins his review of the previous week with a tirade about how customers are upset and how it's the company's fault. He says things like:
"Our customers are so upset with us! The hardware doesn't work and the software doesn't do what it's supposed to."
"How could we be delivering a product with so many problems."
"Our company has no integrity if we deliver this type of product."
"How much longer are we going to deliver such a poor product?"
"I'm embarrassed to talk to our customers. We have no integrity as a company."
And on and on he goes, delivering his statements on behalf of the customers with more than enough emotional punch.
Tom is coming to the Monday morning meetings and he is complaining and ranting and raving and getting very emotional. He is not being generally very productive, he is just complaining. And from his point of view he is representing the customers' position.
Your general conclusions are the following.
Tom is exaggerating a little, maybe even a lot. Most of the customers are satisfied. Yet there is no doubt that the product has some problems. Tom is documenting the problems as the customers call and so you know that he is capturing whatever issues the product might have.
As I stated previously, about 10% of the customers are calling Tom and complaining. Your team is working on the problems. The software is being fixed but not fast enough for Tom and his irate customers. The hardware is being modified but, once again, not fast enough for Tom and his irate customers.
So what do you do?
Do you shut Tom down? Do you tell him to stop complaining, the problems will be fixed?
Do you tell Tom to tell the customers that the fixes are in the works? It will be another month before all fixes are released and the customers will get the upgrades then. Meanwhile they'll have to do what they can.
Do you tell Tom to shut up? You are quite aware of the problems and they are being fixed?
Do you tell Tom to have more respect for his team and for the company?
Do you join Tom in complaining about the company?
Do you ignore Tom?
What would you do?
My suggested approach.
Here is my philosophy... my map of the world.
I believe very strongly that a manager and leader has to lead by example. But I don't mean that like most people think of it. I mean that a manager must "model" the behavior they want.
Next, I believe that people's intentions are mostly honorable. That their actions are an attempt to uphold something fundamentally good in them and that my job, as the manager and leader, is to understand what that purpose is and to tap into it and use it to point them in the direction of the desired outcome, the goal.
This is where I put my attention.
I did not put my attention on Tom's irate protestations. I did not put my attention on how Tom was yelling about our company.
I put my attention on what Tom was trying to accomplish; get a good product that we could all be proud of into the hands of the customer.
What was my emotional and physiological state?
I remained calm. I stayed in an emotional and physiological state that allowed me to act in a way to move the team and the product forward.
These were my actions!
My actions were probably very different than many people would expect.
I let Tom continue complaining and protesting and often I didn't say anything. I just listened. I acknowledged what Tom was saying; I acknowledged that the customers were having problems; I acknowledged that we were fixing the problems; and that is all I said.
I did not tell Tom that he was wrong in getting upset on the customers' behalf. I did not tell Tom not to raise his voice.
I let Tom be Tom.
Why these actions?
Why did I pick these behaviors?
Because of two fundamentals values and outcomes I was going for:
1. I wanted all the team members to believe that they could express themselves honestly, openly, and in accord with their own integrity. If I shut Tom down for being passionate about his customers, I'd be sending the message to the other team members that they would not be safe expressing themselves. I knew that whatever message I sent to Tom, I would be sending to the rest of the team as well. By giving Tom the freedom to be Tom, I was sending the message to the whole team that I trusted their "voices".
2. I knew that if Tom felt this way about the problems our customers were having, when the time ultimately came that Tom said, "You know, we really have a good product now", I'd know that we really did have a good product. If we could satisfy Tom we could satisfy all our customers.
What ultimately happened?
About six weeks into product delivery the new software was delivered, the hardware modifications went into products and the complaints from customers dropped to, essentially, zero.
Finally, Tom came into a Monday morning meeting and said, "Well, I think we've done it. We finally have a great product that we can be proud of. Our customers are happy."
Now there was no doubt in my mind that it was so.
(P.S. Throughout our existence as a product development team, our team had the reputation of having the best team relationships and the best response time to product development and product issues of any team in the company.)
What would you have done?
Email me with your suggestions. I'm very interested in your thoughts.
Good luck and be well,
Steven
A mutually agreed working structure
Establish a clear, strong, clean working relationship that allows you as manager and the contractors to reach a mutually agreed-to working structure. Ideally, the impetus in achieving this out to be on both you as a manager and the contractor.
Be well,
Dwika-ExecuTrain
"How can people be so dumb? I thought I was hiring professionals."
by: Steven Cerri
Here's the situation.
A current coaching client called me (before he was a client) in a state of severe upset. He is managing a relatively large software development project for a web portal and, in an effort to contain costs, he has contracted out much of the work. He has tapped several of the contracting portals such as enlace, oDesk, Outsource Solutions, and he has hired, what he thought, was a good team of programmers and designers. He gave them his requests and then sat back and expected results.
In some cases he got very good results. Some of his contractors delivered top-notch work. Others delivered not-so-great results. But in all cases, my client used his preferred management style. He would reach out to the contractors via email, or IM and expect to know what the status of his project was. In nearly every case their work style didn't match his management style. What do I mean by that?
In some cases, my client would email his contractors requesting information about the status of their projects. My client expected to hear back within a couple of hours. That's how he would have responded if he'd been pinged by his customer. Actually, one contractor didn't get back to him until a week later! And in several other cases his requests for status weren't answered until several days had passed.
In one case, the contractor delivered "buggy" code. When my client complained that it seemed that it wasn't tested properly, the contractor responded that regression testing was not included in his bid.
In another case, the contractor modified a portion of the web portal that was outside the scope of his work but because it was necessary to make his module function, he did it anyway. But he didn't inform my client of the changes and the whole portal went down.
After these events and many others, my soon to be client called at a loss for what to do to bring this project under control. He just didn't know what to do. He made statements like:
* I can't believe these people are so irresponsible. They write code and they don't even test it.
* I can't believe these people won't answer my emails or IMs in a timely manner. These people disappear for a week at a time.
* I've got contractors who won't bid on a task for a fixed price. They tell me it will cost as much as it will cost. I can't tell my customer that. I can't manage a project with "It will cost what it will cost!"
* Some of these people are really good technically, but I can't work with them.
That's the set-up. Now I'll tell you what happened.
The question I always ask is: "What do you want?"
While this might seem like a self-evident question it took my client considerable time to answer it. Because, for most technical managers who have a strong engineering/technical background, the answer is filled with contradictions and impossibilities.
At first his answers to this question were as follows:
* I want the best technical people.
* I want them to manage themselves. I don't have the time to manage them closely or to micromanage them.
* I want to communicate with my contractors the way I want to communicate with them and I don't want to chase them down.
* I want them to think and work like me.
Now my client wanted the above conditions within reasonable limits. He understood the impact of time differences on work and communication schedules, but he wanted the above conditions subject to reasonable impact due to distance.
Now you might look at his list and say, "That seems reasonable to me. I'm paying these people for their work. If they want to get paid they had better deliver. And I want to manage them the way I want to manage them."
Well, unfortunately, it doesn't work that way.
My suggested approach.
Over the course of several coaching sessions I helped my client take a very different approach to managing his contractors and things have turned around. He is now receiving the communications and results he always wanted.
Here is what I suggested and what my client did.
First, my client's attitude had to change, as follows:
* Whoever said that your contractors have to work like you do?
* Whoever said that your contractors have to think like you do?
* Whoever said that your contractors have to be willing to bid fixed-price?
* Whoever said that your contractors have to respond to your emails and IMs within two or three hours?
* Whoever said that your contractors can't "disappear" for a week at a time without "asking your permission"?
The fundamental issue for my client was that he had expectations that he didn't communicate to his contractors, and then when the contractors didn't live up to them, he got upset. Well who's responsibility is that; the contractor or my client?
I'll state it differently. When a contractor doesn't deliver on an unexpressed expectation of the manager, who is responsible? We can even generalize this more. When a direct report doesn't deliver on an unexpressed expectation of the manager, who is responsible?
As far as I'm concerned, in most cases, the responsibility for missed and/or unexpressed expectations is the responsibility of the manager.
As obvious as this statement seems, the challenge comes about because most technical managers and most engineers are loath to express their expectations. They don't like to tell people what they want. They consider other engineers to be professionals. They wouldn't want to be told what to deliver and they think that other engineers feel the same way. Therefore, they avoid those important, clarifying discussions that make all the difference in the world between success and failure. The goal is to express exactly what you expect in all facets of the project.
It doesn't have to look like micromanagement if it's done properly. In fact, I don't think micromanagement ever has to appear if the conversations that structure the project are conducted correctly.
What we did.
My client began to implement a series of conversations and processes that I suggested.
The conversations were used to establish common expectations and common ground. The conversations allowed my client and his contractors to come to agreement regarding philosophy, attitude, processes, requirements, and deliverables.
New and much more demanding processes were implemented. Documents defining requirements were implemented. Documents defining changes to design, requirements, functionality, and/or code were implemented. New processes were implemented so that reviews took place on a regularly scheduled basis.
My client had a habit of "dictating" to his contractors and then getting upset with them when they didn't meet his expectations. Now with these conversations and processes in place, he began asking his contractors for their suggestions. They became committed to the overall projects' success, not just to the success of their tasks.
Finally, he understood that having the very best programmers who won't communicate with him or provide visibility into their progress was not a good fit for him. In fact, he decided he'd rather hire a good programmer who works with him the way he likes, than a great programmer who wants to work "his own way". This, of course, matches what is often said about technical employees, "We hire engineers for their technical expertise, and fire them for their lack of fit".
The Bottom Line.
My client has been implementing the changes I suggested, some of which are laid out in this Ezine/Newsletter. And his project is turning around. He's bringing his projects and contractors under control. He's able to predict cost and schedule much more accurately now. And he is developing relationships with engineers, programmers, and designers that he has never meet in person, such that they are working together much more smoothly.
Working with contractors all over the world is a new requirement for managers and it's here to stay. It's not about fancy tracking software, although it can help. It's not about having the best and brightest on your team, although that may be useful in certain circumstances.
The key is knowing how to establish a clear, strong, clean working relationship that allows the manager and the contractors to reach a mutually agreed-to working structure. Ideally, the impetus in achieving this out to be on both the manager and the contractor. However, the reality is, in most cases, the responsibility for success on a contractor-developed-project, rests with the technical manager.
What would you have done?
Email me with your suggestions. I'm very interested in your thoughts.
Good luck and be well,
Steven
Be well,
Dwika-ExecuTrain
"How can people be so dumb? I thought I was hiring professionals."
by: Steven Cerri
Here's the situation.
A current coaching client called me (before he was a client) in a state of severe upset. He is managing a relatively large software development project for a web portal and, in an effort to contain costs, he has contracted out much of the work. He has tapped several of the contracting portals such as enlace, oDesk, Outsource Solutions, and he has hired, what he thought, was a good team of programmers and designers. He gave them his requests and then sat back and expected results.
In some cases he got very good results. Some of his contractors delivered top-notch work. Others delivered not-so-great results. But in all cases, my client used his preferred management style. He would reach out to the contractors via email, or IM and expect to know what the status of his project was. In nearly every case their work style didn't match his management style. What do I mean by that?
In some cases, my client would email his contractors requesting information about the status of their projects. My client expected to hear back within a couple of hours. That's how he would have responded if he'd been pinged by his customer. Actually, one contractor didn't get back to him until a week later! And in several other cases his requests for status weren't answered until several days had passed.
In one case, the contractor delivered "buggy" code. When my client complained that it seemed that it wasn't tested properly, the contractor responded that regression testing was not included in his bid.
In another case, the contractor modified a portion of the web portal that was outside the scope of his work but because it was necessary to make his module function, he did it anyway. But he didn't inform my client of the changes and the whole portal went down.
After these events and many others, my soon to be client called at a loss for what to do to bring this project under control. He just didn't know what to do. He made statements like:
* I can't believe these people are so irresponsible. They write code and they don't even test it.
* I can't believe these people won't answer my emails or IMs in a timely manner. These people disappear for a week at a time.
* I've got contractors who won't bid on a task for a fixed price. They tell me it will cost as much as it will cost. I can't tell my customer that. I can't manage a project with "It will cost what it will cost!"
* Some of these people are really good technically, but I can't work with them.
That's the set-up. Now I'll tell you what happened.
The question I always ask is: "What do you want?"
While this might seem like a self-evident question it took my client considerable time to answer it. Because, for most technical managers who have a strong engineering/technical background, the answer is filled with contradictions and impossibilities.
At first his answers to this question were as follows:
* I want the best technical people.
* I want them to manage themselves. I don't have the time to manage them closely or to micromanage them.
* I want to communicate with my contractors the way I want to communicate with them and I don't want to chase them down.
* I want them to think and work like me.
Now my client wanted the above conditions within reasonable limits. He understood the impact of time differences on work and communication schedules, but he wanted the above conditions subject to reasonable impact due to distance.
Now you might look at his list and say, "That seems reasonable to me. I'm paying these people for their work. If they want to get paid they had better deliver. And I want to manage them the way I want to manage them."
Well, unfortunately, it doesn't work that way.
My suggested approach.
Over the course of several coaching sessions I helped my client take a very different approach to managing his contractors and things have turned around. He is now receiving the communications and results he always wanted.
Here is what I suggested and what my client did.
First, my client's attitude had to change, as follows:
* Whoever said that your contractors have to work like you do?
* Whoever said that your contractors have to think like you do?
* Whoever said that your contractors have to be willing to bid fixed-price?
* Whoever said that your contractors have to respond to your emails and IMs within two or three hours?
* Whoever said that your contractors can't "disappear" for a week at a time without "asking your permission"?
The fundamental issue for my client was that he had expectations that he didn't communicate to his contractors, and then when the contractors didn't live up to them, he got upset. Well who's responsibility is that; the contractor or my client?
I'll state it differently. When a contractor doesn't deliver on an unexpressed expectation of the manager, who is responsible? We can even generalize this more. When a direct report doesn't deliver on an unexpressed expectation of the manager, who is responsible?
As far as I'm concerned, in most cases, the responsibility for missed and/or unexpressed expectations is the responsibility of the manager.
As obvious as this statement seems, the challenge comes about because most technical managers and most engineers are loath to express their expectations. They don't like to tell people what they want. They consider other engineers to be professionals. They wouldn't want to be told what to deliver and they think that other engineers feel the same way. Therefore, they avoid those important, clarifying discussions that make all the difference in the world between success and failure. The goal is to express exactly what you expect in all facets of the project.
It doesn't have to look like micromanagement if it's done properly. In fact, I don't think micromanagement ever has to appear if the conversations that structure the project are conducted correctly.
What we did.
My client began to implement a series of conversations and processes that I suggested.
The conversations were used to establish common expectations and common ground. The conversations allowed my client and his contractors to come to agreement regarding philosophy, attitude, processes, requirements, and deliverables.
New and much more demanding processes were implemented. Documents defining requirements were implemented. Documents defining changes to design, requirements, functionality, and/or code were implemented. New processes were implemented so that reviews took place on a regularly scheduled basis.
My client had a habit of "dictating" to his contractors and then getting upset with them when they didn't meet his expectations. Now with these conversations and processes in place, he began asking his contractors for their suggestions. They became committed to the overall projects' success, not just to the success of their tasks.
Finally, he understood that having the very best programmers who won't communicate with him or provide visibility into their progress was not a good fit for him. In fact, he decided he'd rather hire a good programmer who works with him the way he likes, than a great programmer who wants to work "his own way". This, of course, matches what is often said about technical employees, "We hire engineers for their technical expertise, and fire them for their lack of fit".
The Bottom Line.
My client has been implementing the changes I suggested, some of which are laid out in this Ezine/Newsletter. And his project is turning around. He's bringing his projects and contractors under control. He's able to predict cost and schedule much more accurately now. And he is developing relationships with engineers, programmers, and designers that he has never meet in person, such that they are working together much more smoothly.
Working with contractors all over the world is a new requirement for managers and it's here to stay. It's not about fancy tracking software, although it can help. It's not about having the best and brightest on your team, although that may be useful in certain circumstances.
The key is knowing how to establish a clear, strong, clean working relationship that allows the manager and the contractors to reach a mutually agreed-to working structure. Ideally, the impetus in achieving this out to be on both the manager and the contractor. However, the reality is, in most cases, the responsibility for success on a contractor-developed-project, rests with the technical manager.
What would you have done?
Email me with your suggestions. I'm very interested in your thoughts.
Good luck and be well,
Steven
Langganan:
Postingan (Atom)