5 Reasons Process Is Bad

I once volunteered to lead a "Kaizen" event. (In Lean Manufacturing a Kaizen event is a big get-together re-engineer a bad process.) The event failed miserably. The proposed solutions were larger than the problem, did little to address the problem, and had no hope of being implemented. 

Process problems have fascinated me ever since. After years of trying to “fix” bad processes, I have found the solution for ninety percent of them: do not create them in the first place.

Good processes are designed for work that is highly repetitive and that requires very little thought. If fixed output and fixed quality are the goal, a well-designed process is in order. Where people’s brains are employed, though, process is usually bad, and here are some reasons why.

1. Process Confines Strategy.

A good business leader helps us all understand vision and strategy. Then the rubber hits the road and we have to do something about it. Each time we encounter a new problem, our lizard brain says, “Create a process!” So we do.

Then we take it a step further. We build a tool to facilitate our process. It might be a spreadsheet or an access database. Maybe we buy a software package and customize it beyond recognition. Now our process is enshrined in a tool.

Fast forward. The leader announces a strategy shift. As the shift trickles down through the operation, what do we start to hear? “That’s not our process." "Our tool won’t let us do that.” And so the process, created in response to a tactical issue, threatens our strategic maneuverability. If you don’t think that’s a big deal, you might be the author of many complex processes of which you are very fond.

2. Process Punishes Innovation.

I once worked for an IT organization that found itself under new management. The new management had a process for everything. The outputs of these processes were predictable. So is the output of a Rube Goldberg machine, but who needs a bowling ball, dominoes, a flame thrower, and a flock of carrier pigeons to flip a light switch? As anyone can guess, the innovators in the IT organization immediately began streamlining or bypassing processes in favor of speed and effectiveness. Question: Did IT praise them for their innovate spirit or condemn them for breaking rules? Answer: They all found their way out of the organization.

3. Process Rewards Unproductive Compliance.

A new Director of IT once restructured our operation to focus on trouble ticket resolution. It involved new processes, new rules, lots of meetings, and threatening language. Those who closed many tickets quickly were to be lauded and those who did not were to be punished.

Amazingly, turnaround time on tickets improved drastically. As an added bonus, the number of tickets closed nearly doubled! How did were those results achieved? It was simple. Employees who added little value immediately figure out the new program. They turned every customer call into two or three tickets and closed them fast, whether resolved or not. The gains in trouble ticket management were vapor, and everyone knew it except the IT Director and his SLA charts. Senior, project-lead-type folks were marginalized and bottom feeders were lionized. Compliance trumped productivity. People who thrived on productivity left.

4. Process Stunts Accountability.

One of the most subtle, yet profound ways that process impacts an organization is the way that it reduces or eliminates accountability. When you point "A" players in the right direction and empower them, they feel accountable for their results. Process, on the other hand, is a vampire feeding on the blood of the "A" player. It says, “Don’t use your best judgment, employ your talents, or think too hard. Just do what you’re told.” For “C” players, this is a boon, because they can focus on output rather than outcome. Maybe it’s no coincidence that “B” players like writing processes and they like to hire “C” players.

5. Process Creation is a Form of Elitism.

When people create processes, they usually create them for other people to follow. Apparently the creator of a given process is so adept that he or she can outthink everyone else, and the process is so good that it will work for everyone. This elitist view never delivers excellence; it rarely even delivers adequacy. When the process doesn't deliver, it's creator will always blame others for not following it. (Wanna know a little secret? People who create processes have trouble following them, too.)

Next time you’re trying to solve a problem, if your first impulse is to create a process, ask yourself the following questions:
  • Are you more interested in solving the problem, or implementing your process?
  • Will your process enhance the creative power of those who use it?
  • Do the people to be affected by the process think it’s a good idea? Do you care?
  • Will your process encourage results, or just compliance?
  • Can the process change easily when needs change?
  • Could you accomplish just as much by merely setting guidelines?

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


