Nobody likes to feel or seem stupid. But when somebody describes a detailed technical solution or gives a complex business explanation of a problem it sometimes just washes right over you and there is a temptation to nod wisely in agreement and move on. That’s when the danger signals should start flashing. Because if the person providing the solution or explanation is a real team player working for the benefit of the project, they wouldn’t put you, or anyone else on the project, in the position where you simply have to take their word for something. If it really is so technical or so complex most people won’t understand it, they would explain why to you first and not spring it on you.
Any follower of the Dilbert cartoons will know Wally, the lazy office skiver. Now, in the cartoon below Wally has done his homework in understanding his target audience. In this case it’s the over promoted, know-nothing CEO. So Wally knows he can feed the CEO any plausible sounding line of waffle and have him agree because the CEO doesn’t know anything like enough to challenge him. The end result is Wally getting a totally false air of knowledge and superiority.
For the project manager this is extremely dangerous. In reality few executives are as dumb as the Dilbert CEO or Pointy Haired Boss. There may not be open challenges in the meeting but there most likely will be private ones afterwards.
What can you do about it?
I make a conscious effort to get at least a basic understanding of the technical and business issues around any project or programme I am involved in. That way I can evaluate whether an explanation sounds reasonable or is going off into the deep end or, worse still, is stretching credibility. I also watch the room to see if others appear to be struggling to comprehend what is being said. If I sense others are getting lost, or I am struggling myself, I put a stop to it there and ask for an offline conversation to go into the detail.
I also lay out ground rules with my team about how I expect them to communicate and at what level. No techie gobbledegook in front of the business etc. I also set out rules for how we treat each other, which include rules about not ‘points scoring’ or ‘blind-siding’ other members of the team in meetings or communications going outside the project team. The golden rule is, if there is any doubt about the clarity of an explanation, check first and avoid losing the audience.
The same applies to you
The same rules apply when you, as project manager, are communicating to stakeholders or the project steering committee or board. Don’t try to hoodwink people with overly complex descriptions, or try to hide or gloss over a failing by getting in to detail elsewhere. You’ll only get challenged and caught out. If you are asked a question and don’t know the answer, don’t bluster and be evasive. Say you don’t know and give a commitment to finding the answer.
Don’t stand for or deliver bullshit, the line that bullshit baffles brains just isn’t true.
What experiences attempted ‘bullshit baffles brains‘ have you witnessed? Post a comment below.