Pages Menu
Categories Menu

Posted by on Nov 7, 2008 in Featured, Uncategorized | 0 comments

Personal Heroics and Tribal Knowledge (Heroes or Villains?)

Personal Heroics and Tribal Knowledge (Heroes or Villains?)

In the course of IT Evolution, many IT organizations at one time or another find themselves entrenched in a cycle where crisis seems the norm and tactical firefighting takes precedence over strategic planning.

These periods are usually preceded by an increase in organizational and technical change that is typically driven by increased demand from the business for new or modified IT Services and Business Applications.

Many times this period of change stresses processes (documented or assumed) and causes the organization to break from their standard practices and resort to a reliance on Personal Heroics and Tribal Knowledge. For a period of time, these behaviors can be successful and in many cases are viewed by both IT and the Business as a suitable practice:

  • IT sweeps in during crisis and solves Incidents that have highly visible business impact
  • The Business swoons and rewards the heroes with praise and sometimes cookies

Let’s face it, we all love to feel like the hero and in many cases enjoy the dynamics that are at play during a crisis. Adrenaline flows, pressure builds, people are panicking, phone calls and emails are flying, and in the middle of the maelstrom we are doing what we do best and all eyes are on us. Then when we finally find the solution and the problem is resolved, the Business stands in awe of the Voodoo that we do.

Unfortunately, this support model is seldom sustainable in the long term. Businesses are fickle and cheers quickly turn to jeers when the same issues continue to occur week after week. IT employees go from loving the spotlight to hating it and any semblance of a successful IT Organization is quickly overwhelmed by the perception that IT is not doing enough to keep things running smoothly. This is the point at which the line between Hero and Villain blurs and the behaviors that were once admired are now despised.

Additionally, most often the knowledge needed to effectively manage the crisis is locked away in the heads of individuals and can only be used if those individuals are available or are directly involved in the crisis. When those individuals are removed from the situation (either temporarily or permanently), the ability to respond to the crisis and recover from that loss of knowledge can take some time.   Ready and ongoing access to that knowledge is vital to ensure the most effective and efficient enablement of your key processes

The dynamics that drive these cycles are seldom simple, and many times the business can shoulder as much blame as IT in the ultimate root causes (Unrealistic expectations, too much change in a given period of time, unclear goals, etc). At times when an organization is smack dab in the middle of one of these cycles it is difficult to see ways to break the cycle or to avoid it in the future.

There are however a few things that you can do to insulate your organization from the effects of these cycles or at the very least provide a basis for quickly adapting to the changing needs of the business.

How to be a Real ITSM Hero:


  • Reserve “Personal Heroics” for true emergencies
    • When every incident is treated like an emergency, you dilute the value of both your process and it’s participants. Save your “Hero” responses for incidents that truly have the highest business impact
    • Being a “Hero” does not mean you need to abandon your processes. Your processes should be defined in such a way as to allow the process participants to act “Heroically” while still executing the process and ensuring that the outcomes of the process are being achieved
  • Training and Communications
    • Train all of the processes participants on their roles and responsibilities and the expected outcomes of the processes
    • Communicate to process participants about the benefits, goals, expectations, Critical Success Factors (CSFs), Major Activities, and Key Performance Indicators (KPIs).


  • Processes should be well defined and readily understood
    • It seems like such a simple concept, but if the processes are not documented there is too much room for interpretation by the participants and no way to enforce conformance
    • Well documented processes allow you to “Normalize” the expectations of all process participants regarding their roles and responsibilities
    • It further allows you to set expectations for your customers regarding your ability to deliver the expected results in a consistent manner
    • Additionally a well documented process provides a basis for Continual Service Improvement.
  • Process documentation should be easily accessible by all process participants
    • Process documents should be current and be easily accessed (either via a website, sharepoint, file shares, etc) by the process participants in the event they need to understand key process details
    • Process documents should link to other appropriate process artifacts where possible to more easily facilitate understanding and usability of the process during it’s execution


  • Technology should enable the process rather than define it
    • Whatever tools you employ should truly enable your process rather than constrain it
    • Tools should also effectively support Business Rules defined by the process and assist users in executing the process wherever possible
  • Technology should provide sufficient data for measurement of KPIs
    • Tools should be set up in such a way as to allow easy measurement of process performance relative to defined Key Performance Indicators
    • These measure will provide further basis for your Continual Service Improvement efforts


  • Knowledge should be documented and readily accessible
    • Knowledge is powerful, only if effectively managed and made available to those who need it
    • Knowledge should be transferred from the minds of the possessors and placed in a common repository whenever possible
    • Standards for documenting and distributing different types of knowledge should be defined and employed
    • Knowledge should be easy to find and access by those that need it in the moments where it will provide the most value

These things in and of themselves will not necessarily prevent the cycles that typically drive a breakdown in process structure, but when employed as part of a larger and organized Service Management program can go a long way in providing a stable foundation for the discipline required to more effectively manage and minimize the impact that these cycles can have on an IT organization.

For a good idea of what a set of well documented processes look like, check out the Pepperweed Process Model.

For a look at some of the best of Hollywood’s greatest heroes and villains of all time, go here (I know, in no way is it related to IT Service Management, but it is fun!).

I look forward to the next chance to share with you.


Post a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>