Rodney, how did the meeting with the Senior Director go? Did he ask about the router replacement schedule?
Great. I took total credit for your work and told him I’d solved the entire thing!
Oh good. I was afraid you’d forget to give me any credit.
Josh, the engineer I was talking to knew that I had done nothing of the sort. Part of the reason our maintenance windows went as well as they did was that the engineers felt safe enough to focus just on the work to be done. No one had to worry about trying to also make sure they looked good.
I’ve talked before about about joking with my team (Yeah, But You Guys Are Screw Ups.) Humor, even good natured teasing, is often a risky endeavor. Part of what makes something funny, is that it’s unexpected. Telling Josh I’d stolen the credit is only funny if Josh absolutely believes I would never steal credit. If he has even a slight suspicion that I might fail to properly credit him, my joke is going to sound more like gloating. And if that suspicion exists, then engineers and team members are going to lose focus on the common goals of the team and instead will start focusing on their own reputations and goals.
I was very careful to cultivate a culture of 100% trust on my teams. Rather than stealing credit when meeting with our senior executives, my prime goal was to give away as much credit as possible. It’s ironic in a way that the more you give credit to your team, the more you are viewed as a successful team manager or project leader. The rule I tried to follow was:
Be very specific when reporting good work. Give names and specific examples.
Be very general when reporting problems. Use passive voice and shoulder as much blame as you possibly can.
At this point some of you are saying, “What an idiot. He’s going to torpedo his career.” I know it looks that way, but I’ve seen this principal work. And it works for two reasons. Management doesn’t want to manage your team and your project. They expect you to do that.
Your team, especially if it’s a team of engineers or programmers, does not want to talk to management. They expect you to do that. So, you’ve got those below you on the org chart and those above you on the org chart looking at you to literally be the man in the middle.
I’ve noticed that reports get smaller and smaller the higher they go up the org chart. I might have a 10 slide PowerPoint deck to explain a new project to my team. I will cut that down to 3 for my boss. He will ask me to cut it down to one for his boss. And that guy will ask for two bullet points for his presentation to his boss.
It’s the same thing with project work. The higher up the org you go, the less they want to hear. I’ve often been asked to boil down my project status to a single red or green indicator. In that environment, it’s easy to lose sight of the fact that engineers are doing a lot of work to get that green status light. It’s the job of the project manager to make sure that senior management hears about truly exceptional work. Again, like any other time, you get a very short period of time to share your success story. I once had an engineer step out of his area to assist on a task and he literally saved us from 6 hours of unscheduled downtime. THAT engineer got mentioned in the meeting with the Senior Executive.
But, what about describing problems in passive voice and taking the blame? Well, in addition to short status reports, executives also value loyalty. It sounds a little corny, but in every organization I’ve worked for, the executives really valued people who believed in the company. So, if they hear you being disloyal to a team member by “throwing them under the bus,” they are naturally going to suspect your loyalty to THEIR objectives and the company is weak.
I have had setbacks in my projects, like all projects have. When I report those setbacks, I make it a point to say something like, “The backups didn’t get done on time and that caused a problem.” My English teachers in college would have been all over that sentence. It’s passive. It’s weak. It lacks focus and direction. And I wrote it that way on purpose. Of course I know why the backups didn’t get done. And generally there is name attached to that failure. However, I also know that I need that engineer to buy into my future projects. So, I would identify the problem and put measures in place to fix it for next time, but I gain nothing by shaming him in front of management. And I lose a lot.
If pressed, “Why didn’t the backups get done?” I’ll generally take as much blame as possible. “I didn’t communicate the seriousness of my request to the backup team, so it didn’t get prioritized high enough to run last night.”
Did you see what I did there? “I didn’t communicate well,” is a very direct statement. “It didn’t get prioritized,” is right back to passive voice. Generally this is enough to satisfy most executives in a briefing. Very rarely, I’ve been pressed even further. “Who was responsible for actually running them?” In that case, you really have no choice. You have to give up an engineer.
I used this approach when one of my engineers deleted an entire department out of our Active Directory. (He Deserved To Be Fired.) It was impossible to shield my engineer. Fortunately, I was able to save his job, but only just barely.
If your team knows that you take the blame and share the credit, they will move mountains for you. If they understand that you are loyal to them when you are briefing the senior execs, they will also be loyal to you when it comes time to do the hard things to get your project done. But, it has got to be sincere. If you even once take credit that should have gone to, or could have gone to the team, they will find out and you’ll find yourself very short of resources when you need them to make that extra push.
If you want loyalty. . .be loyal.
Rodney M Bliss is an author, columnist and IT Consultant. He lives in Pleasant Grove, UT with his lovely wife and thirteen children.