If you were to take flight, land in the middle of some random organization in the United States, accost an employee in the hall, and ask them what are the biggest problems facing their organization, chances are they’re going to say communication is a problem. It may not be number one, but it’ll be in the mix if it’s not. Communication is such a great problem that there are many great thinkers that have made their careers off of trying to help businesses address this very problem.
Solving the great communication problem is something that many businesses work very hard at and spend a lot of money addressing. One of the most common solutions is to increase broadcast. It’s not uncommon to hear executives say, “We just need to tell more people what we’re doing.” Translation: “We need another email distribution list and maybe we should install Sharepoint!” The rub is that by cranking up what they believe is signal, they’re in turn boosting noise for many others. It’s simple to see why, one person’s signal is another person’s noise. The harder we work to resolve the communication problem, the further it seems to get away from us.
The key attribute of the great communication problem is that it’s a problem to be managed and not solved. Depending upon one’s location in an organization, the level of abstraction or detail that some piece of communication has may or may not be found useful by the reader. Operational workers see a mass email from their CEO discussing strategy as hot air and delete it. An executive trying to have a discussion with an employee about work conditions gets bored with details. In their white paper, “Creating Lean Leaders”, Kaufman Global discusses the some of the problems associated with mega, macro, and micro processes. To appropriately manage the communication problem, we should really look into how we organize ourselves
There is a belief that for the modern employee to be successful, we need to group like workers with like. This is especially so in IT, there’s a database administration group, a system administration group, a network administration group, a helpdesk group, and so on. It’s not necessarily a bad thing, this. For one, it homogenizes performance. The cost of individual underperformance is managed by group effort. On the positive side, there’s opportunity for mentorship and growth as one hones their technical skills. And given the level of breadth and complexity of many IT undertakings, there’s some work that is just too much for one person to do.
But the cost of grouping like with like is that we begin to naturally create silos within the organization. For one, each group develops their own language. Inter-group discussions slow down as workers have to find a common language to discuss their problems. This is not only so in IT/non-IT group pairings. It can happen even in between IT groups. The second problem is that vital information doesn’t tend to slip beyond the confines of the group that manages that information. In all the bustle and labor of the day, we tend to become separated from the value propositions we’re employed to deliver and we focus on operational excellence. The easy example is the common-place gap between developers and those that maintain the environments their applications run on. It’s such a phenomenon that it’s near certainty that any IT conference will feature at least one joke about the other group. It’s not hard to imagine the frustration of application developers who feel that the sysadmins are hollowing out their application servers and creating poor performance. And it’s not hard to imagine sysadmins who feel the developers are greedy for resources and don’t think about the other needs of the organization. In reality both groups are probably right though not in such harsh terms and not to the extent they imagine.
It would appear that the natural thing to do would be to group individuals according to the services they are employed to deliver. So instead of having a pure database administration group, the DBAs would also group themselves with the developers and system administrators associated with their services as well.
This type of ordering isn’t new but it is still insufficient. And ludicrously rare to see even today. Common language and information problems get assuaged within IT but the larger problems of how well those services align with an organization’s strategic position and its individual value propositions still remains and will remain until the appropriate business partners have been engaged. Engagement isn’t quite right. They can’t just be engaged but receive decision rights. They need to be involved with IT in making decisions regarding the services they use. Enter demand-side governance. This seems scary to IT workers. The idea that non-technical people could influence technical decisions is scary. On the flip-side though, the idea that non-business people (in IT) could influence business decisions is also scary. So IT and the other departments agree to keep each other at arm’s length. The consequences of this behavior include the business not being able to enumerate its needs intelligently, long-running and underperforming projects, and IT deploying unusable tools to the business. Sound familiar? The guilt for failure to perform is uniformly distributed.
Business decisions are IT decisions and IT decisions are business decisions. This realization, or rather the lack thereof, is what keeps many businesses in a state of mediocrity. In 2005 (according to one study), only five percent of Fortune 500 companies had installed CIOs on their board of directors. I remember hearing the number is around thirty percent today. Amazing.
To bring this back around, it’s not enough to bring operational IT workers together with users to ensure operational excellence in terms of performance, uptime, and tool delivery. It’s absolutely imperative to get decision makers, people who have the ability to sign a check and spend some money, to make sure that the right things are being delivered. Get the managers who depend on the outcomes your tools are delivering in the room. Be prepared for questions like, “Why the hell are we even here?” Fair enough. To start, just answer that you need them to help you make them successful. Start with hygiene factor problems. Let them gripe about how terrible the software is, vigorously take notes, and bring them back to your teams. Find the wins that can build IT’s credibility in the business place. Don’t just go for low hanging fruit, go for real wins. With enough wins, the conversation can move from what they need to be making things better to asking what we need to do to make sure we’re doing the right things for the business and doing them in the right way.
Doing this well, doing it consistently, and doing it over the long term while greatly enhance your organization’s ability to truly deliver on their stated goals. If your CIO doesn’t sit on the board, you might be able to help them get there (although that depends on the business acumen of the CIO, an ability that only a percentage have today). If your demand-side governance teams are effective, you’ll be improving the communication situation in your organization. IT and their partner business units will be getting precisely the right information from each other at the right time in a manner that’s easy to digest and disseminate.
You’ll be better prepared to successfully roll out Sharepoint when the time comes.