Today's Providers Look Like Tomorrow's IT Managers

In "What IT Needs To Change To Survive" I mentioned some things successful IT leaders need to do going forward. The good news is that IT leaders have a great role model to look to. All we need do is look at our favorite service providers, consultants, and vendors and we know where we're going.

It's remarkable to compare the relationships that many senior IT managers have with their vendors to their relationships with their own companies' executives. Let's try it.

1. Our vendors make it their job to know what we are doing, what our problems are, and how they can provide value to us. They are constantly tracking our project wish list and our budgets. They know what our major initiatives and our big challenges are. We, on the other hand, always complain that we're the last to know. We ignore relationships in favor of processes. We would rather comply with ITIL than take our peers to lunch and pick their brains. This is not going to work going forward. Failing to establish relationships will spell doom for IT management in the near future. Companies will not be content to simply dislike IT. It's no longer an all-or-nothing outsourcing proposal--they'll go elsewhere one application at a time.

2. We expect vendors to keep us up to speed with the latest options. Especially where consultants are concerned, we expect them to know more about what's out there than we do. Do we provide that same level of intelligence to our companies? Pretty soon (i.e. already) our BUs are going to realize that we don't provide that degree of insight to them. If we are to remain relevant, we need to be fluent in the external offerings that can solve their problems and meet their needs. If not, we'll be like mainframe experts making big data pitches.

3. We expect vendors to say, "yes." Better? "Yes." Cheaper? "Yes." Faster? "Yes." Moreover, we expect them to deliver on what they say, despite our constant stops and starts, our frequent changes, our late payments, and our endless griping. Yet to our companies we frequently invoke the "no" doctrine. We want them to pay more, give us more time, and settle for what we can deliver within the confines of our standard offerings. We resent their constantly putting things on hold and then rushing them. We don't like project creep, late budget approvals, and most of all, complaints about our inability to work magic.

The problem is that the time is coming when the cloud will offer them an alternative to us. The same vendors that bend over backward for us will bend over backward for our business units. If we fight it and try to pigeon hole our companies into our "service catalog" and our "engagement methodology," they're going to go elsewhere.

Wanna be a CIO in 2020? Start acting the way you expert your best vendors to act.

Contact Matt here .
Follow Matt on Twitter.
Connect to Matt on Linkedin.
View Matt's language coaching blog.


What IT Needs To Change To Survive

A week ago I interviewed for a position at a major Life Insurance/Financial Services company in Seoul. The CIO asked me a lot of strategy-oriented questions. I was thrilled to be able to field this one:

"With all the changes in the technology, how does IT have to change to continue to be relevant?"

This question is really important. In fact, its one of the reasons that I have questioned whether or not IT is a good place to be developing one's career these days. This is not a good time for IT leaders to have their heads in the sand. I will mention a few things that are driving changes to IT's way of life, and provide some solutions for forward-thinking IT leaders.

1. Disruptive technologies. It used to be Internet access, then VPN, then Blackberries. Now it is smart phones, tablets, BYOD, social network apps, and smart work. By and large, IT hates new stuff. We are still trying to work out the kinks in our old stuff and figure out how were going to get to the next rev. The problem is that companies need the new stuff in order to compete for customers and employees. In the near future our service catalogs will be out of date by the time we can finish negotiating them. If ITILv4 is yet more static IT operations models, it will be DOA. Think about it--we hate deploying a new service just to have everyone complain because their needs have shifted. Soon that could happen to our entire service catalog. How long can we wait to think about that? What are we going to do about it?

2. The Cloud. Pretty much everything we do internally today exists in one form or another in the cloud. This means that our companies, or even individual business units, are starting to have a choice. How many more upgrades to your Financial System before your department decides they just want to  have it hosted? When will Engineering decide to use hosted resources that can be provisioned on demand? When will our companies decide to evaluate alternatives to our corporate email systems? As more people move to smart phones, tablets, and whatever comes after them, do we think we will be providing the voice and video conferencing infrastructure for our companies? Do we think we will be able to prevent SVPs from shopping our services in the cloud? Would we want to prevent them from doing so? Can we match the level of provisioning time, customer support, mobility, and disaster recovery that the cloud offers? Check out this story on a company that replaced most of IT with cloud-sourced services.

