5 Broken Things That IT Continues To Embrace

For fifteen years I've been watching IT departments cling to things that don't work. No matter how many times they get overhauled, they still don't work. Maybe some company, somewhere, has these nailed, but I've not seen it. Furthermore, I don't think that most of them are even possible in a large company. Here's my short list along with my solutions.


IT has all kinds of processes. Processes for dealing with outages. Processes for configuring systems. Processes for filling out forms. I even found a process for creating processes. Two facts exist about most processes: (1) they are constantly being modified; (2) people aren't following them correctly. Sometimes #1 is caused by #2.

Why are processes such a train wreck? Here are a few reasons:
  • Unlike manufacturing processes, IT processes are highly non-linear.
  • People usually create processes so that other people can follow them. However, those other people don't care or don't understand the need.
  • Processes usually are not intuitive. In a crunch, one must either look them up or have them memorized, neither of which is likely without a punitive threat...
  • ...which is why processes usually carry punitive implications for people who don't follow them. Red flag?
  • Processes stifle innovation.
  • Process creators love their processes, no matter how much everyone else hates them. Fixing them often requires an ego-bruising Kaizen event or something akin to it.
My solution: Rather than create a process, create tolerances within which people work. Inside of those tolerances, let them figure out how they'll deal with things as appropriate given the priorities and variables that they face in real time. Also, give them the tools that they need.

This approach, while bumpy, will lead to three things: (1) a much better understanding of the problem; (2) a more distributed sense of ownership of the problem; (3) more innovative or relevant solutions to the problem.


Documentation in IT network and systems environments is horrid for the following reasons:
  • Documentation requirements are often arbitrary. Documents are created without regard to their value in order to satisfy a process requirement. (See Processes above.)
  • Most people are not good at creating documentation that is useful to others.
  • Documentation is often audience-agnostic.
  • You don't really budget time and money for documentation in your projects, do you? 
  • Documentation has a very short half life...
  • ...because documentation focuses on pictures and paragraphs, not on data points. Thus the same IP address or device name exists in a dozen documents, and when that IP or name changes, they can't all be found and updated.
My solution:
  1. Make things intuitive so that a competent systems admin can assume how a particular system goes together. That way you don't need as much documentation.
  2. Make things consistent across systems. Same reason as #1.
  3. Make things internally or intrinsically documented. Systems people should take a clue from software developers. Put your documentation inline in your configurations. Use comments. Better yet, use conventions in your configurations that reflect what the configurations are doing.
  4. Use dynamic systems as documentation sources. DNS, DHCP, AD, monitoring tools, and other dynamic repositories can be used to provide most of what documentation seeks to achieve.
  5. Once you've done all those, you might still want some documentation. Stop and ask yourself whether the documentation will be used. If so, how frequently? If frequently, for what? Taylor your remaining documentation accordingly so that you're adding value.

ITIL notwithstanding, SLAs generally do not reflect the value of IT, nor the level of satisfaction that IT delivers. I have never seen IT SLAs that were worth the electrons required to generate them. IT SLAs are mostly a scam and a waste of time. Here are the reasons why:
  • IT SLAs are created primarily to tell the executive staff why they should like IT. Guess what? If they hate you the SLA's won't do anything to help. (See "Statistics vs. Value" in 9 Reasons Control Is Bad.)
  • IT SLAs are usually lies inaccurate. Everybody games SLAs. People close multiple tickets for the same issue. They change the severity of a ticket to push the date out. They think of creative ways to get credit for meeting the SLA without necessarily providing value...
  • ...which is why SLAs don't reflect IT's value, and therefore why the business can hate you even though you're touting stellar SLA conformity.
  • When the business keeps complaining, what does IT do? They revamp their SLAs and go through the whole exercise again.
  • SLAs don't measure project delivery. You provide huge value in delivering major projects that align with executive vision and your SLAs don't measure them...
  • ...which is why you constantly allow your top resources to be distracted from high-value projects in order to be SLA-compliant.
