Advice Line | Bob Lewis | InfoWorld | Dealing with an autocratic change agent | May 31, 2006 05:06 AM

MORE ENTRIES

Dealing with an autocratic change agent

May 31, 2006 | Comments: (0)

Dealing with an autocratic change agent

Dear Bob ...

I would appreciate your thoughts on the following situation.

Our company recently started a program to implement "radical change" in a particular business area. They hired an external contractor to create the program. This person (let's call him Dick) has now been hired as the overall Project Manager (still a contractor). I am a Systems Consultant (company employee) on this project - my role is to develop the overall IT solutions. Dick has made it clear that he is "in charge". To wit:

* He doesn't believe in stakeholder, consensus, or any consensus for that matter. He believes in imposing change (he has said exactly this).

* He will not hesitate to "throw out" systems methodology if it impedes the speed at which "he" can deliver. He has demonstrated often that he's not sure what systems methodology is and thinks all methodology is waterfall, despite efforts to educate him to the contrary.

* He does not believe in moving IT closer to the business - our role is to "deliver working software", not be partners in business change.

* His behavior demonstrates an "ends justify the means" approach to getting things done.

* He claims Senior Management has given him carte blanche to cut "whatever corners are necessary" to implement this program.

In spite of the above, I recognize he has a lot of knowledge in his area of expertise (change agent) and I believe his business plan is a good one.

How do I work with this guy? I report to the IT project manager (excellent manager), but have a functional reporting relationship to Dick - I want to work effectively with him. I believe in partnering with the business (which he doesn't). I fully endorse changing our processes when it makes logical sense to do so but we do have some rigor we CANNOT escape, e.g. SOX, and some we SHOULD NOT bypass in order to ensure quality and maintainability. Our dynamic is weird - Dick tends to speak to me in either a condescending manner as if I need his "wise guidance", or in a conspiratorial "it's just you and me" tone (I'm a younger female). I feel I'm being "played" much of the time. He also has claimed responsibility for my recent promotion, which is inaccurate. I want to be effective on this project, but I'm not sure how to approach this.

- Working for an egomaniac

Dear Working ...

Well, clearly the right course of action is to backstab him until he's thrown out, then bring in our consulting company to rescue the situation.

I'll even pay you a commission!

Okay, that isn't such a great solution. Among the many disadvantages is that we might get caught. Let's go for Plan B: Keep your head down and your nose clean.

Here's what's going to happen. Dick hasn't figured out the difference between being right and helping the organization be right enough. He also hasn't figured out the difference between being certain and being right. This will work out fine for him, right up until the time he overplays his hand. When he does, it will get ugly fast. He won't have to make very much of a slip for it to trigger the pent-up resentment he's certainly causing.

So do your best to keep yourself clean, wait it out, and let someone else start the blow-up process. My best advice is for you and the IT project manager to accept Dick's methodology, at least to the extent that you accept that your scope is limited to building software that fits the specs. To that end, document the specs as precisely as you can and insist that you get proper sign-off on the specs from Dick before anyone starts the coding process. That he thinks all methodologies are waterfall will work to your benefit here: This is how waterfall methodologies work.

If Dick refuses to sign off on the specs, that sounds like a great opportunity for you and the IT project manager to say something like, "We don't understand. If they're right, you would sign off on them, of course, so if you won't, that has to mean something is wrong with the specs. We sure don't want to start the coding process until they're fixed."

Or, you and the IT project manager might consider bringing in internal audit around then if you're boxed in and think that might help. But that's a last resort. As I say, try to wait it out and let someone else start the party.

BTW: In my book, what you describe indicates that Dick might be an excellent project manager, but as an agent of change he's a fool. Being a competent change agent means more than telling everyone what's supposed to happen and then blaming them when it doesn't. It means taking the steps necessary to move the organization forward.

By definition.

- Bob

Posted by Bob Lewis on May 31, 2006 05:06 AM

RATE THIS ARTICLE:

COMMENTS

It is possible (but not certain) that they had too many checks and balances. I am in the process of going through a transition, where we are going from a methodology of lots of documentation and control, to 'get er done'. The thought that keeps me going is this 'The reason you have controls is to minimize costs of a failure in production, however if your controls are more expensive than a (potential) failure then the controls are counter productive'. Imagine installing a $200 thing-a-ma-jiggy in a $500 whats-ya-ma-call-it. How much testing should you do to insure that it does not blow up the whats-ya-ma-call-it? If their is a historic rate of 1 in 100 failing, then why spend $100 to have the thing-a-ma-jiggy tested, if you can't get the cost of testing down to $5 each then you are wasting your money. (yea, I am assuming that their is no lost revenue in having your whats-ya out of service, pretend you have 50 of them on the shelf and you only need two in production at one time)... In my case were were spending more time on testing, then we were risking by going live with a full failure. My point is sometimes there is a lot of methodology that can be cut.

Posted by: mark wusinich at May 31, 2006 08:02 PM

How is this not malicious obedience?

"To that end, document the specs as precisely as you can and insist that you get proper sign-off on the specs from Dick before anyone starts the coding process."

Without (I'm fairly sure) intending to, you've just confirmed the real reason "malcontents" would cite for what they're doing: they think the boss is wrong. You've told people several times that if they find they're working for someone they can't deal with, it's better to be the one to choose when to stop working for them rather than wait to be fired or transferred.

What you're suggesting here -- keep your head down and wait for the boss to crash and burn -- is even more indirect. It's waiting for some un-named third party a step further from the conflict to fix your problem by removing the boss. I have to disagree with that. It's time for "Working" to polish up the resume. The only question is whether the udpated resume is a backup while trying to take down the boss, or if leaving is the primary strategy.

Posted by: Drew at June 1, 2006 08:43 AM

"He doesn't believe in stakeholder, consensus, or any consensus for that matter. He believes in imposing change (he has said exactly this)."
--> That makes Dick the singular stakeholder in this project, so treat him that way. Dick becomes Working's source for system requirements needed for specs; he will either provide them, or figure out he can't and the ball's in his court to find someone who will.

"He will not hesitate to "throw out" systems methodology if it impedes the speed at which "he" can deliver."... but Working has minimum compliance standards to meet. So, she should plan her work so it meets standards, and present her plan to Dick. If he notices and wants to cut and claims he has the authority to over-ride the standard, Working should escalate to her IT Project Manager, that's what managers get paid to do. If Dick is proven right, document what the impact is and send it to him and the IT Manager, and keep a copy handy.

In the end, Working does not have to keep her head down, she just needs to clearly define to Dick what she is going to do to deliver the software, and escalate when needed. Be professional at all times, do the work, don't get emotionally attached to the work or the results. If Dick then goes down in flames at some point, Working should be able separate herself and go onto another project assigned by her IT manager.
For those who say she should dust off her resume and look for another job, your advice is out of date. These days, your resume should always be ready and you should always be looking for a new job, so you are prepared for anything. Dick's project may turn out just fine, but then some C-level management person could decide the next day to turf out the whole IT department. Always be prepared, Baden-Powell wasn't kidding...

Posted by: David Wright at June 7, 2006 02:04 PM

Three books. Three ways to change the world, your life, or at least Bob Lewis' bank account.

Leading IT: The Toughest Job in the World distills the world of IT leadership into eight learnable skills and gives you concrete, practical techniques for each one of them.

Bare Bones Project Management: What you can't not do makes project management manageable, even for first-time project managers with no formal training in the discipline.

ManagementSpeak: What managers say/What they mean … well, it won't help your career, and won't make you a better manager. Mostly, it will make you chuckle, guffaw, and maybe even chortle. Make friends - it's the perfect gift for anyone who has ever suffered through one of those meetings.

Order your copies today!

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert