Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
Rookie intraneters, however, require a bit more guidance. They might not have the confidence to determine if what they’re doing is right — especially if they’ve never worked on an intranet before — and will second-guess every move they make. They’re also usually overly concerned with what their superiors and colleagues think about them and the job their doing.
Intranet leaders need to be more visible in an inexperienced team — to provide direction, support, and even validation. When problems arise and tough decisions needs to be made, leaders should guide them through the process and allow them to find the solution on their own. Leaders shouldn’t solve the problem for them because rookies might wind up using their leader as a crutch, running to them whenever they hit a roadblock. The role of the leader here is to train rookie intraneters so that they will eventually have the experience and confidence to be more independent.
Having been in leadership positions in the past, I find that allowing rookie developers to talk through their problems and providing them with an ear to bend (and dropping subtle hints for them if they’re really stumped) will usually give them one of those eureka moments where they discover the answer on their own. This gives them the sense that they solved the problem on their own rather than just being told, “Here’s what you need to do.”
The goal with managing a rookie intranet team is not to do their job for them, it’s to instill upon them the confidence to do it themselves. It’s far better for their development to give them a sense of accomplishment as opposed to simply giving them orders to follow.
Managing a Team During a Full System Meltdown
There’s perhaps no greater test of an intranet leader’s abilities than what he or she does during a full system meltdown — when unexpected problems threaten not only the immediate availability of the intranet, but also the future integrity of the system and its content. The actions taken from the point of the meltdown onwards can have permanent impacts on the longevity of the system.
This is the true test of a leader’s fight or flight instinct. It takes a special breed of leader to grab control of a seemingly uncontrollable situation. System meltdowns lead to confusion, stress, and even panic — amplified tenfold if the intranet is a mission critical component of the organization. Intranet leaders must help those below them move beyond the initial shock and confusion of a crash so that they can concentrate on the task of recovering the system.
Intranet leaders need to oversee the technical system recovery procedures, the various intranet teams tasked with this recovery, and the hundreds or thousands of users who will be asking the same question, “When will the system be back?”. Although each intranet group — content managers, developers and designers, network and system administrators, disaster recovery personnel — will understand what’s required of them to put Humpty Dumpty back together again, it’s the responsibility of intranet leaders to coordinate this effort so that team members don’t end up bumping into one another.
While system meltdowns will definitely have a negative impact on the user community, intranet leaders’ abilities to triage recovery tasks and manage the staff will determine the severity of this impact. With all the various intranet personnel working toward recovering the system, intranet leaders must examine the situation quickly and prioritize the recovery process and reallocate resources if necessary.
For more on the technical aspects of system integrity and disaster recovery see:
The Keys to Maintaining Intranet Integrity, Part 1 and Part 2 Introduction to Disaster Recovery Planning
Closing Thoughts
A true intranet leader is one part technical skill and one part interpersonal skill. They must have the ability to manage both the system and their staff with equal proficiency. Leadership positions should be earned through a person’s past actions and experience in the trenches. But all too often, it’s acquired through nepotism or deceit.
The means by which leaders acquire their position can tell us a lot about the character and integrity of the person holding that position. Situations such as those described above and in the previous installment in this series do a lot to expose unqualified wannabes and reveal true leaders.
Paul Chin is an IT consultant and a freelance writer. Previously, Paul worked as an intranet and content management specialist in the aerospace and competitive intelligence industries.