My solution: First, build relationships. If you are a CIO or a director, you should have relationships with the business units and the executives. Those relationships will allow you to cater your services to their needs. They'll allow the business units to come to your organization when they have concerns rather than screaming to the executive team.

Second, poll your most important users and ask them opposing, up/down questions like:
  1. I think it's time that we make management changes in IT. T/F.
  2. I think it would be a disaster to replace IT management. T/F.
  3. I think that IT management is focused on promoting the company's strategic goals. T/F.
  4. I think that IT is mostly reactive.
  5. IT solves my most important problems quickly and thoroughly. T/F.
  6. IT fails to resolve my most important problems in a way that satisifies me. T/F.
  7. IT is staffed by experts. T/F.
  8. IT needs to go recruit people who know what they're doing. T/F.
Forget those fluffy surveys that you can interpret to mean that you're doing ok when the barbarians are burning your city. If you have the right relationships and you poll often enough to get ahead of any major concerns, your SLAs won't matter much.


IT is almost always broken into teams by system type. You have network teams, Windows server teams, Unix server teams, security teams, desktop teams, etc. The result is a lack of end-to-end ownership of virtually anything. These teams routinely throw their problems back and forth over the cube wall at each other. "It's a network problem." "No, it's an firewall problem." "Wrong, it's a DNS issue." It's like watching tennis.

My solution: Encourage natural collaboration and watch to see how your teams reform themselves functionally around projects and issues. It will probably gravitate to a more horizontal model than your current vertical model. You'll have teams based more on seniority and expertise than on system type. In fact, some of you have senior people doing this behind your back already. They aren't telling you because they think you'll co-opt it and screw it up. Natural collaboration almost always trumps anything that you can create, because whatever you create is too static for what people are dealing with right now.


This is really where the rubber comes off the wheels. Imagine for a second if your output was one-tenth as bad as your HR department's review process. You'd be out of a job (unless you work for Intuit or a handful of other US companies with meaningful review programs).

Your review process has some--maybe all-of the following problems:
  • The objectives that your employees set at the beginning of the year are arbitrary and meaningless. You and your employees know it. These objectives will not last any longer than your tentative project list. Your employees know that, too, which contributes to their setting of arbitrary goals.
  • Your employees do have some professional goals that they would like to accomplish and be recognized for. Your review process doesn't facilitate them well. It might not even allow for them.
  • You will not follow-up on your employees' objectives during the year in a meaningful way, i.e. in a way that helps to ensure their success.
  • Your review process is not designed around a career advancement path. You don't have a way to push people along a technical track versus a PM track versus a management track because you're using HR's one-size-fits-all process.
  • You're not going to get budget to provide training to facilitate your employees' objectives.
  • You're not going to be able to reward everyone who excels, because your HR department has already determined that only 10 percent of people can excel. If you really focus and inspire your team to achieve, you can't reward them accordingly.
My solution: Tell HR to pound sand. Seriously. Everybody gets to dump on IT at the slightest hint of something not working, right? They even threaten to create their own IT teams, right? Why should HR be any different? Try something like this:
"Dear [VP of HR], The annual review process that we are using right now doesn't work for the following reasons: [list]. My employees and employees in other business units have been complaining about it for years. We've decided that IT will not participate in the process this year unless it facilitates creation of a meaningful, personalized program for each employee and rewards them based on their individual performance, not on a statistical distribution. Sincerely, [the CIO].

What, you can't do that? Seriously? Business units can violate security policies, trample on your budget, abuse your systems, and then tell you that they're going it on their own, but you can't do the same to HR? Why not? Seriously, why not? Show your people that you're leading them.

These are just five examples of things that don't work in IT and haven't for a long time. If you're a leader, you need to get control of these things. Stop trying to conform your department to broken practices. Build a foundation on relationships of trust and then free your people to succeed.

What other broken things have you found IT to be embracing?

Contact Matt here.
Follow Matt on Twitter.
Connect to Matt on Linkedin.

No comments: