Keith Perhac mentioned in a podcast that a client told him he accomplished more in three days than the client had accomplished in six months. That sounds like hyperbole, but it’s actually plausible.
Sometimes a consultant can accomplish in a few days what employees will never accomplish, not because the consultant is necessarily smarter, but because the consultant can give a project a burst of undivided attention.
Some projects can only be done so slowly. If you send up a rocket at half of escape velocity, it’s not going to take twice as long to get where you want it to go. It’s going to take infinitely longer.
Related post: A sort of opposite of Parkinson’s law
Completely true! I’ve hired consultants to do the same thing. No distractions is nice. Sometimes, having the consultant on site frees me to work more productively too, because I have to escort any contractors while they are in our facility. That makes it easy to say no to other things.
Chemists quickly learn that things take as long as they take. If a reaction takes 48 hours to run, it takes 48 hours to run, and that is that. Other reactions you have to quench fast, or they will go on and do all sorts of nasty things.
When I was a contractor, this “rapid progress” effect seemed to happen most often for social or structural reasons: I was able to get folks involved who weren’t normally “in the loop” or even listened to.
Most often they were technicians or IT folks who were not normally viewed as peers by the “real” engineers or management. One thing a contractor can do is work across existing social and managerial group boundaries to make use of *all* available resources.
BobC: Absolutely. Sometimes there’s someone in the organization with low prestige that has the answer. It takes someone with high prestige, the consultant, to repeat what they say.
I would try to get the “outsider” to step up to present their input and take credit for it, and get some “up-front” respect from their peers. All I’d do was introduce them and highlight the need for all to listen. Sometimes this had to be preceded by a short intense session on public speaking to get them past their reticence to speak up.
My goal wasn’t just to come up with the answer to the specific technical problem I was called in to address: I wanted to leave a system behind that was better at group problem solving, with the hope that my next contract with them would have a smaller social component.
I very much preferred to apply my technical expertise rather than wade through and resolve social dysfunction, which is always a management failure far removed from any technical issue. I was a technical contractor, not a management coach or industrial psychologist.
But any time you deal with people, it’s social to a greater or lesser degree, even with “strictly” technical issues. Makes me wish I had better natural “people skills”, instead having to work so hard at it. Tech is easy in comparison.
Like Gerald Weinberg said “It’s always a people problem” even if it looks like a technical problem.