Let's take a quick look at a scenario that happens all too often in the business world…

1.       Company has process/culture problem.

2.       Consultant brings in new process.

3.       Company loves new process.

4.       Process fixes problem.

5.       Consultant becomes hero.

6.       Company thinks Consultant IS the process.

7.       Company becomes dependent upon Consultant.

8.       Company doesn’t want to let Consultant go.

When it comes to software developers, we live in a town that gets attached to individuals.

Often we start as consultants and over time bleed into staffing models.

It’s somewhat revealing about what clients truly want.

And it’s cultural. It has to do with trust and execution. After being at a client for awhile, the Consultant's messages – and what their Company stands for – become replaced by the hero culture of the individual.

There is a portion of this that’s knowledge work and we fear that change of personality presents a loss of that knowledge. We worry that it will create uncertainty in our daily continuity. That’s understandable. We start to imagine that the daily operations of the new process can’t operate without the Consultant on hand to make it tick. But other individuals have knowledge too, so perhaps the real fear is that we might be losing someone who can save us in dire circumstances.

The fear of losing the hero as our "Ace in the hole".

The intention of having a consultant should be to help companies course correct and become self-sufficient with new approaches.

If you’ve had a rock-star IT consultant come in to help with your internal pictures, at some point he or she should be able to put themselves out of a job. But the opposite invariably happens and Dependency situations arise instead.

Companies lose sight of the original intention, and the consultant gets swallowed up in the process they’re attempting to correct and the message is lost. The Consultant becomes a daily grind "fix-it-all" super-hero – strapped to the process they’ve been hired to provide assistance with.  

We get tied up in the achievements of the individual, and not the philosophies they brought to the table. We start treating him or her as a great developer who can get more work done than their peers, and the Consultant turns into a “Butts in Seats” contractor. We lose sight of how they were able to achieve success. In fact, we don’t really care. Ultimately, we just want it done for us. We want the hero to arrive to save us from the very same poor decisions we were asking them to originally help us with.

We want the Consultant to save us from ourselves.

Focus instead on what the Consultant is telling you – the process improvement and self-sufficiency. Not the hero that made it happen. Listen to what he or she is telling you. Don’t just watch them execute and absolve yourself of the responsibility of learning what they are attempting to teach you.

Instead, up your own game. After all, that’s what the Consultant was originally brought in to do, right?

Author: Brett Gibson, Vice President of Business Development at AdventureTech

I remember being asked once how shipping and handling was calculated in a client's system. I thought it was an odd question, but I was being asked by a Senior V.P of that company so I thought it best I cooperate. I’d been working there as a consultant for only about 2 months, but there was an expectation that I should know the answer “because it was in the code” and well, I was in the code too.

I think he could see the double-take on my face that said, “So how long have you worked here and been a Sr. VP? You don’t know how your own freight is calculated? Couldn’t you ask your CFO?”

But this sort of business-to-IT dialogue is common. After some research, I was able to look through the code and provide the somewhat convoluted calculation for him. He looked at the calculation and then…get this…he began to press ME as to WHY it was calculated the way it was. 

“Who made that decision?”, he proceeded to ask me as if the IT consultant that had been at the company for only 2 months could go back in time and be a fly on the wall when that decision was made. 

This scenario is an all-too-frequent and frustrating conversation between business and IT. But who else did he have to ask? Performing a witch hunt for an employee who no longer worked at the company was a worthless pursuit and, even worse, the inter-departmental politics were extremely ugly (Let's just say he didn’t want to ask Accounting.)

So why does this scenario keep happening between business and IT?

It’s inevitable that employees leave companies and that obviously includes IT staff as well. As new employees arrive, the software a company uses is often the only living record of all those historical decisions – both good and bad – and the business itself starts to look at those decisions (wrongly) as an IT responsibility. 

But then something even more dysfunctional starts to happen. Not only is IT held responsible for past decisions that were made when they weren't at the table, they are then asked to offer new ones. This continues the cycle of mystery accountability for business decisions as time goes on. Many times consulting, clients are expecting IT to help them not with technology decisions…but with business decisions. 

Soon, leadership begins to excuse themselves from the decision table. They start seeing business decisions as coding issues, and this is where a serious misalignment with IT and your business can occur.

In the absence of effective, engaged and decisive leadership, IT starts making business decisions. Which begs the question…..

Should IT be making your business decisions?

Would you call a communications professional and rely on them solely to “create” some pretty words for your website – relinquishing the responsibility of communicating the critical message of your company's culture, services and more?

Would you call a social media company for guidance and then sit back and hope that LinkedIn, Twitter and Facebook would require no effort or input while yielding magic results?

Would you send a sales rep into the field to just “go make me some sales…” without communicating the company message and positioning – hoping that along the way he or she is going to create a company brand for you?

These are all leadership responsibilities. And so too is IT. 

Some "leaders" believe that giving money away to IT means that they have paid for a solution and therefore are absolved of all responsibility and accountability going forward. In fact, quite the opposite is true. The more money you spend on something, the more involved you should be to ensure you’re getting what you want.

Creating good software requires close collaboration if you want it to accurately reflect your business needs and daily operation. This should not be performed in an information-vacuum followed by a grand  presentation of choices to be adjudicated by the business. If business doesn’t know what they want, or chooses to absolve their responsibility for the decision, you will have IT folks making "best guess" business decisions and your software (and business) will be negatively impacted for years to come.

The bottom line is this: Business leaders MUST come to the table. They MUST be engaged. They MUST be curious. They MUST evolve from their 20^th Century fear of technology.  

The role of IT in that disovery process should be PARTNER – not DRIVER.

Leaders need to lead. Your business depends on it.