Tuesday, July 30, 2013


Here are a couple more tips to help get on, and stay on, your boss's good side.

Nothing will please your boss more than getting blindsided from his boss or someone from another department. You wouldn’t like it much either. Certainly, as discussed earlier, you can’t expect to be up-to-the-minute current on everything happening in your area, and there’s no reason to feel that you have to keep your boss up to that level either. Doing that is too big a burden on either your own people or on you. You have to carefully pick the items of interest and present them in an appropriate timeframe.

Certainly, anything major, or anything that has direct negative implications on other departments or on customers is a good candidate for a quick update to the boss. You have to ensure that should he get a call from one of his affected peers, or from his own boss, that he’s ready with at least a little bit of information on the subject. It’s okay not to know about absolutely everything that’s going on, but for something major, he will look like a completely out-of-touch moron if his response to a critical call is, “I don’t know what you’re talking about.”

My methodology for these situations is to pop in with words like, “Hey I need to give you a quick heads-up on a situation that’s brewing…” Your boss will be trained to know what this entails and he’ll understand that it’s time for a short burst of real concentration. You’re about to give him information he may actually need to know in the near future. Give him the quick summary of what’s going on, who’s involved, what the “likely” outcomes may be, and the next steps your folks are taking. When he gets the call from whoever, he will appear totally in-touch and on top of things.

By the way, when you do your “pop ins” for these situations or any other, don’t assume that just because his door is open that he’s ready to engage in conversation with you. Some folks might be, and you’ll learn if that’s the case. But, always assume otherwise. My wording is, “Hey, I’ve got a couple important things to go over with you. Let me know as soon as you’ve got a few minutes.” He will appreciate you giving him the flexibility to prioritize you into his other happenings.


Nobody likes a whiner. It’s okay to have problems or complaints, but how many times does it take of one of your guys coming to complain at you before you start hiding under the desk to avoid him? Don’t fill that role for your boss either.

Just as you should encourage your own people to do, when you raise an issue with your boss, try to do so in a constructive manner. Spend some time before the discussion thinking through possible causes and solutions, even if the power to implement the solution is completely outside your scope of control. When you have your discussion, adding your thoughtful analysis of the causes and solutions will change your boss’s entire perception of the meeting from “how can I get out of here” to “there’re some good ideas here.”

Your boss is probably in the better position to actually act on the information you’re discussing. It may require meetings with his boss or peers, but he can probably actually work to fix whatever your original complaint was. When that happens, a lot more people “win” since the problem was probably shared by many. The moron whines and moans. Managers solve problems.

Don't Save The Punch Line

Relating problematic information to your boss in typical story-telling language is not likely to go over well. Even if you can keep the story brief, your boss is going to start getting antsy to know where the story is going.
“First we did this, then we did this. Then this happened, and then there was even more of this. But another guy did this and this, and…”
By this point, your boss is a nervous wreck. He’s not even listening to you much now. He’s just wondering if everything came out okay, or if someone is dead.

Always start out with the punch line.
“I need to let you know we had an accident in the factory, but everybody is fine and there won’t be any negative affects on production. Do you want the details?”
Now he can relax. He’ll let you know just how much extra detail he needs now, and what can wait until later.

A few more bossy tips in the next installment...

Friday, July 19, 2013

Managing your boss

The importance of the relationship you build with your boss cannot be overstated. No one can do more to advance or hinder your career than he can. Regardless of your boss’s management style, good or bad, hands-off approach or micro-manager, you can still learn from him. And learning is always a good thing.

Keep in mind that when I use the word “boss” here, although I am primarily referring to the person
you report directly to, in many ways much of this information will apply to your higher-level superiors as well -- your boss's boss, his boss, etc...

What's the most important thing you can do to please your boss? Well, probably perform really really well, and finish all the tasks assigned to you or your group in record time. But, to get your relationship off on the right foot, from the first time you meet your boss, you need to start...

Learning His Style

