Printer Friendly Version

No one short of a masochist consciously seeks out trouble. If given the choice between relaxing on a beach and having an angry mob force its way into your office, most of us would choose the former. But as someone in a leadership position, you need to take the bad with the good.

In my last article, I discussed one of the most common intranet situations: Conflict resolution among intranet team members.

In this final part of my series on intranet leadership, I discuss three other situations that intranet leaders might have to face:

Dealing with unofficial developers

Leading an inexperienced team

Managing a team during a full system meltdown

Dealing With Unofficial Developers

One thing that separates an integrated intranet from a mixed bag of semi-related internal sites is its consistency of design, content structure, and technology. But in large companies -- especially technology-based companies with a lot of non-IT experts itching to fulfill their application needs outside of IT's involvement -- there will be those who don't agree with the corporate development standards set by the intranet committee, or will want to bypass the committee altogether.

This creates a very awkward situation: Unofficial developers want nothing to do with the intranet committee and IT, but when the system is abandoned -- because they leave the company or change departments -- guess who's called upon to adopt the system?

Unofficial developers and non-sanctioned applications will make an intranet less manageable in the long run. It's very difficult and taxing for IT to decipher the code of an application they had no involvement in. They'll have to reverse engineer the whole thing to figure out how it works before doing anything else with it.

Intranet leaders need to handle these situations carefully. They must make every effort to convince unofficial developers to work with the official intranet IT teams -- to include them into not only the technological infrastructure and failsafe measures, but also the decision making process. If all attempts to include them fail, and they still insist on breaking standards and bypassing the intranet governing body, intranet leaders must take a firm stance.

This is sometimes a semi-bluff. In my experience most unofficial developers create non-sanctioned applications to impress their superiors and their users. Intranet leaders must make it known to the unofficial developers, as well as their superiors and their immediate users, that the governing body will have nothing to do with the unsanctioned application during development and whatever happens to it in the future. This harsh stance will more often than not put some pressure on unofficial developers -- from their superiors and their users -- to think twice about breaking development standards and guidelines.

For more on the effects of unofficial applications and renegade development, see:

Guilt by Association: Effects of Unofficial Sites and Applications

Going to the Dark Side: The Dangers of Renegade Development

Leading an Inexperienced Team

There's often a mutual trust between experienced intraneters and their leaders that doesn't need to be explicitly expressed. Experienced intraneters know exactly what needs to be done and require little handholding from their superiors. They're confident in their abilities to make the right decisions, knowing that their leaders will be there to support them if need be. Good leaders, for their part, will recognize and trust the abilities of their team members, allowing them the autonomy to get their job done without constantly looking over their shoulders.

Go to page: 1 2

Printer Friendly Version