Most IT execs try to boil down their decisions to simple dichotomies: build vs. buy, distributed vs. centralized, minimum ante vs technology leadership, good vs. oracle, freedom vs. microsoft. This pattern repeats amongst the developer crewmates: visual studio vs. rational rose, DOM vs. script, cron vs. UP, and the most ancient of wars: vim vs. emacs.
Now that I am on the business side, and not held directly responsible for the tactical stuff, I can see why the business suits always simply stare at IT people in agogged wonder– these tight decision trees have nothing to do with the real world. Developers and engineers live their whole day in an artificial construct of reference hash tables, primary keys, routing diagrammes, and copies of 1s and 0s that need to be shephered from here to there and back safely. The engineer’s job consists of either a) building more of that artificial construct, b) cleaning up someone’s poor interpretation of that same construct, or c) defending their version against someone’s proposed revision.
Business people think in analog– sales are way up, slightly up, break even, almost to goal, a little off, under plan, or ‘in need of budget revision’. Notice the complete lack of any diacritical statements next time you talk to marketing– it’s all shades of orange (the new gray), very little black and white. Notice how the IT guys will pepper endless questions trying to make some logical tree out of statements like “make it cool”.
So what? Well, I don’t know yet. I’ve spent several years trying to come up with the magick formula, the correct set of questions to ask, the right analogy to frame things for the business owners. I hve learned the following points (in no logical order):
- never start with a stark choice– it scares the business types, and makes them inherently defensive
- when picking your analogy, try something close to the listeners’ heart: cars seem to be popular here in the midwest, while history worked well on the east coast. Japanese like to use organic metaphors: seeds, vines, roots (nemawashi), etc. Be careful with chess– your listened either has no clue about the game, or is a grandmaster– either way, they’ll start asking questions about your analogy for which you don’t have answers (you didn’t think that many moves ahead– oh the irony!)
- When laying the groundwork for your eventual “this vs. that” question commital point, make sure you attribute all the incoming data to someone else: bonus points for attibuting the background research/material to the same person you are about to ask for a decision– they feel smarter already.
- multi-variate choices are much better in terms of quick understanding, but they usually require a whiteboard to lay out the different factors involved (i.e. cost and complexity, time and ROI). At this point, the best you’re gonna get is to have your decider play pin-the-tail-on-the-donkey somewhere on the whiteboard. This is a false answer– it is still analog-y and relative to their opinion. You still don’t have a hard decision (maybe that’s enough?). Warning: do not attempt multi-variate using only verbal communication. Double Warning: don’t try this with a metaphor, as your listener will forget the question and only answer their opinion about dogs/cars/football teams/naval battles.
- Whenever possible, practice your Fractal Management.