In Part I, I described two graphs that I think help explain much IT dysfunction.
I also noted that, typically:
- People in group A will often talk to and solicit advice from people in group C. (think VC or CEO talking to technical guru)
- There are relatively few people in group C. (some companies might not have anybody internal in group C- they hire consultants or read expert opinion)
- Most of the people who actually have to implement and maintain new technologies are in group B.
Clearly there are lots of gradations between A & C & B, so I am using the groups as a convenient way to refer to the extremes. In the case of group B, the extreme is people with relatively-solid technical credentials but who are very cynical about technology and are very risk-averse. There are a few things that one often finds with group B:
- Group B are adverse to risk because, when things go wrong, they are on the front lines having to deal with the aftermath.
- Group B are rewarded for keeping things predictable and consistent- change and the risk that goes with it are anathema.
- Group A and C perceive group B as being, at best, passive aggressive and, at worst, obstructionist. Sometimes this is true.
- Group B views groups A and C as being out-of-touch and/or irresponsible. Sometimes this is true.
- Even though both group A and C are frustrated by group B, if there is ever any contention between groups A and B, group C will usually align with group B because they share technical DNA and members of group C were once (at least briefly) members of group B.
- A large percentage of the technical world never progresses beyond group B.
- Group B makes up most of the total IT salary cost of an organization
- Individual members of Group C cost significantly more than individual members of group B
In your typical organization, you will often find that the helpdesk, QA, network administration, and facilities groups are at the apex/trough of the risk benefit curves in group B. I have to emphasize that this is not meant to be slamming group B. As shown above- there are often very good reasons for group B’s world outlook.
So why am I faffing on about this? Well, having spent about ten years managing technical groups, I have found that a very large percentage of my time has been spent dealing with the tensions described in this chart. The superficially similar world outlook of senior management (group A) and the technorati (group C) can often lead to trouble when both groups are largely dependent on a third group- the technological Eeyore’s of the world- group B. The danger comes when group B completely dominates an organization and makes it impossible for them to innovate, or, conversely, when groups A and C, underestimate the legitimate concerns of group B. I’ve witnessed a few different strategies for trying to manage the technology disfunction caused by the different world views of groups A, B and C and they generally fall into the following categories:
Ignore Group B: This is probably the most common strategy the companies adopt when they feel paralyzed by IT dysfunction (though calling it a “strategy” is probably just dignifying what was really a muddle). The typical scenario is- A major project is estimated and planned by senior management (A), with very occasional sanity checks of isolated elements of the projects with some senior architects (C) and virtually no acknowledged input or buy-in from the poor sods who are going to implement and run the thing. The project radically misses the deadline, there are recriminations all around. Does this sound familiar? I bet it does.
Hire only group C: This is often cited as the “Google strategy”, but it is common to many tech startups. In order to avoid the disconnects caused by the differing world views of groups A, B and C- just hire people in group C. The problem with this strategy is that, while it may work very well in the initial stages of a startup, it doesn’t scale very well. Either you have to eventually hire people in group B (even if you outsource it), or you are going to have a lot of pissed off senior engineers ineffectually doing things like product management, sales, helpdesk and basic systems administration. I guarantee you that Google has recently had to hire people in the A and B camps. I know because I’ve met them. Eventually Google too will have to deal with the ABC dynamic.
Outsource: This is probably the second most popular strategy for dealing with IT dysfunction. Without going into the debates about the ethics of outsourcing, it is important to note that, in the context of dealing with the disconnects between groups A, B and C- outsourcing is simply a displacement activity (in the psychological sense- obviously this is literally true as well). It has long been noted by outsourcing specialists that you are only likely to succeed in outsourcing something that you already know how to manage. If you are having trouble managing a process, then outsourcing it will probably actually exacerbate your management problems. If a company outsources IT, they are still going to need an informed IT strategy and that strategy will still have to reconcile the differing world views of groups A, B and C. Outsourcing IT might temporarily mask IT management problems by making mistakes less costly, but I suspect that, in the longer-term, the cost will creep back up as management takes advantage of the “cheapness” to launch even more ill-informed and mismanaged IT projects.
Turn A into B: This is the most original strategy that I’ve seen for dealing with problems inherent in the ABC dynamic. The CTO (group C) of a small technical company made a habit of hiring people from group A, and intensively training them to handle group B tasks. The advantage of this, from the company’s point of view, was that they had a group with the apparent expertise of group B, but with none of the cynicism and risk aversion typically associated with the group. The result was that, for a while, the company in question was incredibly agile and innovative and the company’s clients loved dealing with the IT group because their answer to everything was “Sure, that can be done. It will only take a few days”. In the long term, this strategy had some ultimately pernicious side effects. The reason that the team was initially able to deliver on its “it will only take a few days” promise was that they took shortcuts everywhere, didn’t build to scale and released alpha quality code that they would then spend months repairing and rewriting. Clients who were at first thrilled by the quick turn-around, grew increasingly disillusioned when almost every project had to be re-released N times before it really worked. And, of course, the cumulative effect of all of these problems was that eventually many members of the team developed much of the cynicism and risk-aversion typical of group B (though, to be fair, I should note that they still remained a remarkably optimistic bunch, considering what they went through).
Triangulate: This is the dialectical process, but the key to it is recognizing that you have a three world views in the first place. Most companies just muddle along, knowing that there are different views, but not clearly understanding what informs those views or how they relate to each other. The problem is even worse for companies who have IT departments exclusively made up of group Bs- to them there just seems to be an unbridgeable gap between the non-tech and tech sides of the organization. Recognizing the three world views is the first step to being able to mange how much influence each group has over a company’s technical strategy.
The two graphs illustrating the relationship between technical expertise and attitude toward the introduction of a new technology are descriptive not prescriptive- but they have always seemed to me to serve as a useful model against which to compare the interactions of an organization and its technology group.