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

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 delievering 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 existance 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 estalbish positibve working relatiohsips with other deaprtments, 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,

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 judgement 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.

Check out the page http://stevencerri.com/index.php/articles/index/ (also known as the "FREE STUFF" button). There you'll find several articles and other useful information, all of it FREE.

Some of the Free Articles include...

• 10 Pitfalls to Advancing Up the Technology Management Ladder
• Definitions
• Being Right versus Being Effective
• Motivating People by Reference
• Case Studies
• So You Want To Be A Manager
• Mechanical Engineering Magazine Feature Article: Going Soft

 

The blog is updated every Monday.  (However, seveal of the most recent blogs were accidentally erased.  They will be reinstated soon.)  To check out the latest ideas go to:
steven's blog

 

Most of us believe that the behaviors that made us successful at one level of our technical career will make us successful at the next.  You might be surprised by the answer! (Check out the articles at the left)

Home

My Blog

Coaching

Training

Speaking

Products

Contact

Register for Coaching

Take that next step into your future with private tele-coaching or in-person coaching.

Call: 925-735-9500 and set up your 30 minute free interview or Skype stevencerri