Thankfully, most bosses are all about results, and that’s a welcome trait. As the competent manager you are, you should be able to wow him with your ability to get actual work accomplished by your team. But everyone has some degree of sensitivity towards how you handle the relationship from your end. Improperly done, you can set the relationship up for disaster, regardless of how well you actually deliver results. Adjusting to your boss’s operation and interaction requirements is vital to your survival.

In your initial interactions with your boss, begin to take note of what kind of communication styles he enjoys, and what styles seem to turn him off. Some guys are very detail oriented, and they enjoy hearing all those juicy details. Others want the executive summary. Still others don’t want to know anything about a topic unless it requires action on their part. Don’t mistake that attitude for disinterest in your activities. Take it as a sign of trust that you can handle things and that you’ll alert him when his time is really needed.

Whichever category he falls into, it doesn’t make him a “good” or “bad” boss – it indicates his preferred communication style.

How can you tell how much detail your boss needs? Start with the summary, then begin going into more detail. Watch for the eyes glazing over, the attention shift to whatever’s going on outside the window, or the sudden interest in email or cell phone. It doesn’t take long to zero in on his preferred level of detail. Once you think you understand what he needs, in future briefings just go to that level of detail and stop. If he wants more information, he’ll ask. If he does that consistently, you can probably assume that he generally desires a bit more, and you can adjust your style to fit.

When you have communications of a written nature, such as a report, you need to play to multiple levels since it will probably be “read” by a variety of folks. The reason I placed the word “read” in quotes is because many people who will need to read it – won’t. At most, they will skim it. Therefore, it’s important to include an “Executive Summary” section at the top that details the key elements of the report in one paragraph – which some also probably won’t read. Sad, but true.

Next, learn how much independence he wishes for you to have. Again, some guys are going to want to sign off on much more than others will. If you are starting from a position of trust, he may be perfectly happy to let you fly on your own unless you feel you need assistance. It is vital to stay close to whatever level of independence he wishes for you to have and not stray much higher or lower than that point. If you are coming to him for approvals way more than he thinks necessary, he’s going to think you’re overly burdensome and incapable of independent thought. If you seize far more independence than he wishes, he’s going to think you are a loner and maybe a bit out of control. Stick close to the level he wants and you will, over time, earn additional independence.

In the next few issues of this blog, a half-dozen or so additional ways to get on, and stay on, your boss's good side.

Tuesday, July 9, 2013


Let's talk about the process for setting up goals for your team. In this context, a goal is a statement of some work to be performed. Examples of goals might be to change a process, get a project completed according to some basic parameters, or perform a reorganization.

Commitment to those goals is the key factor to success. Sure, you can impose them on your folks if you wish. As Captain Ramius told his staff in The Hunt for Red October, “When he reached the new world, Cortez burned his ships. As a result, his men were well motivated.” Throwing a commitment like that to your team is a guaranteed failure. But probably a better way to handle things is to talk to your staff about the goals.  It is critical that the team determine what they are able to do, and then commit that back to you.

But what should a goal look like? Answer: unless absolutely necessary, write goals around projects, not processes.

In general, goals created for the completion of projects will be the most useful, allowing other changes to happen as needed in support of that objective. For instance, you may write two different goals, one for a project, and one to overhaul some process in some way. However, you might find that the two goals are in conflict with each other. What if the project team determines that the most efficient way of completing the project is to leave that particular process alone or change it some other way than you specified? The overall project is what’s key, so leaving more options to the team for dealing with their own processes and tools is much preferred.

How specific should the goals be? Answer: keep them general!

So, we want to create this year’s goals. We know the big projects we’ll be working on, but we don’t know the exact requirements, much less have any estimates for how long the work will actually take. Doesn’t matter. Especially if you work in an environment where the requirements can continually change during the project execution, you’ll never have them done.

I have seen so many goals written with such specificity that they never get met. Once the project is underway, somebody will change something than diverges from the overly-specific project goal. What do you do now? Rewrite everyone’s goal sheets to match? I’m sure you can imagine the hassle in dealing with that every time a change occurs. You could leave them alone, but now your people are working towards goals that are wrong. Is that better than simply not having goals anyway?

