Many IT managers have proposed an idea to their team and then had to suffer the challenge of an unwashed, video gaming, gearhead claiming that the manager’s proposal “Can’t be done?” Project managers face these contests in the trenches but usually find quickly that there is no real competition. Read on to leap past this obstacle.
Picture a rider saddling a horse. He squares the blanket on the beast. He tugs the girth, ties it, and tugs again. Places the stirrups. The rider ties down the tack. The watcher would see something unique to the rider, the horse, and the tack. A ritual.
Applying BBQ rub and marinade. Giving thanks. Checking email when waking. All can be ritual.
Likewise, when the manager is told that he can’t do a thing, it is just the first step in a ritualistic dance between management and developers.
It’s a Conversation
“I want to represent all financial transactions in a single table before we go live,” says the manager.
“But you can’t do that. It won’t work,” answers a chorus around the room. Various reasons–some good, some bad, some too techie to tell–are tossed in the manager’s direction. If he didn’t earn his chops–he leads because he is the leader–the next few minutes are wasted on I’m-the-leader words and resumes fly out to Dice.com that afternoon.
On the other hand, if the manager is used to working with coders, he realises that the gearhead answers the exact word of the proposition by nature. Any percieved attack is made on the idea, not the man. Well, usually. The PM, Resource Manager or App Manager properly lets the techies talk through the limitations. List them. Anything worth saying is probably worth visualizing.
“Our tables are set up to work with our vendor software packages,” announces the lead.
“The rework would take weeks of coding and testing time.”
“I agree with that statement. What else could be an issue?”
And so the project team lays out the pros and cons. When the expert finishes explaining everything he knows, he’ll start explaining how the proposition could be architected and made into a success. With a little prompting.
Or is it Brainstorming?
“So, we have a problem we have in front of us that the business wants solved,” begins the manager. “You’re my problem solvers. How can we integrate these tables without breaking the existing applications?”
A pause… One or two team members get a wide-eyed look.
“We could use a view. What do you think about a view?” says the first brainstormer.
“Not without some kind of replication,” answers a half-convinced tech lead.
“We could use trigger-based replication and a view. What do you think?” comes another answer.
“Guys, I don’t even know what that means, but let’s talk it through,” says the manager. A design session materializes and code is probably written by the close of business.
The geek brain is wired to work this way. I’m sure there are papers written about it somewhere–who cares! Make the ritual work for you. Put your team at ease and engage them as problem solvers. Enable them. Coax them, if you have to but buy into the ritual. It is your first step out of the command and control model and escaping an adversarial process; and just as likely, the ritual is your first step to solving problems in a better way.