3. The new workforce. The new workforce is not going to be located where we would like them to be located. They will not want to use the tools we tell them to use. They are highly accustomed to the world of technology addressing their whims, and they are very fast at finding what they want. They do not care what the IT management has to say about it, nor should they.

4. New IT recruits. The people that we hire over the next decade will be increasingly dismayed with "old-fashioned" IT. Many of them will have come from start-ups or from hip companies that know how to move fast. They don't want a ride in our Oldsmobile.


First of all, IT leaders have to understand that they are becoming one source for IT solutions, not the source. Most of our companies are already using salesforce.com and have HR applications hosted who-knows-where. Many of our employees use Skype for video conferencing. Email is beginning to fall. Even MS Office is experiencing daylight raids from the cloud. Companies are beginning to embrace choice. IT is only one choice, and our menu is shrinking. They're not coming to our restaurant for cold Chinese food when they can order it delivered from a specialty place with the noodles still steaming.

If we understand that we have become an option, then we need to learn to do two things:

1. Get to know the BUs. We need to know what the BUs want as soon as they do, if not before. (We should be doing this anyway. See this post.) Many of us lack the relationships necessary to do so, which is why we always complain about "being the last to know." In the future, if IT is too busy managing its service catalog to know that a BU has an important need, it will be too late. If we don't build the relationships we won't be providing the services. Period.

2. KnowOwn the options. In the future, much of our value will be in understanding external offerings and knowing which ones to recommend to our BUs. A CIO or IT Director who can't speak the language of cloud-based applications will not survive. But knowing what's out there and how to put it together effectively will be invaluable.

3. Only do what you do best. Focus on where we can knock the ball out of the park. We may be able to reduce our operations overhead and apply more resources to strategic initiatives.  Maybe we're breaking our necks to deliver mediocre satisfaction for a given application. Shouldn't we just let it go? Think about this: the next time the company is complaining about that app, rather than saying we need more people to manage it, why not have a great cloud option in our back pocket?

4. Think "service." How are we doing at onboarding new employees? How useful is the training that we're providing on new applications? Do we provide service with a smile? Or to the contrary, do we wait for new employees to ask us where their laptops are, constantly invoke the "no" doctrine for new "gadgets," and resent that we aren't appreciated? Do we strive to delight our internal customers, or do we believe that a good SLA report means that they should be satisfied? How does that compare to the way the cloud treats them?

The IT paradigm of 5 years ago is becoming out-dated. In 5 more years it will be old-fashioned. Many of us are still clinging to it. We have to change if we are to continue to be relevant.

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


Challenge Norms: Movin' and Shakin'

No more email. Unlimited vacation. Offices designed to keep employees away. I've been reading a lot of articles lately about companies that are overturning sacred apple carts. In each case it turns out that the only serious justification for the status quo was that it was the status quo.

Atos banned email. They've decided to know as a company what we all know individually: email stinks. Last year decided to delete all email that wasn't critical, without reading it if possible. I turned off my inbox notifier, too. After a few months I found that nothing bad happened as a result. So then I set up rules that wiped out about 80% of my email before I ever new it was there. Still, nothing bad. People use email as a file system and as a CC weapon. Atos decided to employ social networking tools that are appropriate for the task instead.

Red Frog has an unlimited vacation policy. As an organization they chose to understand what we all know: good employees want to work and don't abuse time off. Most of us don't use our 2 or 3 weeks as it is. Even when we do, we make sure that all of our work is done before we leave and we stay late catching up when we get back. Somewhere an HR policy guru is twitching and drooling in the corner over Red Frog's policy, but why? Really, why?

