Management for technologists
#11-10-16-06: Micro-Management or Bust!
Micro-Management or Bust
Managing for results AND empowerment
Posted by Steven Cerri on Monday, October 16, 2006
Good evening!
It seems lately that everywhere I turn, much of what I read about management and leadership keeps pointing to the same set of management deficiencies. It may be the major issue of managers and leaders; not just technical managers and leaders, but all managers and leaders. And quite simply it’s the inability of managers to manage so as to achieve results. Do any of the following three scenarios ring true for you?
1. You are a new manager. You have been given responsibility for a project and you have also been given three direct reports. The direct reports are all technically competent people. They have been out of school for several years and have been accomplished individual contributors. You sit down with them, discuss the tasks they will each be doing and you then send them on their way to accomplish their tasks. At the end of their respective task schedules, none of them has completed their tasks as they said they would, either on time or to the level of detail they and you anticipated. What has gone wrong and what should you have done?
2. You have a disruptive direct report. This direct report is constantly challenging your authority when they are alone with you. When you and they are in a team meeting, the direct report seems cooperative. But when you are not there, this direct report tends to undermine you in front of other people. This direct report doesn’t seem to feel the sense of commitment regarding getting tasks done on time that you do. Missing a schedule is just not that big a deal.
3. You give a task to a direct report. This direct report has a mixed track record. The direct report sometimes completes tasks on schedule. Other times they miss their schedule. You don’t want to be known as a “micro-manager” but you are uncertain if the person will complete their task if you give them an independent hand. But you choose to give the person a good deal of independence anyway. The project slips and the direct report has an excuse for the inability to complete the task on time. After several attempts to give this person an independent hand you decide to step in and manage them closely so the task can get done. What went wrong? What should you do differently next time, if anything?
Do any of these scenarios sound familiar? Do you have direct reports who behave like this? Should you manage closely or manage loosely? Should you ignore how people want to be managed and just manage to get the task completed?
Over the last several months, much of what I’ve read in business and technology magazines, and much of what I’ve heard from my clients, points to this one issue; how does a technology manager manage to get results and build a sense of empowerment and independence in employees at the same time? Or should a manager even try to accomplish these seemingly competing outcomes?
WHAT TO DO?
In order to answer these questions I first want to establish some common ground. And the first area of common ground is this: I want us to agree that the only tool a manager has is communication. It doesn’t matter if you have hire and fire authority of if you don’t; you still only have your ability to communicate as your tool of influence. Threatening an employee with termination if they don’t get the job done is still just a means of communication. A means called “intimidation”. So let’s agree that as a manager your most powerful and only tool is communication.
If it is true that communication is your only tool, then the next question is “How do you use communication to manage for results without making an employee feel that you do not trust them, that you don’t want them to make decisions; basically how do you manage and yet make an employee feel that they are empowered to make certain decisions on their own?
These will be the questions I’ll address in the next couple of blogs and I’ll use the three examples I presented at the beginning of this blog as examples.
See you Thursday.
Be well
Steven Cerri
Posted by Steven Cerri on 10/16 at 09:26 PM Engineer to Technical Manager • Management • Engineering Management • Management for engineers • Management for technologists • Technical Management • Inter-Personal People Skills • Communication for engineers • Soft Skills for engineers • Soft Skills for Technologists • (0) Comments • Permalink
#10-10-12-06: Management Myths
Management Myths
Part-time technical and part-time manager
Posted by Steven Cerri on Thursday, October 12, 2006
Good evening!
As I indicated in my previous blog, I taught a class this week on being a technical professional and technical manager at the same time. This is usually the situation that arises when a technical person is first promoted to management. They are promoted to a position that is part-time technical and part-time manager. During the class I taught, we discussed how and why a technical person is promoted to this “schizophrenic” situation; a situation in which they have to shift from technical to manager and back and forth and back and forth. It seems pretty difficult to be both at the same time and yet this condition seems to occur with regularity.
So I thought this would be a good time to discuss the thinking process that managers go through when they promote their best technical people to part-time manager and part-time technical individual contributor.
The first point I want to make is that very, very rarely does a full-time technical person get promoted to a position of full-time technical manager, and for good reason. Experience counts for something. Judgment is important. It’s very risky to take someone who has not done management work and promote them to full-time manager. So it makes sense that a technical person will be given management responsibilities in a piecemeal approach. It’s more like a proof of concept process.
However, the issue is that it’s usually a proof of concept without adequate training. Most technical professionals get very little if any training before they are given their first management assignment. And for this reason, most technical professionals who get their first promotion to part-time manager have a very difficult time.
It’s not uncommon for a person who is 50% technical person and 50% technical manager (i.e., it might be a team lead position, or manager of a small project with one or two people) to get frustrated because the team he or she is managing isn’t delivering their tasks on time or in budget. The new manager is often trying not to look like a “micro-manager” and yet by taking such a “hands-off” approach, the tasks aren’t getting done. This was exactly the situation facing one of the students in this week’s class.
So let’s talk first about how the best technical professionals get promoted to this position of part-time technical and part-time manager usually without adequate training. Why would a manager pick the best technical person and promote them out of the job they do so well into a new job without training them?”
From the manager’s point of view, the best technical employee may seem to get their work done very quickly and effectively, and therefore, may have something to teach other employees. But most of the time, the reason the manager picks the best technical person is because the manager certainly can’t pick the worst technical person to manage technical people who are more competent.
So once the best technical person is targeted for promotion to part-time manager, the manager has to justify the selection. The rationale for the selection process is comprised of several myths. I call these myths, “The Myths of Early Management Selection”.
Myth #1
The first Myth is what I call: “Good Technical Job: Why Not Manage?” The thought here is that “if you can do your technical work well you can obviously manage people doing the same or similar work.” Underlying this myth is the belief that you can manage a small team or a small project because managing people doing the same work you do is easy.” It is, isn’t it? This myth completely ignores the fact that your technical work and the management job are completely different disciplines.
Myth #2
The second Myth is what I call “Osmosis”. This myth says “Don’t worry. Just hang out and assist a good manager in the company and you’ll learn what you need to learn from that manager.” The unfortunate part about this myth is that while you may well learn some good practices you’ll also pick up all the weaknesses and faults of your teaching manager. Myth #2 produces a series of managers that all have the same strengths and the same weaknesses.
Myth #3
The third Myth #3 is what I call, “Trial by fire”. It translates into a philosophy which is something like, just jump in there and do the management job. It’s a “sink or swim” approach. It’s similar to throwing a child who can’t swim off the deep end of the pool expecting them to dog paddle their way to the edge of the pool and thereby, gain the ability to swim. Or maybe it’s like putting a novice in the left seat of an airliner and expecting them to fly you from San Francisco to New York safely. By any stretch of the imagination, Myth #3 is a looser.
The point I’m driving home is that none of these myths include management training. They are based on the basic assumption that technical management, at least in the early stages, is a no-brainer. It’s easy. It’s obvious.
The reality is that technical people haven’t taken any training to speak of by the time they have graduated from college. They’ve focused most, if not all their time, on their technical work.
And the necessary training I’m talking about is not training in Microsoft Project, or in budgets, or schedules. I’m talking about the skills of
Communication;
Motivation;
Conflict Resolution;
Delegation;
Management Style Selction;
Personal Flexibility
and other inter-personal skills that make the difference between success and failure.
Before taking your first step up the technology management ladder, get some preparation in the inter-personal skills that truly make a manager a manager.
Be well
Steven Cerri
Posted by Steven Cerri on 10/12 at 06:49 PM Engineer to Technical Manager • Becoming a manager • Management • Engineering Management • Management for engineers • Management for technologists • Technical Management • Inter-Personal People Skills • (0) Comments • Permalink
#8-10-05-06: Info Sharing Boss
My Boss Won’t Share Information
Talk to me!
Posted by Steven Cerri on Thursday, October 5, 2006
Good morning!
Once again, I was reading a magazine and thought I was dreaming. This time it was the October 9, 2006 edition of BusinessWeek. There happens to be a weekly column called “Analyze This”. The question came from C.J. of New York City. C.J. wrote, “I work with a top executive who regularly fails to share information I need. I wind up hearing about concerns he has or steps he has taken from colleagues in other departments. Then I have to scramble to adjust a deadline or a budget, sometimes narrowly averting disaster. During project postmortems with him, some of us have broached the issue by pointing out problems that might have been avoided with better communication. He’s quick to apologize, but his behavior doesn’t change. I’m stymied.”
Now, who among us with some experience hasn’t run into a person like this, be they our boss or a colleague? They’re out there. It’s clear that this isn’t the best working relationship and C.J. is understandably “stymied”.
What I found interesting was the response C.J. got from the column author. The author began his response by stating what he thought “psychoanalysts” would call this person. Some 343 words were devoted to the article (yes, I did a word count on the column). Of those 343 words, 317 were devoted to the psychoanalysis of C.J.’s boss and 26 words were devoted to suggestions that C.J. could implement to enhance communication with the boss. In the final analysis, the column suggested that there probably wasn’t much C.J. could do, that C.J. would probably have to continue working around the boss, and that C.J. should “try to establish greater trust with (the boss) in other ways, and to tactfully reinforce (the boss’) rare moments of openness.” I have to tell you, 26 words out of 343 doesn’t make a very useful response, even in a short, cramped, magazine column.
Now in the world of technical professionals and technical management, this BusinessWeek response wouldn’t fly. Probably more than any other group I’ve worked with, technical professionals and technical managers are very leery of “psycho-bable”. If you want to loose a technical professional just start talking about the psychological implications of their childhood or of the childhood of someone they work with.
Frankly I agree. As a technical professional and a technical manager, I’m paid for the necessary and appropriate behaviors that lead to results. I’m not paid for psychoanalysis.
So, how would I go about dealing with the person C.J. is working with? Whether it’s my boss, and it has been, or whether it’s one of my colleagues, and it has been, the approach is basically the same. Let’s assume that my situation is exactly like C.J.’s. My boss has a tendency to withhold information. My approach follows some very basic, fundamental rules or theorems of communication and relationships.
The first theorem is: No one exists in a vacuum. We all exist in “relationship to one another.”
So when I think about communicating with my boss in order to get an open communication, I have to think about a “communication system” made up of me and my boss. This is not just about my boss and his behavior. It is about my boss’ behavior in relation to me. It’s about our communication process and I’m going to be looking at how I can communicate with my boss in order to alter his openness. And it will be my communication that will either motivate him to share information or not. (My assumption here is that there is a possibility for openness, and therefore, I can get the openness to show up at some point with the right “stimulus”.)
The second theorem is: Every behavior that a person exhibits has some positive purpose, some positive intention, from their point of view.
Therefore, my boss is withholding information because he thinks there is something positive he is getting out of it. I’m not interested in his childhood or his “terrible twos”.
For example, I once worked with a colleague who always, and I mean always, took a contrary point of view to any new idea that I or someone else put forward. One day I asked him what the positive purpose of his approach was. He nonchalantly indicated that he felt it was his mission to make certain that we didn’t overlook any potential flaw that could cause us great difficulty on our project, down stream. It was a reasonable goal but his implementation sucked! But now I understood and I could work with him to support his need to find “dangers” while moving the project forward.
Also, in his question, C.J. indicates that in the “project postmortems with him, some of us have broached the issue by pointing out problems that might have been avoided with better communication. He’s quick to apologize, but his behavior doesn’t change.” C.J. is falling down on the job here. Telling his boss about “problems that might have been avoided with better communication” is not explaining to C.J.’s boss what the issue really is. Saying that problems could be avoided with more open communication isn’t explaining to the boss that the boss has a habit of withholding information. C.J. is only saying we would all be better off with better communication. That goes without saying. C.J. has to step up to the plate here and explain that his boss has a behavioral style that puts projects and people consistently at risk. If C.J. or others on the team aren’t willing to be this open how can they expect their boss to understand his need to do the same?
The third theorem is: If I can find out my boss’ positive outcome, his positive intention, I might be able to structure my conversations and requests for information so that giving me the information supports his outcome rather than seeming to undermine it.
Think of it this way. If my request for information seems to my boss to be contrary to the outcome he desires from withholding, he’ll just withhold more stringently. The way I find out my bosses positive outcome is to ask him. Many times I’ve asked these questions;
“I’m curious, what is it that you are attempting to accomplish by not giving me all the information you have about a topic as soon as you have it?” (By the way, the boss may not even know that he is withholding important information.)
Or,
“What is it that is important to you about holding information close to you and not letting it out?”
Or,
“There seems to be some information that you keep and act on. Is there something special or unique about that information that causes you not to share it with me and others?”
You may have to ask these questions over and over, perhaps over several weeks time but sooner or later you will get the answer. And when you get the answer you’ll know that it’s IT! There isn’t any way I can tell you what the answer will be or how you’ll know it. It will be context specific and that means that it will relate to the situation at hand.
Here’s a real-world example. I once had a software engineer who wouldn’t release his software to the customer. The project was a rapid-prototype for a database user interface. The program manager didn’t know how to get the software out of the developer’s hands and into the customer’s hands for first stage evaluation without making a scene. I was called in and after talking to the engineer for a few minutes I asked my question, “What’s important to you about holding on to the software and not releasing it now?” His response was that he wanted to pack as many features into the interface as possible so the customer could give him the maximum amount of feedback.
Once again, a reasonable goal. What he didn’t realize was that if he released the software immediately, he could get it back from the customer in time to perform one more iteration and get the customer’s feedback a second time. When I explained to him that a quick release would guarantee that he would actually get two cycles from the customer instead of one… the software was in the customer’s hands the next day.
I don’t know what C.J.’s boss is trying to accomplish by withholding information. However, what I do know is C.J. has a lot of options still open and available that he hasn’t yet tried. Before C.J. makes a habit of going around the boss or of trying to compliment the boss when he opens up, C.J. has plenty of proactive questioning and discussing that can be done with the boss. Nine times out of ten, my experience is that you can be successful in these kinds of situations, regardless of what Freud said.
Be well
Steven Cerri
Posted by Steven Cerri on 10/04 at 09:41 PM Management • Engineering Management • Management for engineers • Management for technologists • Technical Management • Inter-Personal People Skills • Communication for engineers • Soft Skills for engineers • Soft Skills for Technologists • (0) Comments • Permalink
