TUTORIAL IT

An L D Consulting Tip you Shouldnt Miss Plan your Obsolescence

A few weeks back I was all set to start working with a friend of mine. I rate her very, very highly and she was going to be a real asset to ThoughtWorks when shed join. A couple of weeks before her joining date though, I spoke to her and learned that her client cant release her from her current project. When we caught up, it appeared that her employers hadnt communicated her planned exit to the clients and at the eleventh hour they threw a fit. My friend and I spoke at length about possible solutions, but it looked like she was irreplaceable on her project -- given that she was leading it. While I admire my friends decision to stay back on her current job to serve her existing customer, it seemed to me that her project was at a really high risk if it was so dependent on her.

On Agile teams we often talk about the truck factor:

While being hit by a truck isnt a very pleasant metaphor, you could easily substitute that occurrence by people leaving their jobs, going on vacation or falling sick. The smaller your truck factor, the more risk your project is at. The larger your truck factor, the better youre managing your risk. So if all that needs to happen for your project to fail is for you to leave the company and go, then I argue your project is already at a really high risk and theres something you need to do about it. Ive often heard my colleague and ThoughtWorks consultant, Angela Ferguson talk about the importance for consultants to plan their obsolescence. Its an interesting thought - because if youre the hero on your project, you perhaps want to retain that status. Unfortunately, being a hero isnt the best thing for your clients! So in todays post, I want to talk about three simple strategies that can help you plan your obsolescence in your team.

On typical, leader driven, command and control projects, theres only one person who has a vision for how the final product takes shape. They understand the strategy, the release plan and even plan the little bits of work that each member of the team performs. As it turns out, when these people leave, the project is in absolute shambles. Agile teams mitigate this risk by applying the practice of Collective Ownership. The idea is for all members of the team to contribute ideas to every segment of the project. This defies traditional wisdom where a single architect is responsible for unifying the vision for your project. Agile however, is based around real-life experiences with human behaviour, and the one thing we know about people is that they make mistakes! Architects/ Chief Designers/ Project Managers all make mistakes - and theyre not wrong to do so. Unless youre dealing with a trivial piece of transactional work, its impossible for one person to know everything about everything. By ensuring that everyone explicitly understands and contributes to the projects design and planning, you encourage diverse perspectives, and reduce the risk of letting one persons mistakes fail the project.

So the next time youre planning out some fancy solution-ing workshop, include the rest of your team members in it. Try an Agile Card Wall to track and manage your projects progress as against a plan on Microsoft Project, which only you can see. Yes, youll need an electronic version of your plan and you may have distributed teams as well -- in that case use a collaborative project management tool like Mingle. Remember, you need to move from a point where its your project plan, to a point where its the teams shared vision.
The other thing youll see on Agile teams is the act of Pairing. The idea is to have two heads solve a problem instead of just one, thereby achieving some interesting benefits. Firstly the quality of the work goes up, because while one person is creating the output, another person is checking it. The increased quality always leads to big savings on the project as time goes on.


The other, more intangible benefit of pairing is that of knowledge sharing. Constant rotation of pairs ensures that every understands every part of the project almost equally well. This again helps ensure a higher truck factor on the team. So think about this from the perspective of L&D and elearning projects - how about having instructional designers pair with builders and project managers. How about having builders pair with testers and how about having SMEs pair with all the different roles? You can build a truly cross-functional team that can deal with the risk of losing a random person.
Last year I read a really interesting article on the Harvard Business Review blog about why the wrong people get laid off at their jobs. From the blog, "Legend has it that Gordius, king of Gordium, tied a knot so intricate that no one could untangle it. There were no visible ends. It lasted for centuries." The article discovered that the people that often got laid off were the people whose work the company understood quite well. It often didnt matter that they were superb workers - the fact was that people understood the risk of doing without them. On the other hand, people who were Gordian Knots - who performed well, but whose work no one understood were the ones that seemed to keep their jobs. While this strategy may seem to help you as an individual, its more likely to backfire. Firstly, if no one understands your work and youre not as good as you think, youre likely to get fired anyway. More importantly, the mystery around what you do may protect your status but hurts your client, as a consequence hurts your employers and then hurts you. The examples of the AIG and Lehmann collapse, finally triggering the downturn there for us to see.

So if you really care about your clients and your employers, spend some time each day, demystifying what you do. Refine your job description, create standard work thatll help you teach others what you do, coach others to perform your tasks, write a wiki page for each of your individual capabilities. Create a toolkit for a potential replacement. Think as if you were going to roll off the project tomorrow!

---

While Ive put my friend on the spot when writing this article, I realise that despite all the great wisdom out there, I havent been great at planning my own obsolescence. Which is why youll see this post when Im on vacation - I want to see how my pet project performs in my absence. Ive done what I can to narrate my work and hopefully the team is fully empowered to make my decisions when Im not around. Over the next few months, I want to ensure that I detail each piece of work that I do for my employers. If anything, thatll give me the opportunity to try different roles in the organisation - if the opportunity comes by.

What do you think about the idea of planning obsolescence? I can understand the choice of words can be a tad depressing - though Im keen to know from you if my argument made sense to you. Do let me know what you think - Ill look forward to your comments on this post.

Available link for download