Tuesday, February 7, 2012

Methods to Having Authority with None of the Responsibility

About a year into my career in the student assessment industry, our company had a large group meeting about a program where we discussed lessons learned. Running the meeting was our program manager (PM), who I had never seen until that day. Judging from the comments around the room, some people didn’t even know who he was.

The meeting seemed to be productive as members of the group laid out issues they found while trying to make their deadlines. Issues ranged from creeping scopes of work to a severe lack of personnel to not having a coherent master schedule. The PM wrote it all down on an easel.

As our allotted hour time limit approached, the PM stopped everyone and handed out a colorful sheet of paper. He didn’t have enough copies, claiming he didn’t realize so many people worked on the program. The paper contained a design made in PowerPoint that said, “Everyone Counts, Everyone is Accountable.” Then – POOF - the PM was gone, leaving all the notes from the easel behind.

After seeing the same type of thing a few times, I coined the name “dive bombing” for that style of management. Swoop in, sound authoritative, and disappear. Above all, don’t get your hands dirty. It’s a technique in trying to establish authority while shucking any type of accountability.

There is another form of dive bombing. In a more negative form, the dive bomber points out all the problems (real or perceived) very vociferously, then…POOF…disappears until the next meeting. There is no intent to suggest solutions or to work with anyone until the problems are addressed.





The Dragnet is usually done by a supervisor that was caught off-guard by something that should have been easy to see coming. A dragnet may go something like:


Supervisor: Why didn’t you tell me about the package?
Underling: I did, several times. I even emailed you a heads up twice.
Supervisor: Where is the package?
Underling: In the mailroom.
Supervisor: Which mailroom?
Underling: The one downstairs.
Supervisor: Is that where you were told to put it?
Underling: No, you wouldn’t answer me on where to put it. So I put it there for safe keeping.
Supervisor: A-HA! So, you were hiding the package instead of placing it where you were told! No WONDER I was left in the dark! We have high standards, you know!

A much uglier form of a dragnet gets personal, with one person investigating things such as an employee’s social habits, how much they are seen drinking after work, where they are using their company credit card, and who they talk to from competitor organizations. Anything to dig up dirt, discredit, and smear someone on the other end of a dispute. Unfortunately, this is a very real phenomenon.

A Yellow Herring is somewhat like a red herring. Where a red herring sends people into a different and incorrect direction, a yellow herring is purposefully laid out in numbers to distract. This is a complicated scenario where Group B is banking on Group A not successfully completing their portion of work on time. This way, Group B is without blame if deadlines are not met. Yellow herrings are best set under the guise of questions, such as, “is the VP okay with this process?” While the question may be completely irrelevant, the process has to be halted until someone is able to track down the VP and ask.

Akin to the yellow herring, Speed Bumping is assigning actual tasks or details with the intent to slow down a person or group. If an original task was to review a test form to be sure that keyed responses are correct, a speed bumper will add, “make sure that the fonts are consistent.”

A Phantom Checklist is a checklist that grows with phantom requirements after the work is done. The phantom checklister will ask, one by one, if specifications were met. The problem comes when the phantom checklister keeps asking questions until they get a “no”. That conversation may resemble:

Phantom Checklister (PC): Is the software compatible with PC and Mac?
Unaware Victim (UV): Yes
PC: Does is use less than 3 GB of space?
UV: Yes
PC: Does it have a clear welcome screen?
UV: Yes
PC: Does it make people feel good about themselves?
UV: Um, yes, I guess so.
PC: Does it make julienne fries?
UV: Of course not.
PC: Get back to the drawing board! You know our client has high expectations. I have worked so hard to build this relationship and will NOT stand by and let you destroy it with sub-standard work! We have high standards, you know!

Scope creep is a project management term to describe when the scope of work grows without commensurate changes in timeline or compensation. It is a nasty thorn to most program managers and is usually caused by a sly client. Responsibility Creep, by contrast, is when some responsibilities prove to be too difficult or treacherous for someone and they migrate into someone else’s hands. The creep is almost always stealth and results in conversations like:

Scope Creeper: Why didn’t your group finish the edit log?
Unaware Victim: That is not in our realm. It is reserved for your group.
Scope Creeper: So we aren’t a team? Aren’t we ALL responsible for the success of this program? We have high standards, you know!

The Soviet Basketball technique may be the most sinister of them all. It is used less frequently than the other techniques, but can be much more damaging. The name comes from the 1972 Olympic basketball gold medal game between the Soviet Union and the United States. If you aren't familiar with the reference, read about it here.

To avoid a lengthy description, let’s cut straight to a real example. One of the duties of assessment people is to build test forms to match a blueprint and certain specifications. It’s not an easy thing to do and any error can put the company onto the front page of the newspaper…or at least in very hot water with the client. Program ABC (masking true identity) had strange specifications and a weak bank of test questions to use. The chances of error and missing the specifications were very high. Yet, the test forms were built that satisfied all criteria. Huge accomplishment, huge relief.

Just after completing the work, the specifications and blueprint changed and we had to start the process all over. And with less time. The job of our project leader was to avoid these types of changes after the work was completed. But alas, the specifications continued to change.

Again – success somehow. Again – a change in the specifications. Again – rebuild with even less time than before.

This went on for a month. The tests were built and rebuilt …until an error was committed and caught. It turns out that the error was perceived and not real; but the damage was done.

This program was doomed from the start for several reasons. Using a Soviet Basketball, the project leader was able to put any and all culpability for program failure on the worker bees.

And we lost a month of work time.