We're not going to mince words: Poor staffing structure and practices contribute to the "suck factor" of many IT departments. Other factors contributing to bad IT performance and a bad IT rep are poor team-building techniques, a pit-bull attitude about keeping others off IT's turf, poor communications with line departments and a failure to leverage relationships with top brass.
Staffing Structure
The technology love affair that went on in the early days of IT led to IT departments' being structured by technology disciplines rather than by any sort of business strategy. As we left the mainframe era and entered the age of PCs and LANs, the division went from "operations versus programmers" to "network administration versus application development," and the 21st century has fractured IT even more. For example, some Web development teams grew up entirely outside the app-dev teams; and some systems support teams, as they grew, split into user support versus systems support. However you split it, in a business where complexity is the rule and interdependencies are a fact of life, splitting IT business units by area of technical expertise is insane if you want any sort of reliability or efficiency.
Let's say your Microsoft Windows NT group reports to Bill, a top-level manager in charge of PC technologies, and this group is the only one that is supposed to deal with NT. Similarly, say your Linux group reports to Linus, the top-level manager of Unix systems. How is Bill supposed to get good information about Unix? Even worse, how is Linus supposed to enforce practices about Linux with the PC technology group, and vice versa?
Ultimately, top IT brass should be technology agnostic; the only agenda at this level should be "get it done so the organization can prosper." Both experience and reader feedback indicate that when a top-level IT manager has a vested interest in a specific technology rather than in overall IT performance, turf wars and other problems result -- which is counterproductive. For example, we recently visited a Fortune 500 company whose IT department was split up into Mainframe Operations, Network Infrastructure, Unix Support, PC Technology, and Database Operations (see "An Invitation to Turf Wars," below). You can only imagine the mess: turf wars, duplication of services, lack of broad knowledge, no cross-training and, worst of all, very little planning, since every department was effectively navel-gazing.
So what's the solution? Many of the most effective IT shops we've seen aren't divided by technology -- at least not on the top level. Instead, the organization is divided into more general areas on the top (for example, Operations), ignoring specific technology types. Then, since not everyone can be a generalist -- and in fact, if everyone were, no one would get the details right -- the organization fields tactical, detail-oriented technology teams that are specific to the various disciplines (Unix, Windows 2000, routers, Web technology and so on). These staffers are backed up at the core with strategic planners and architecture specialists who have a broad understanding of interconnected technology. Because the top brass is not subdivided by technology area, they have a motivation to consider all relevant technologies when planning and actually choose best-of-breed technologies, as opposed to technology partisans who choose the familiar. Obviously, some back-and-forth dialogue is needed: The top brass can't simply pick new technology X without feedback from tactical-level folks.
To get this feedback loop going, make sure some of the strategic folks have at least occasional "in the trenches" responsibilities so they keep sight of the needs of tactical players. Similarly, it's a good idea to make sure some of the tactical staffers get involved in the big picture stuff to keep sight of the needs of the architects. This loop is typically where future architectural players get identified as well.
One sample scenario (see "Strategic/Tactical" below) comes from an employee of a large financial services subsidiary that built a highly reliable IT infrastructure with a team that didn't want to bolt.
App dev and network or system administrators were at the same hierarchical level; they weren't separate. When a big-picture event loomed -- a new system was made or proposed, for example -- it was filtered through architecture and security teams that either rubber-stamped or kicked the proposals back for more work. For the most part, the tactical players worked with the line departments, and the strategic players worked with the VPs. This setup creates an organic career growth path for those who see the bigger picture; those who don't can continue to improve their skills in their niches. It worked well for the company; turnover was low, and systems simply operated.
One thing we're not advocating is that you split up your technology teams and scatter them to the winds. One corporation we know of did this; that is, it redeployed technical staff to various business units (see "Separation Into Business Units"), with disaster as the result. When you think about this, it isn't too surprising: If you've worked on a technology team, you know how important it is to have a peer group and a common support umbrella. If technologists who have a common area get split up, they lose both. Equally important, the technologists become beholden to departmental interests, which aren't always the same as broader organizational interests.
RSS
