But that’s not what I meant!
John Murrell has a nice post at Good Morning Silicon Valley talking about recent moves at Facebook and Google that reflect the classic divide between programmers and users. It’s worth reading in full:
Many years ago now, I worked as a database administrator for a large, bureaucratic organization. Those of us who represented the users of our database tool would sit in meetings with the programming teams who were assigned to improve the tool. The programming team broke down into three groups:
- The unhelpful. Happily, there were few of these. Unhappily, one of them ran the main team that was supposed to be meeting our needs. I shudder at the memory — let’s move on.
- The helpful-but-misguided. This was the bulk of the programming team, and the problem was more or less exactly as described by Murrell. These coders wanted to do right by the users . . . but we the users often found out, much later than anyone would have liked, that their ideas and ours simply didn’t mesh. This was a problem since they were the only ones with the ability (and the mandate) to implement their understanding of users’ needs.
- The truly helpful. Out of the main group that worked with us, there were two programmers who genuinely grasped what we were after. One of them had learned programming during a long military career, and benefited from a level-headed engineering mindset. The other was a musician with a lot of interests outside of coding, who had the ability to talk across the programmer/user chasm. Both of them were big-minded enough that they truly wanted to implement the most useful changes rather than their own pet ideas.
Doing that is a lot harder than it sounds, and it’s hardly a one-way street where users know what’s right and the IT folks misunderstand them. My IT pals, including the two programmers I just praised, could tell you all kinds of horror stories about user ambiguity and rapidly shifting requirements. It’s a two-way street that is so hard to navigate that you tend to be more surprised when the process does work without a hitch.
Category: Technology, The language of business
If you liked this post, please consider subscribing to the RSS feed so you can receive future articles delivered to your feed reader.
3 Comments so far
Leave A Comment
Hear, hear. Unfortunately a central problem in the applications arena. It was my proud privilege to be in a similar meeting at IBM talking about DB2 which was and is the most powerful, complex DBMS around (after Oracle beat ‘em to the punch on a commercially viable relational dbms). The research lab’s definition of user friendliness was “exposing” the API’s for user apps to access. Our notion was to point at Lotus Approach and/or MSFT’s Access for a UI, design and development tools. Guess who won ?
This is a much…much bigger issue and lies at the heart of the malaise in the tech industries though. In 25 years of fooling around with this stuff the biggest gap (in my experience) were analysis of business requirements in business sensible terms and then TRANSLATING those into at least the high-level design. Call it the knowing doing gap. Carr’s points about technology is accurate insofar as the bottom of the stack (hardware, network,OS, middleware (including dbms’s))are concerned. Where IT is NOT a commodity is when it helps solve business problems and/or opens up whole new vistas of changing the way we do things. The usual suspects for IT effectiveness remain the usual small list, e.g. Fedex, because of their abilities to drive business-based design. Take a look at the Web sites of any major ERP vendor and ask yourself what model of the enterprise lies behind the discombobulated jumble of alleged functionalities. Certainly not any derived from a deep understanding of mfg., logistics, et.al. The door’s wide open but whether the cultural gap and skill mis-alignments will ever be bridged constructively, ah…
Good insights, dblwyo. In my experience, there’s often a major problem — both with individuals and organizations — in terms of building bigger and bigger mental models of what ought to be accomplished. Yet all the top performers — individuals and organizations — do this, whether consciously or unconsciously.
What I’m getting at is that the best are always looking beyond the immediate requirement. It’s not just about hitting a quota or satisfying a spec sheet or whatever; it’s about addressing the deeper problem / issue / opportunity in a way that builds up the entity’s performance and capabilities over the long haul. Way too many IT departments — or I should say IT ecosystems, since the fault hardly lies only with IT itself — get bogged down at the specs-and-deadlines level, so that they’re never freed up (never free themselves up?) to do the Big Work, i.e. the stuff that could change the company, the enterprise, or the world.
The best business leaders are those who keep ratcheting up the arena of concern. Yes, they get the nitty-gritty details right, but then they’re paying attention to how those details feed the overall project at hand, and how that project feeds the whole progress of the enterprise. And the *very* best ones do it from angles of *both* work product and organizational process.
Tim - what you’re saying is true but believe you riffed a variation. Or more prosaically we’re using the word model in two different though accurate senses. My use was in the sense of enterprise model which represents the functions, activities and workflows of an enterprise, a business unit or operation, e.g. a manufacturer or customer service. Having spent $M and been able to draw on a worldwide engagement and client base we eventually developed some very good blueprints. But the gap between business vision and/or best practice and technology realization remains quite wide. As a friend of mine put, SAP was a state-of-theart 1970s mfg. model (said circa 2000).
You use model in the related sense of the picture businessman have of how their business should run and which they get wedded too; often because they acquire that model by osmosis over years of experience and build up a set of rules-or-thumb that have worked for them. Like any primitive hunter-gatherer who memorizes the patterns of his patch of woods he knows it and is good at hunting it. But when the climate, ecology or animal/plant populations change he’s not prepared to adapt and adopt.
Now there’s another whole thread of conversation to start for your blog.