Creating Shared Vision

I should first say that I have made a career (so far) out of IT Infrastructure. Aside from a short jaunt doing something else, I have worked in IT since I first got an internship when I was 15. So - I understand how very difficult it is, and have done everything from IT helpdesk, to being the IT Infrastructure Manager for a small group of shipping and logistics companies. I've worked for everything from a non-profit, to Washington Mutual Bank which had 55,000 employees at one point. I've burned the midnight oil upgrading Exchange, and sweated bullets when I couldn't bring things back online, and my maintenance window was fading fast. So - at numerous levels, in various industries, in two different countries - I've been there. The complexity and pressure IT Infrastructure teams have to cope with these days is tremendous. I am not saying that the technology isn't important, or is easy. However - it's not the technology that is the challenge for most organizations. It's the people.

Specifically, the challenge is in getting to the technology. Ask any project manager or team lead, and they will tell you that by the time the project has gotten to the "pointing and clicking" phase (the "doing" if you will), that step is 95% done. Think back through your own career - How often have you seen a project fail because some technology wouldn't work? If you have - I'm willing to bet it's still the very smallest fraction of the projects you have seen fail for myriad other reasons:

1. Budgetary challenges - the company is willing to spend $750K on yet another triple-redundant item for some other department - but IT cannot get $150K to set up even rudimentary DR capability (ignoring that the other expenditure/item will be a moot point if IT isn't running, anyway)
2. Lack of organizational will - the group has 30 initiatives to get done, and enough throughput (people and time) to handle 15. Your project got pushed to next year (for the third time)
3. Project problems - people leave, resources aren't available, contractors are unfamiliar with your environment, team members can't get along - you know what I'm talking about.
4. Too many silos - I know this sounds like a buzz-phrase, but have you ever been on an email thread of  >50 "replies" that keeps growing in the number of people on the thread - all to get something completely trivial done? Should it really be that hard to get a simple request filled? Should it require approval from 5 different people, and information from five others so one person a week from now can check a box?
5. The corollary to #4 is too much process. Ever been at a company where any change required three weeks of paperwork, two approval boards, and a three week waiting period?
6. The end-users reject the new project, either by not learning or doing what is needed of them, or outright and explicitly.

There are many more, but that's for another day. All of the above are project killers, for sure. But the one that I see again and again, and that I believe saps the productivity of IT like no other, is Lack of shared vision. Compared to this challenge, the others above are mere pretenders. Everyone has been both party to and victim of this merciless scourge of IT productivity.

Notice that all of the above are complete people problems, not technology problems. At a startup where two people could just get down to "clicking and doing" - and where there weren't a lot of decisions to be made, the technology project would be done in record time. It's the addition of more people, and more organizational issues that introduces the other challenges, and organizational complexity is something people create. 

Shared vision solves a host of ills. Typically - people want to succeed and will try, if they know what success looks like and how to get there. If everyone knows what they should be doing, and what the desired end-state is and why that is important, it greatly reduces the odds that problems #1-5 will be a significant obstacle. The Army spends a lot of time trying to train young leaders to distill and communicate "commander's intent" to their platoon or company. When difficulties are encountered, small units leaders can take individual action to circumvent or adapt to most problems, and still achieve the desired end-state. While they aren't always successful in these efforts, it's powerful when everyone is driving toward the same clearly-defined goal.

However - shared vision is incredibly difficult to create ex nihilo. Taking a group of people who have never done something before (of even trivial complexity), and explaining their individual roles in sufficient detail takes almost as much time as if you just did all the tasks yourself. Teaching a group of 30 soldiers a simple team task can take hours on end, and continual drill to keep it fresh. Obviously, that approach doesn't scale very well on tasks that can't be rehearsed.

This "top down" model completely breaks down when the task/project is something new, and that's the norm in IT projects, not the exception. To complicate this - how often do the leaders themselves actually understand (much less agree on) the desired outcome? That isn't necessarily a judgement on the leadership, because technology is changing so rapidly that it's nearly impossible for anyone to stay abreast of new developments across a wide range of disciplines and at sufficient detail for a "top-down" approach to work. Unfortunately - that is usually the way that most groups are organized - with an old-school, hierarchical, "command-and-control" structure with the authority at the top.

Take for example a fictitious organization that is consolidating a number of smaller IT groups into a shared services and shared datacenter model. At the point the technology folks were needing to make purchases and get to work in order to meet deadlines, the leadership was still trying to forge a common vision of what the purpose, scope, and desired results of the project were. No-one could buy anything or begin work until those decisions were made, and before those decisions could be made - everyone had to agree on a shared vision. The security folks could outline their requirements, but couldn't necessarily articulate what that would mean for the other groups, or vice-versa. The infrastructure folks weren't sure what they would be doing after the consolidation, and each group had concerns about what life would be like as a tenant on the final product. And all of this is completely necessary and normal. There's no judgement in what I am saying - all of those things do need to be done, and all of the people there are bright, dedicated, and impressively friendly and articulate, and they will get there. But, the end result remains the same, and is still sub-optimal - a lot of people are waiting on a few people, and the meetings continue day after day.

Another factor that needs to be considered is that very often the technical know-how and architecture expertise does not lie with the leadership, but rather with someone in an individual contributor role, or middle management. Frequently, the people who are best suited to making a decision around which technology or platform to adopt aren't the ones who have the title and corner office, but instead live out in the cubicle farm. These are typically the people who will be needed to make any project succeed, because they are the ones who will do the actual work, and are the subject-matter experts.

The pace of disruptive innovation in the technology world also negates the benefits of organic learning effects. Typically, if a company or team does something more than once, they develop some familiarity with the topic material, and the mechanics of completing the process, and they can deliver subsequent iterations of that same project in a fraction of the time initially required. As a case in point, consider the Boeing 787. The first unit took about 3.5 years to assemble and test. Today, Boeing is working to deliver 10 units per month. While learning effects are applicable across nearly any sector (doesn't have to be manufacturing), classical learning effects are dependent on the task being repeated a number of times.

So, how can IT groups short-circuit this process, and more quickly converge on a shared vision?

I'll throw it out there so you can mentally mull it over while I draft the conclusion to this!

(Click here for part II)

Why?

I meet with a lot of people, across a lot of different industries, in many states. You would think that every situation at each company would be a very different story, and while the people stand out, it is surprising how often the same themes come up again and again.

This blog is both for your benefit and mine. Writing it helps crystallize things rattling around in my head, and maybe something useful might end up in here from time to time that helps with something you're thinking about.