So maybe you just periodically review goals to see if they still reflect reality. How often? Monthly? Weekly? Hourly? What a waste of time! When you write your goals, don’t sweat the small stuff! Cover the basics, and leave the specifics out. Written properly, goals should clarify the intent and major parameters of the project. The unwritten details will be filled in as the project progresses. That doesn’t make them “bad” goals, it makes them “realistic” ones.

Take this example:
“Complete version 3 of the XXXX product, with major business value features included, no later than end of 3rd quarter, requiring no major corrections by the end of the year.”
Yes, that’s written fairly loosely – we don’t know what the “major business value features” are yet. Even if we did, you might change one or more of them before the project is actually completed – maybe adjusting for customer demand, and hopefully an accompanying increase in revenue. We don’t want to impede change simply because the goals were written too strictly. And we don’t want to have to go rewrite them, either.

How hard should the goals be to achieve? Answer: a good chance of success

Nothing will destroy motivation faster than a task that is simply impossible. You have to stay within “reasonable” parameters. Folks need to see the job as having a good chance of success. Sure, you need to press a little on some goals and make a small number of them very challenging. Despite sometimes thinking so, we are not omniscient. Just because we don’t know how to accomplish something, doesn’t mean that nobody knows. Entrepreneurial leaders are the kings of this technique. “I need this completely new product developed in 2 weeks.” You, personally, might not think it’s doable in that timeframe, but maybe you’re wrong. Maybe some creative guy can dream up a totally new way to get across the finish line in world-record time. Maybe, for him, it’s actually old hat, and that 2 weeks is twice as much time as he needs.

Just remember that because you think something is impossible doesn’t necessarily make it so. I’m not advocating impossible goals, but it’s OK to give the team a challenge. They will press back as much as they need to until you can all find a happy medium.

Objective or subjective goals? Answer: Mostly objective

Don’t fall into the trap of creating goals that are only subjectively measured. As much as possible, all milestones need to be absolutely demonstrable. You can either see it, or you can’t. Period. A goal like, “Be 50% complete with development” is a farce. There are so many ways of measuring “completeness,” and so many different opinions, you’ll never get anyone to agree. And that usually means that the goal will be completed “by default,” because you won’t want to spoil someone’s day with a failing grade. Keep it objective so that anyone can make the call. Demonstrable goals and milestones drive real performance and progress.

And don’t give credit for anything less than 100% completion. The goal didn’t say “almost”, it said “done”. As soon as you say “good enough” on 99%, or 95%, soon they’ll be expecting it on 90% or even lower. Stick to the goal.

How do I write all these goals for so many different people? Answer: DON'T!!!

Create YOUR OWN goals first. Do this in consultation with your teams to know what's reasonable. Once you have created your list of major goals for the year, they should be adopted downward throughout your organization. In this way, the goals for each of your own managers and for their people will all directly support your own goals. Each worker who has responsibility for any portion of one of the top goals should have that goal transcribed onto his own goals for the year – verbatim. That means that his goal will be the same as everyone else’s contributing to that project.

He will, of course, have a particular area of expertise. But, if something falls a little outside his direct area, having the more generic goal will entice him to help out. The message you are sending him is that just being successful at his own job isn’t enough. The project must succeed. He needs to do whatever is necessary to make that happen, and everyone wins or loses as a team.

On that note, if you have your own direct management team, you can send an even stronger message to them. They should each have every one of your goals as one of their own, even if their particular team is not involved in one of those goals. This will force them to play together better, help out whenever they can, and generally not play politics with their people or other resources.

Again, they all win or lose together. If you have the ability, you can adjust the relative weights of the goals to compensate for those items they truly have within their scope of control. Just don’t take any of them all the way down to 0%.

Setting goals can be a dumb, useless, exercise in irrelevance, or they can be useful. You pick.