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.

Solutions

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.

Processes

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

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.

SLAs

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.

Silos

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.

Reviews

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.

Doh!

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!

Solution:

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.

Disproductivity

More posts on leadership can be found here.

I'm going to venture an estimate. I'm thinking that I've wasted somewhere around 75% of my employers' time on average during my career. My entry-level jobs were not so bad. Working the phones meant that I was actually doing something, albeit low-value, most of the day. But as I progressed from task-taker, to individual contributor, to positions of influence and leadership, the amount of my time wasted increased to include, well, most of it.

"Matt, you're telling the world that you're a drain on your employers!" No, I'm not. I've always delivered value many times greater than the cost of my employment. What I'm saying is that I've had to do it in about 25% of the time allotted. The other 75% of my time went to things that were not just unproductive, they were disproductive. They were worse than doing nothing because they caused stress, wasted time and money, and impacted worthwhile activities. Here are some of those things that caused disproductivity:

Spinning up disproductive projects. I'd say that, on average, four out of five IT projects that have hit my radar have had no potential to be completed. Some reasons for this are:

• They were knee-jerk, "Yes" reactions to an executive whim.
• They were committed to before costs and duration were understood.
• They were legitimate projects, but they didn't survive subsequent waves of prioritization.
• They seemed important at the time, but the stakeholders lost interest.

My solution? In recent years I've gained the ability to foresee which projects will actually go to successful completion (with almost 100% accuracy). I've made a practice of killing disproductive projects as quickly as possible. Doing so has reduced my disproductivity a fair amount. When confronted with a new project, I ask qualifying questions like:

• Who actually wants this project?
• When they find out the cost, will they still fund it?
• Will it survive resource reallocation for acquisitions, new sites, new product launches, management swaps, bad earnings reports, etc.?
• Do we have the support, the funding, and the ability to make the project a win, assuming that we complete it?

If I don't like the answers to these questions, I apply a choke hold, poison, or starvation to the project as aggressively as I can. It works.

Attending disproductive meetings. Everyone knows this, but nobody does anything about it. Disproductive meetings are meetings where (a) too many people are invited, (b) the agenda is weak or null, and (c) the follow-up expectations are unclear.  These meetings are disproductive because:

• They distract people from otherwise valuable work.
• They frustrate people.
• They cost a lot of money and don't provide much benefit.

My solution? I love Tim Ferriss's advice in the 4-Hour Workweek. Among my favorites is asking  the organizer what he needs from you in advance so that you can give it to them via email and skip the meeting. Usually they don't know what they need. They plan to let everyone do their thinking for them in the meeting. If the meeting doesn't have a clear agenda, ask for one or don't attend. Also, don't attend the whole meeting. Ask if you can get your stuff out of the way first and be dismissed because you've got "another commitment."

Disproductive email. I noticed this story about Atos banning email. I don't think that email should be banned, but I agree that people should use the most effective means of communication available. Email is generally ineffective and often disproductive. People use email incorrectly in at least the following ways:

• They use it like IM.
• They CC way too many people.
• They don't drop people from distribution once they're not needed.
• They use it as a data archive.
• They turn on the inbox alert to distract them every time they get a new, useless email.
• They use it to say things that they would not normally say.

I don't have any of these problems when I use LinkedIn, Facebook, Skype, or Blogger. They have rough email capabilities, but they don't get abused. Moreover, they never involve large groups of disinterested parties.

My solution?

1. Don't send email.
2. If you do send email, avoid CC.
3. Turn off your inbox notification.
4. Create aggressive filters. Filter sources, people, subjects, and anything else that you don't really need to see. Yeah, you might miss something important, but they'll call back, and you'll avoid wasting your time.

Reading management's minds. Leaders are supposed to set direction. In most cases, IT management fails to do this. They flounder, they react, they panic, and they drag everyone else along with them. It's impossible to focus on important or complex work when management is driven by urgency.