Plantronics wants their employees to work from home. They designed their office to keep employees away. They seem to have figured out that if they hire the right employees it really doesn't matter where they work. Of course we all know that, but Plantronics chose to know it as an organization.

Here's what's so interesting about these and similar situations: the companies decided to believe in the aggregate what they all knew individually. They chose to replace traditional thought with contemporary facts. That should seem like a no-brainer, but for some reason it seems that we have to know things for a long time before we are willing to believe them as a group. There is something comforting about structure that keeps us clinging to it long after it ceases to be beneficial. Kudos to these companies for taking off the blinders.

This is what movers and shakers do. They challenge things. They don't do it for sport or to breed contention. They just aren't afraid to ask, "Why?" when something doesn't make sense.

I've written about a few things in the IT realm that generally don't make sense in their current form (see "5 broken things that IT continues to embrace") including:
  • many IT processes
  • most IT documentation
  • corporate IT SLAs
  • team silos based on skill sets
  • HR's performance review process

I also have talked about rules and why they are generally ineffective in numerous posts.

I've found a few other things that simply don't seem to be necessary:

1. Voice mail. I've been in Korea for a year and a half. I've received 3 voice mails during that time. Each one was preceded by an email and included a followup email. The voice mails were unnecessary. People in Asia don't use voice mail. They use text messages and they're always concise. I wonder what would happen if a company decided to ban voicemail! You're probably reading this thinking "Heresy!" But hey, Atos just banned email, right? Just think about it.

2. Big, centralized offices. With video conferencing capabilities, why have one big office in the middle of the city and force everyone to commute in? You're not paying people enough to live close to the office, and that office costs a fortune. Why not have three smaller, strategically-located offices and let people go to the nearest one? The leases would be cheaper. You'd get "green" press. You might get green tax breaks depending on where you're located. You could probably offer lower pay to new applicants since they would save two hours each day on their commute. Having worked for a globally-distributed company that relied on video conferencing for day-to-day business, I know that it works. Plus, if worse comes to worse, you're only an hour away.

So here's a request: I know that you have ideas about things that we all know don't work. Yet corporate consciousness hasn't grasped it yet. Please leave your ideas in the comments. I'll write another post aggregating them and I'll even do some research to see whether anyone has addressed them yet.

Let's move and shake a little. Hope to hear from you...

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


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.


Do Something, Even If It's Wrong!

When Don Casey was frustrated because things weren't getting done, he would yell, "Do something, even if it's wrong!" He didn't mean it. He just said it.

By contrast, some IT leaders don't say it. They just mean it. An executive yells, the CFO demands a budget by day's end, a user complains that "the Internet is down again," or an exposure is discovered. IT panics. They put everyone through the paces. Projects come to a screaming halt, best practices are violated, and everyone gets exercised.

I call this "reaction bias." I call it that because it sounds worse than "action bias." (People think that action bias means having a "get it done" mentality. In fact this is incorrect. Bar-Eli et al describe action bias in their study of goalies:
In soccer penalty kicks, goalkeepers choose their action before they can clearly observe the kick direction...given the probability distribution of kick direction, the optimal strategy for goalkeepers is to stay in the goal's center. Goalkeepers, however, almost always jump right or left. We propose the following explanation for this behavior: because the norm is to jump, norm theory (Kahneman and Miller, 1986) implies that a goal scored yields worse feelings for the goalkeeper following inaction (staying in the center) than following action (jumping), leading to a bias for action.
In other words, "Do something, even if it's wrong!" because of the perception or feeling associated with doing nothing.)

This is how the TSA came to be what it is today. TSA has an $8 billion budget to protect you from terrorists. Did you know that you are 9 times more likely to choke to death on your own vomit than to die in a terrorist attack? Yet (a) we do not have a "CTDOYOVA" and (b) the TSA budget isn't doing much to make us safer.

As an IT leader, you need to be able to withstand the urge to look like you're doing something. Failing to do so reaffirms your employees' belief that there are no real priorities. It leads to disproductivity. Are there times when everyone needs to drop what they're doing? Sure. Is that usually the case? No.

