In Part 1 of this series on ‘Social’ IT Management, we discussed the inherent complexity of the IT management function, and how a more ‘social’ and emergent approach can represent a better way to manage IT.  In Part 2, we talked about the types of things that would be in a ‘Social’ IT Management Platform and the advantages of such a platform for enabling this social approach.  In this 3rd post in the series, we will discuss some Principles my esteemed colleague, Roy Youngman and I have found helpful in moving to a Social approach to IT management.

Some Principles for ‘Social’ IT Management

Over the course of several client engagements, Roy and I have developed a short list of principles to guide the way we help a client move towards a ‘social’ approach to IT management:

  • Create a baseline quickly, set the quality bar high, and make rapid, incremental improvements thereafter.
    • Rationale: The emergent and more parallel process implied by a social approach can feel a little intimidating at first.  “Will I look like a fool?  How will my co-authors react?”  We’ve found that the best way forward is to “Just do it!”  Get started, and damn the torpedoes!  But also, don’t ask people to begin with a blank slate.  While some clients are o.k. starting from scratch, most prefer a starting point – a straw dog, if you will.  Having said that, it’s important to make it clear that the straw dog is just a starting point – that the expectation is that this will be refined into something we can really use and be proud of!
  • Follow a ‘cascading’ approach – deploy in waves, starting with IT leadership, rapidly engage Process Owners, then members of Centers of Excellence, and finally everyone.
    • Rationale: To be frank, there is something “1.0” about this cascading approach – it’s rather top-down which flies in the face of a truly emergent, egalitarian and collaborative approach.  But most organizations have a hard time jumping from the “1.0” to the “2.0” paradigm.  So, we’ve found a “1.5” approach to be a useful interim state.  It acknowledges the special role of the IT leadership team, and the reality of engaging them first.  It also puts them in a better position of experiencing the new approach and being able to model desired behaviors.  The trick is not to get stuck in a mode where everything has to start with the IT leadership team.  Get the process owners appointed early (they usually already exist, even if that role has not been formalized) and they in turn will engage process teams.  Typically, there are Centers of Excellence or Communities of Practice that are already blogging and participating in wikis (the IT architecture community is often an early adopter) so it is a natural to bring them into the tent.  Just be careful to not shut down their activity by legitimizing it.  They thrive as a 2.0 collaborative community because that was a truly emergent practice for them.  Legitimizing this practice as “leadership sanctioned and monitored” can shut it down, or drive it back underground, so don’t be too heavy handed in this sanctioning – shine a light on it, but not a floodlight!
  • It is far more important to instill pride-in-workmanship than to install a complex review and control process.
    • Rationale: Coming from the 1.0 world, it is natural for leadership to want to place controls all over the wiki environment.  I recall one client executive, when I first described the plans for their ‘social’ IT management, looking aghast, and saying, “You aren’t seriously suggesting we’d let stuff go up on the Wiki before it was fully vetted and approved?”  This is a natural reaction, but must be resisted.  The power and wisdom of the crowd to shape and continuously improve is relentless – if you let it be!
  • A Power-Law Distribution is expected and good; a few will contribute a lot and some will contribute little, but everyone has something worth contributing.
    • Rationale:  There’s no way around this.  It’s a well-researched and documented phenomenon.  Your major contributions will be limited to a small proportion of the IT organization.  Many will seemingly be bystanders.  The fact that they aren’t in the Wiki every day, participating in discussion threads, creating Wiki pages does not mean they aren’t participating or getting value from the it – they are.  Don’t be put off by it – just accept it and be thankful.
  • Leaders must demonstrate their commitment ‘by example’ while avoiding the temptation to criticize (which will be initially easy).
    • Rationale: Early on, people will look to IT leadership to see if they are “walking the talk.”  If they are, others will join the revolution.  If they are not – this too shall pass!
  • Consistency is a key to success; if every content page looks different, the Social platform will not create a sustainable social web.
    • Rationale: The emergent properties are a good force to tap, but can be a double-edged sword.  We’ve seen many clients with SharePoint (or Lotus Notes way back) where people were encouraged to participate. And participate they did – in spades!  Before long there were SharePoint sites everywhere – each with their own structure and style.  Pretty soon, the collaboration ecosystem is un-navigable.  You have to strike a balance between emergent and structured – and consistency in style and structure are important to sustain this.  Provide templates to make it easy for people to conform to a common style.  And have active Collaboration Managers and Wiki Gardeners whose role includes encouraging a clean and consistent style.

We will end this 3-part series here – but please keep an eye open for upcoming posts that further explore our work in this space.  Or ping Roy or me for a discussion on how this might apply in your organization.

And, of course, please comment on your thoughts and experiences – this is an emerging space, and we all have lots to learn about social means to improving IT management!

Graphic courtesy of Literate Web

Enhanced by Zemanta