My solution? Determine the priorities for myself and the people I lead. (See the qualifying questions under "Spinning up disproductive projects" earlier in this post.) When management panics and wants to change priorities, buffer it as much as possible until the questions above are answered. Don't let it impact everyone else until you know whether or not it's important.

Usually management doesn't know why they're panicking. In a few days the dust will settle and they'll be glad that someone held the course.

Things that are not disproductive. Here are just a few examples of things that employers should value over the aforementioned disproductive activities, but don't for some reason:

Chatting with a coworker in the hallway usually is not disproductive. It is a frequent source of innovation and idea generation.

Training is not disproductive. If you are not training your employees because your volume of disproductive work won't permit it, your organization will never be great.

Reading is not disproductive. Reading on the job should be mandatory. Employees should be able to expense any book on the condition that after they read it they share what they have learned with the team.

Brainstorming and whiteboarding sessions are not disproductive. They lead to great ideas and they encourage people to share information that is highly relevant. If you're people are too busy doing disproductive work to think, tinker, and experiment, you will never be great.

Working from home is not disproductive. I did it for a long time. My productivity increased tremendously, as has the productivity of others who have done the same. How?

• Commute time is recuperated.
• There are fewer interruptions.
• There is no need to look busy when between important tasks.
• Personal needs (laundry, phone calls, etc.) can be intermingled here and there, freeing up time after 5pm for the employee to keep working on important stuff.
• Sleep and diet improve.

Complaining is not necessarily productive, but it isn't necessarily disproductive, either. It is an indicator that something needs to change, even if it's the complainers. Letting things fester is disproductive.

I would love to see a company wage an aggressive war on sanctioned disproductivity. In a business climate where most companies are still grovelling for marginal efficiency gains, why allow this stuff to continue?

Contact Matt here.

Follow Matt on Twitter.

Connect to Matt on Linkedin.

View Matt's language coaching blog.

Trust--THE Critical Leadership Attribute

Quote: "There’s an expectation that you can work anywhere and be highly productive and engaged."

This is from an article about a new Plantronics office. They designed an office to be just unappealing enough that people would prefer to work from home. Never mind that they'll save some money, or that this is forward-thinking. Consider the implication: their trust level is so high that they enshrine it in architectural plans.

I've written a few articles about leadership traits. (See 9 Reasons Control Is Bad and 5 Great Leadership Tendencies That I've Actually Seen.) One of the common themes is trust. I'm now going to explain why trust is THE leadership attribute.

First, trust is the source of your power as a leader. Leaders derive authority from the people who appoint them, but their power comes from being followed. If people refuse to follow you, you are powerless to lead them. True, you can coerce people. That's a kind of power, but dragging people behind you in chains is not the same as leading them. To the extent that you sew fear you will not harvest inclination, initiative, or ingenuity. If you're bad enough, your subordinates will start plotting either their own exit or your demise.

