I can’t help it.
Gartner has discovered the need for “Bimodal IT.”
What I can’t help: Pointing out that once again, Gartner has discovered something KJR’s subscribers (back then it was InfoWorld’s “IS Survival Guide”) read about a long time ago … in this case, 1996, when I wrote:
You can’t ignore the Web, and so, probably for the first time, you have to start thinking about serving your company’s RPCs (real paying customers). That will change everything.
Remember when you did feasibility studies, requirements analyses, external designs and internal designs before you got around to coding systems a few years later? Forget it. You’re going to start working in marketing time.
What’s marketing time? That’s how long your company takes to get new products, services, and pricing programs into the public awareness to beat your competition. Years? Forget it. You’re going to be working in months. Sometimes weeks. That means a whole different way of designing and building systems.
Well, better very, very late than never at all, and give Gartner credit for publicizing the concept.
So bimodal IT it is, and publishing precedence be damned.
What you care about is making bimodal IT happen. On that subject there’s a point neither Gartner nor I have explored: The challenge of culture.
Culture is loosely defined as “how we do things around here.” It’s a collection of informal, unwritten rules, enforced with iron discipline through the application of peer pressure.
IT started by automating a lot of the drudgery associated with core accounting. It had a batch-oriented culture which was fine: Accounting is a batch-oriented discipline. It had no tolerance for defects, which also was fine: Accounting balances the books to the penny.
Speed? Speed wasn’t all that important compared to making sure systems provided reports everyone could trust. And by the way, with punch-card-driven batch systems that provided accounting reports, there wasn’t a lot of opportunity for ambiguity when the question was whether a system did what it was supposed to do.
For the most part, the mental habits IT acquired in learning to support accounting are still valid … when it comes to supporting accounting and other “systems of record.” Even if the underlying systems rely on overnight batch processing, they’re supporting a discipline that considers the end of the month and end of the year to have mystical properties.
Okay, that was mean. A more charitable view is that unlike most other departments, Accounting cares enough about the accuracy of its numbers to verify them on a regular basis.
And this emphasis on accuracy reinforces the traditional slow-and-steady culture that pervades so many IT organizations.
Enter bimodal IT. Systems of record don’t go away, and continue to rely on this slow and steady way of viewing the world. But now, coexisting with slow and steady is a need for an entirely different IT culture — one obsessed with speed; one that recognizes when systems have reached the exalted state of good enough and whose members are happy to put good-enough into production.
It’s a culture where late is just as serious a defect as a calculation error, and where poor aesthetics (the marketing buzzword is “ugly”) gets as much attention as overall functionality.
Want to make bimodal IT happen? We can talk methodologies and architectures until we’re blue in the face (speaking of aesthetics) and when we’re done we can’t escape the need for two radically different IT cultures coexisting in the same organization.
The question is whether this is feasible or fantasy.
It’s a good question. For guidance, look at differing cultures in the business as a whole. The view isn’t promising: Accountants talk about the bureaucrats in HR, who sneer at the bean-counters in Accounting in return. Marketing complains about the propeller-heads in IT, who make snide comments about the marketing crazies in return.
And so on. In the business at large, different cultures clash.
How about inside IT? Still not so promising. Among sysadmins members of the Unix and Windows subcultures tend to disrespect each other. Elsewhere, IT operations staff have been known to gripe about developer teams trying to push buggy code into production, while the developers in question gripe about the bureaucracy of the change control board (CCB).
Think that’s bad? Just imagine the resentment of slow-and-steady Accounting developers. While they still have to deal with the CCB, the DevOps teams supporting Marketing practice continuous integration and get to bypass the CCB altogether.
That’s your dilemma. You have to foster two very different IT cultures. And you know before you start that they’ll almost inevitability clash.
* * *
What should you do about it? Great question. But it will have to wait until next week. With any luck I’ll come up with something between now and then.
Hi Bob,
Funny you should mention bimodal IT. I’ve recently been reading the work of Simon Wardley and have been pretty convinced by his assessment that in fact bimodal is doomed and what you actually need is a three-tier system.
Wardley dubs them “pioneers”, “settlers” and “town planners”. Here’s why the middle layer is described as necessary:
There’s a lot more here for those who are interested.
Thanks for bring this to my (and everyone else’s) attention. Very insightful, and I’ll have to start visiting Mr. Wardley’s blog on a regular basis.
Those three levels sound a lot like company growth as a whole, as well. Entrepreneurs start a company (pioneer), hire a bunch of people to grow it (settlers), until it’s reached some sort of on-going sustainable stability (maintained and tweaked as needed by the town planners).
Just as the entrepreneurs who start a company are not always the best people to run them once they’ve become large stable organizations, different cultures or mindsets could be helpful in supporting departments that function in very different ways.
Looking forward to your column next week. My thought is that you really have two departments with two different customer bases, accounting and sales, under a single umbrella. But since what one department does affects what the other the can do, on-going multi-cultural training, as is done in schools for teachers, would be the way I would start — if I can make showing and understanding the functionality, the needs, and the values of one department, by everyone in the other department, part of the yearly review process.
As an ex-substitute teacher, I know that there always has to be a consequence that is meaningful to the person in whose behavior you want to see change.
you were right in 1996 and you are still right – about IT, and about the different cultures that exist in almost any organization of any size.
It seems to me that the core issue with this “culture clash” is a tendency toward simplistic thinking as in “one size fits all.” As you point out, there are situations where accuracy is more important than speed; others where speed is vital and we can accept approximations. The real challenge is to recognize which is which, which is impossible when people think one is “right” and the other is “wrong.”
IT is one of the departments that gets to support the whole organization. Another department that does so is HR. HR needs to support departments that rely on high-turnover interns, temps, part-times, etc., and also those departments that value long-term employees and the increased knowledge, experience, and skills they provide (perhaps HR helps those employees gain the skills and knowledge necessary).
Sometimes the same department employs both high-turnover and long-term employees. Sometimes this can lead to conflict between those different cultures of employees, but in well-managed departments and organizations that conflict is minimized.
All this not to mention that these multiple cultures already coexist in one organization.
I think this is where all the diversity training can come in handy. Diversity inclusion is not limited to characteristics like ethnic heritage and gender and age, but also personality styles, thought processes, work ethics, etc.
I’m thinking that bi/tri-modal IT can learn from all these other examples.
Some of the “it has to be exactly right” IT thinking remains regardless of the culture it’s supporting. It doesn’t matter how quick the turnaround of new features if the new features are too buggy to function – the coding has to be exactly right all the time; although the way the feature works exactly may be more flexible.
And I hope all of IT uses some form of change control – I have seen too many disasters from attempting to bypass it altogether. Though the extent and formality of the change control process can certainly vary.