Here are some ways to avoid doing something, even if it's wrong.

1. Don't overreact.

Maybe it's really important--maybe not. If you have to drop your entire operation because someone said something urgent, you don't look like a leader. Don't assume that the Internet is really down, or that the numbers really have to be in by CoB. It usually isn't as bad as it sounds. Frequently it's nothing at all. Know what you'll say to calm people down and reassure people that you're taking a sane approach to handling their concern.

2. Don't spray and pray.

This is not the time for a machine gun. Be a sniper. Find out who needs to be involved and get only them involved. Make sure that you understand the impact on your priorities before you let them go too far. Try to keep everyone else working on your priorities. Just because you had an emergency doesn't mean that deadlines have been extended or that your people can move in and out of high-value work without any impact. Assuming that you have set the strategic direction for your troops, try to keep them moving in that direction.

3. Don't immediately revamp your procedures

Every time something bad happens, some management teams respond by overhauling their procedures. It's part of "telling the executives what we're doing to ensure that this doesn't happen again." The problem is that next time will be different, and even if it's not, your new, improved process will still fail because it wasn't designed by the people who will use it, or because it was insufficiently socialized. If you really plan to overhaul procedures, make sure that you have a way to test the new procedure and make sure that everyone understands and buys off on it. Don't do all that work just so that you can say you did something. 

4. Know about real emergencies before they do.

Don't use your user base as your monitoring system. For your critical IT resources, ensure that you know first when there is an outage. That way if someone screams, you will (a) know what to tell them, or (b) know that their complaint is overstated. Consider making a customized console, or perhaps a ticker, available so that executives or users have a simplified view of what's going.

5. Know how much things cost. Provide ranges.

Start to build a table of what things cost. That way when you're asked for a budgetary quote (which you KNOW will be referred to as if carved in stone tablets) you won't have to scramble people to put together the same pricing info that they scrambled for last time. Know the full IT cost range for building a new facility per user, per square foot, etc. Know the range of costs for circuits. Have a working figure for how much consultants will cost for a generic project. Provide a range. When they try to pin you on a number, the answer is "it depends on details that aren't available yet."

6. Build relationships that will get you information.

You don't have to be the last to find out that someone is building a project budget. BUs don't have to complain about IT to their SVPs. You and your people can start to become a HUMINT organization. Gathering intelligence and building rapport through relationships on the ground is much better than relying solely on technology and SLAs. If you're panicking when someone complains, is it because you know that you and your organization don't have the relationships necessary to win you the benefit of the doubt?

Next time you feel your reaction bias kicking in, stop and ask yourself why you feel it. What are you afraid of? What will it take to be able to breath deeply and apply a measured response? 

Do something, even if it's wrong? That's not leadership. Don't choose your action before you know which way the ball is being kicked.

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


My 2012 Goal: Get the worst job in America

Oh, yes I did!

Are you listening, Mike Rowe? I had just about every kind of job in my early twenties. I trimmed trees, ironed shirts, pounded nails out in the snow, moved boxes from this side of the room to that side, sold my soul to a telemarketing job... You name it, I did it. Then, in the 90s, I jumped into the tech craze like John Travolta into disco pants. Straight into network engineering. Then security. Then architecture. Then finally I decided that I should move into management. Well, here it is 2012 and I'm starting the year with one goal.

My goal is to get the most hated job in America: IT Director.

That has only been my goal for a couple of days. Before I saw that article, I was gunning for one of the top 20 jobs in America: IT Director.