To lead and be followed, a relationship of trust must exist. Someone has to extend and engender trust first. It must be the leader. (In fact, whoever extends that trust first is the leader, whether it's the boss or not.) Extending and engendering trust involves convincing followers of three things:

• You can and will do what needs to be done as a leader.
• Your primary concern is their personal success.
• You trust them to fulfill the responsibilities that you give them.

If you can't do these three things, you have to fall back on some degree of coercion.

How do locate your position on the leadership-coercion scale? One way is to look at your rules. What is the fundamental function of a rule? To shore up a lack of trust! (I'm not talking about an immutable law, like "Don't touch the stove or you'll get burned." I'm talking about a rule that you make to get the results that you want.)

Rules reflect an assumption that people are not inclined to do what is right or best. When you make a rule, you are implying a lack of trust. Moreover, if you make a rule, there must be penalty, whether implicit or explicit. Otherwise the rule has no effect. Threatening penalties is coercion, not leadership.

For example, "No Running!" is a coercive way of saying, "Running is dangerous and may result in injuries." The natural penalty for running is the potential for an injury, but the coercive rule has an arbitrary penalty, namely being kicked out of the pool area. If you tell your people, in effect, "No Running!" you force them all to live under a threat, even if they're disinclined to run in the first place. What might you forego as a result? Creative new ways to make running safe, new surfaces that prevent injuries for people who run, etc.

How do you start to trust more? Begin by questioning your rules. A story will illustrate:

Once I was tasked with creating a Suggestion Box for an IT department. When it was done, we had a stakeholder meeting to review it and to craft a welcome email to all of the IT personnel. The first suggestion made was this: "We need to tell them that the suggestion box is for constructive feedback, not for complaining." Everyone agreed, except me. I asked why we needed that statement. "Do we have reason to believe that people will use it to complain? Will we still get frank feedback if we start with a rule that assumes the worst? Do we want real feedback, or just positive feedback?" We all agreed to forego that statement, as well as several additional rules that, for some reason, seemed intuitively necessary to several people.  (As it turns out, feedback to the Suggestion Box was professional and constructive.)

Another story involved a team that was complaining about senior management frequently. Then something happened. Someone on the team was blamed for a major incident that really wasn't his fault. Everybody knew it, but he was about to take a hard fall for it anyway. The damage to morale would have been irreparable. At that time, a senior director stepped in. He called a meeting with the team and forcefully apologized for what was happening, ascribing all of the accountability to himself, and swearing that this sort of thing would never happen again. He then scheduled a series of meetings to just listen to the team. Almost overnight, the trust that he created increased his power to lead the team several fold. Rather than minimally complying, people were actively trying to support him and going out of their way to praise him behind his back.

He build relationships and harnessed their power. Relationships are based in trust, and thus inspire our best action. They foster respect, admiration, and camaraderie. Rules foster resentment, indifference, and fear.

If you genuinely trust your people and you are sincerely inclined to their welfare, your only limit is the upper bound of their best synergistic output, which you have the power to help improve! If you don't trust them, though, you are restricted to whatever you can force them to produce. This is why, whether your a senior director, a parent, or even an individual contributor, trust is THE critical leadership attribute.

9 Reasons Control Is Bad

"Fifteen calls in the queue holding four minutes!" He would belt that out every ninety seconds or so. He was my manager at my first IT job. My job was helping customers. His job was reminding me. Never mind that my customer service rating was perfect for six months. My average call length was above threshold by a few seconds. Whatever-his-name-was kept reminding me. I left, doubled my salary, and launched my career. He probably hired someone who was better at following directions and wasn't so worked up about "happy customers."

For years I swore I would never get into management. Every new boss I encountered only bolstered my resolve. Management, including senior management, seemed to be about enforcing mediocrity. They did things like:

• noticing what time people showed up to work
• pouring over reports looking for potential 0.5% improvements
• cracking the whip to make sure the hamsters run faster
• pretending to be SMEs when lecturing actual SMEs

I did what any good engineer learns to do: I got important work done in spite of them. I built valuable relationships with business units. I avoided meetings, ignored pointless forms and procedures, and generally was a prima donna.

Well something happened. I went to work for Dan Case. (I talk more about Dan here.) Working for a leader made many things clear and forever altered the trajectory of my career. I've spent the ensuing time pondering and studying what makes great leaders, and in the process I've learned much about what makes bad managers. The bottom line is control. Leaders lead because they have followers. Managers control because they don't.

Here are seven reasons why control is bad for business:

1. Coercion versus inspiration. When you control your employees, you employ some degree of coercion. Coercion breeds fear. People who are afraid of you will not be inspired by you. They won't even be inspired in spite of you for very long. If you have to coerce people, either you have hired the wrong people or you are the wrong person.

2. Compliance versus excellence. To control your employees, you have to enforce arbitrary standards. Most employees will respond with compliance, not excellence. Excellence involves converting the unique skills, abilities, and passions of your employees into valuable contributions. In many cases these contributions cannot be measured by your standard. Employees who try to excel will either get into trouble or find their way out of your department.

3. Subservience over ownership. When you mandate someone's output in any fine degree, you strip them of ownership. Their job goes from challenging and engaging to perfunctory and uninteresting. You lose their innovative and creative potential as a result.

4. Conformity over spontaneity and intuition. When the "right way" is set in stone, a feedback loop is erected. People will focus on "doing it right." "Aha!" moments will go unharvested because there is no benefit, and perhaps some risk, in pursuing them.

5. Statistics versus value. I once met with a CFO who was unhappy. He had lost money and IT was arguably responsible. We showed him a network SLA report with 4 nines. He said, "Bull. You're lucky if you have 80% uptime." Of course that statement is absurd. So what?. You can't prove to the company that they like you using charts. Attention CIOs: you don't need SLA reports. There is no such thing as statistical happiness. You need one question in a management survey:

"How would you feel if IT management was replaced and why?"

6. More versus better. If you are controlling people and you need improvement, you ask for more. More hours, more tickets closed, more calls handled, more comments written--just more. That is different from better. Better means that people, processes, and output are continuously improving. Try calling USAA sometime to see what I mean.

7. Satisfaction vs delight. The result of controlling always seems to be a satisfaction survey of some kind. Designed by IT, these surveys are rarely as meaningful as water cooler talk. Even more rare is the survey that is interpreted correctly and acted on properly. Try asking questions that use superlatives. Stop giving five options, and switch to yes/no, like this:

"Are you amazed at how easily your iPad works on the company network? [yes] [no]"

8. Tactical versus strategic. Managers use the word "strategy" a lot to describe tactical things. Control is tactical. Control has nothing to do with envisioning the future, setting direction, or getting the very best out of your people. Tactical work is for managers. Leaders focus on strategy and evangelism. Their tactical work consists of clearing hurdles and facilitating the work that their people need to do.

9. Rules versus relationships. People who control make rules. Rules dictate how people will behave. They limit and constrain our interaction, our mutual understanding, and our sharing of knowledge. Relationships, on the other hand, do just the opposite. Even if you're a controlling manager type who has a rule for everything, you still go to conventions in hopes of networking--yes, that's right--building relationships that will help accomplish what you want. You do the same thing in any number of social settings. Why is it that as soon as you're in charge of something you torch relationships and start making rules?

At the end of the day, letting go of control means leveraging trust. You can lead when your people (a) believe that you can and will do what needs to be done, and when (b) they know that you believe the same about them. If those two things are missing, you only have control left.

So, do you simply stop telling people what needs to be done? Not exactly, although if you do they'll figure it out. Setting direction, though, is what people look to leaders for. Thresholds are beneficial for some people. Some people need to learn how to stop being supervised. When such guidance is offered as a means of cultivation it is empowering, unlike the stifling influence of control.

Take a minute to ponder and question. Are you comfortable letting go of control? Do you trust your people to do what needs to be done? Do you believe that they trust you?

Strategic Plan vs. Aggregate Tactical Plan

"Matt, we need your input into the 3-year strategic plan." I was a network security engineer. I configured firewalls and tried to stop intruders. The question didn't make any sense to me. "Could you please tell me what you mean by that?"

"The CIO is putting his 3-year strategic plan together. We need to know what projects you think we'll need to do over the next 3 years."

"What will you do with that?"

"We'll roll it up with everyone else's input and turn it into a strategic plan."

"So let me make sure I understand: you're going to take my ideas about security projects that we might need, add in other peoples ideas about projects for their teams, and then the CIO will use that to make the strategic plan?"

"Yeah. We need it today."

If you aren't laughing yet, you shouldn't be reading this post. Unless you're wincing. That counts.

Well, I began using the term "Aggregate Tactical Plan" on that day. For the rest of the time I worked there, whenever someone mentioned the "Strategic Plan" I would say, "You mean our Aggregate Tactical Plan?" They never liked my name for the plan.

When tactical thinkers get into leadership positions, they don't suddenly start thinking strategically. They start using words associated with strategic thinking, like "3-year Strategic Plan." They say things like, "What's our strategy for getting the phone system upgraded by November?" But they never actually think in terms of, or portray, strategy.

Strategy is the result of deep consideration and pondering. For a tactical person to arrive at strategy is possible, but it involves asking "why" a lot. "Why should we do this or that" can lead to a somewhat bigger view of what needs to be done. Continually pushing one's thoughts up that hierarchy of actions eventually leads to the ability to think about vision and direction. Eventually one can resist the urge to plunge into battle details and focus on the war.

IT might be the worst at this. IT has some deep thinkers (and not all in management) who understand strategy and don't get recognized for it. Then there is the rest of IT who is either incapable of or disinclined toward strategy.

So for those of you who are going be promoted to IT Management and put your engineers in intellectual harm's way, here are some ideas to consider when you have to craft a strategic plan.

Highest-Level Strategy

This is where you define your overall direction or your ultimate desired outcome.

Q: What do we produce?

A: Delighted Clients. [See Steve Denning's article.]

• Engineers who can turn out good products faster.
• Salespeople who can sell solutions more easily.
• Executives who can execute on strategic goals.

By the way, if your focus is on how you're going to report on SLAs so that you can prove that you're doing your job, you are losing. All you have to do is ask the employees a simple question: "Would you be sad to see IT management replaced?" Most SLAs are B.S. and everyone knows it. I've never worked at a company where IT at some level didn't rig the metrics or the reporting.

(Also, notice that I asked a"what" question. You should have already answered "Why?" Visit Simon Sinek for more.)

Mid-Level Strategic Talking Points

Here's where you flesh out at a high level what you're strategy means operationally. Try asking questions.

Q: How will we lead? [See also 5 Great Leadership Tendencies That I've Actually Seen.]

A: By enabling and facilitating.

• Clear roadblocks.
• Mask corporate turmoil.
• Provide clarity and prioritization.
• Minimize fire drills.
• Resolve concerns and be transparent.
• Focus on relationships over rules.
• Allow employees to focus on delighting the client.

Q: How will we manage?

A: We will expend 20% effort to get 80% results on things like:

• Measuring
• Documenting
• Policy creation and maintenance
• Reporting
• Compliance (with obvious exceptions)
• Forms
• Meetings

Q: How will we communicate?
A: We will communicate transparently.

• Frankly
• With full disclosure (except where prohibited)
• Promptly
• Often
• Unambiguously

Q: What will we reward?

A: We will overtly reward innovation, creativity, and the extra mile.

• Rely on our experts; don't dictate to them.
• Foster cross-team collaboration and synergy.
• Provide time, incentives, and recognition for valuable behavior

Q: What kind of team will we build?

A: Fully engaged and leveraged.

• horizontal, cross-discipline integration
• natural collaboration
• spontaneous and assigned mentoring
• constant personnel development and promotion

Q: What will our systems and applications look like?

A: Primary features: elegance and simplicity.

• Simplify processes and minimize rules.
• Encourage risk taking and judgment calls within thresholds.
• Reduce system and configuration complexity.
• Make things reproducible, intuitive, and intrinsically documented.

If this list makes you want to define forms, meetings, policies, or org charts, you're thinking tactically. If it gives you a vision of a team that functions with enthusiasm an generates high-volume, high-quality output, you're on target.

Of course, questions like these lead to action plans. Action plans bridge the gap between strategic and tactical thinking. The more detailed they are, the more tactical they are. You need action plans.

However, a list of projects that you'll execute on, especially if it was handed to you by the business units, is not a strategic plan. It's a project list. It's the tactical outcome of your strategic goal to delight your clients.

Try to learn to think about the big picture, or at least the medium-sized picture. If your approach to building and running your organization is overly tactical, you will end up spending too much time tweaking minutia and minimizing the ability of your people to do great things for you.