How can IT Director, with unusually high pay, and with a projected 17 percent growth rate by 2018, be the most hated job? The article had some ideas about that. So do I:

  • Your boss, the CIO, might be replaced, and the new guy will prefer his own yes men.
  • If he isn't replaced, he will continue to confuse priorities with "emergencies" on a daily basis.
  • You will continue to get the green light on projects after budgets have been established and deadlines set. Only then will you be asked for budgets and lead times. Then the BUs will resent you for costing too much and taking too long.
  • Your people will continue to get no credit for pulling off magical project wins because executive expectations were not managed.
  • The realization that you never want to be a CIO will become clearer and your career path will turn darker.
  • You will continue to attend meetings and produce documents that have no value because someone north of you has a whim.
  • You will continue to place significant emphasis on generating SLA metrics that prove that the company, which hates you, actually loves you.
So here's the deal: You want to be a great leader. You have a philosophy that allows you to tap the hidden potential in your people and produce great results. You are constantly honing your ability to motivate, to avoid micro managing, and to protect your folks from the stuff that's rolling downhill. But you're still an IT Director.

So if you're an IT manager with aspirations here are some questions worth asking yourself:

Can Leadership Prevail In Your Environment?

I had one peer who, when everyone else was jumping ship after an acquisition by the Borg, insisted that he wanted to stay and fight the good fight. His a sharp guy with a lot to offer and a lot invested in that environment, but he's basically mud-wrestling with pigs. By pigs I mean people who exist for the purpose of promoting themselves at others' expense--"yes men" who would rather look good than be great. What they lack in competence they make up for in maneuverability. Remember Wormtongue?

How much time do you want to spend competing with him?

Solution: Take a serious look at your company. Does it reward the results that real leadership produces, or does it reward manipulators and yes men? If the latter, don't waste three more years of your career. Else, if there is a pocket of your company that is driven by (or even susceptible to) strategy and leadership, do some great work for that VP, learn his/her business, and work yourself into that department.

Is IT Really The Place To Be Anyway?

Maybe it's time to pull the plug. I have a close friend who was a senior director and is now looking for a CTO-ish role in a smaller company. That's pretty smart. Why stay in a reactive IT department if you can do something that actually helps drive the company?
Tough choice?

Solution: Network with people who got out of IT. Learn how they did it, what mistakes they made, what they learned, whether they have any regrets, etc.

What If I Want To Stay And Make It Work?

Now we're talking. You're not going to accept defeat. You've put your heart and soul into this and you're going to see it succeed, by gum!


1. Be a leader first and foremost. Each time insanity is imposed on you, look at it as a challenge. What outcome could an ideal leader create in that situation? What ability do you lack that is preventing you from creating that outcome?

2. Eliminate distractions for yourself and your team. In order to stand your ground, you need results. Make sure that your people are working on home runs, not foul balls. Don't let the panic of the day prevent you from delivering on things that will put you beyond reproach.

3. Build relationships with the BUs. Don't wait for them to go to their SVP and for their SVP and your SVP to dream up a DOA solution. Work with the BUs to define and prioritize what they need and then go champion it with your respective bosses.

4. Start doing your boss's job. Free him up to do his boss's job. This is critical. Whether you stay or go, whether you get promoted or not, you need that experience. Moreover, give as much of your job duties to your best subordinates as possible. This will free you up to do your boss's job and it will make all of you more easily promoted, whether with your current employer or a future job.

5. Communicate. Become a master of communication. Learn how to give excellent presentations. Perfect your email communication. Develop an understanding of which communication medium is best for which people and under which circumstances. Don't fail because people were confused, overwhelmed, or starved by your communication.

6. Start writing. Keep a journal or a blog of things that you've learned. Review them and reflect on them.

As for me, I'm still optimistic that the "most hated job" in America has the potential to be immensely rewarding as a personal growth opportunity, but some positions have more to offer than others.

The fact that IT Directors "hate" their jobs, combined with the prediction of 17 percent increase in IT Director positions by 2018, says that there will be a lot of turnover during the next few years. Voluntary turnover rates could reach 2008 levels or even higher. Learn all you can, document and review what you've learned, and know when it's time to leave.

Contact Matt here .
Follow Matt on Twitter.
Connect to Matt on Linkedin.
View Matt's language coaching blog.