Where do the ITSM experts learn their trade?
Have you heard ServiceSphere's ITSM Weekly podcast? ("What happens when a CIO, a Service Desk Manager and an Industry Junkie Chat Weekly?!") If you haven't you should, not least so you can enjoy Chris's dangerous style. Along with Coté's equally unpredictable People over Process, it's my pick of the podcasts (I don't listen to many podcasts). Except when it is offending me.
The ITSM Weekly podcast features Chris Dancy, Matthew Hooper and Matt Beran. I mention it this week because one of the Matts cast aspersions on me. I forget which one - I was too busy sputtering.
He suggested that since I live in little old New Zealand I don't get much experience with big companies (which might be true if I spent my whole life here - more of that) and so that means I am not qualified to expound on ITSM (which is not true at all, even if I never left these shores).
The discussion was in the context of James Finister's great Core ITSM post about instant ITIL experts [that's another blog you must add to your list] so the implication might have been that I'm disqualified as an expert. That bit I definitely can live with as I don't think I'm an expert, just an opinionated and thoughtful philosopher of ITSM. (Though I know many ITSM experts, and still correspond with the ones I haven't offended).
As it happens I've lived in Australia, Hong Kong and New Zealand, and worked or talked with companies in ten countries. I've helped ANZ Bank (37,000), HSBC (300,000), HongKong Telecom, TAB (think Melbourne Cup betting data), National Australia Bank (40,000), Garuda, Qantas, Optus, NZ Police (15,000) and others. I've been in the data centres and service desks of dozens more, understanding their problems, trying to sell to them. So even if Matt was right about the need to understand big companies, I think I do know big companies.
But he's wrong. Or more precisely he overstates the case. Sure managing 600,000 CIs is challenging, or 60,000 calls a week. But dealing with 2000 calls a week is pretty interesting too when you have 5 FTEs. And managing 10,000 CIs challenges an ops staff of 2. The hardest ITSM job I ever did was four months at a site of 4000 users - man I did some learning there.
The mega-sites have the luxury of huge budgets to pay for silliness like CMDBs and other big-city-folk tools. Smaller sites just have process and their wits.
Big sites have so many staff that people can specialise and be a fulltime knowledge librarian or configuration data administrator or availability analyst. Those jobs are much harder when you only do them 4 hours a week. Try finding time for training or tools implementation (or, to be fair, process improvement). In smaller sites you get to be a jack of all trades and to understand many roles and processes. And you learn what's really essential.
So mega-computing isn't essential to forge an expert, though some exposure is a good thing to make them well-rounded. An issue I have with the world's ITSM experts is that too many of them seemingly ONLY know Fortune 500. I've talked before about the distorted view the pundits get when they only talk to sites big enough to afford them. Anyone who has worked in smaller orgs can see how much of ITIL is irrelevant or overkill or even wrong for the majority of sites.
Some folk may think people need to work with the biggest sites to know what they are talking about. I think "big" experts need to get out more.
And no I wasn't really upset - they're all three too nice guys for that. But it makes a better story.
Made in New Zealand 
Comments
results not experience
A real expert is measured by (a) their past results and (b) their referees. Nothing else means much else to me if I'm hiring. Note the word "results" not "experience". My above description would not suffice if I were interviewing me for a role. "I worked two years with Hong Kong Telecom." Doing what? What did you deliver? Describe that in detail (as if my shot memory could recall now, though interestingly the technical details of a database we fixed are as vivid today as then). How was that received - do you have enthusiastic referees? Who else worked on that with you? What did they do? Exactly what was your personal contribution? How is that relevant to this role?
Interviewing is a simple skill oft done badly. I learned from Selecting Winners and I've used what I learnt many times since.
One area where i wondered if perhaps there are more significant differences is in cultural change. The bigger the org the more byzantine the maze you have to navigate. Does that mean you have to have new skills to get a result? I don't think so - I think you play the same games; more of some, less of others.
yeh but no but
RE: (a) their past results and (b) their referees
However I've won consulting gigs and gotten jobs by outlining where I've royally mucked up in the past and what I learned from it. So IMHO it is not just past results & refs. Well - bad results can also be viewed/spun as positives.
Getting my ass chewed out by a CFO because I wasn't properly able to defend some assumptions in a biz case, or not knowing which ones should have been tested before submission.
Being humiliated by a Government Secretary in front of 40 people when my financially and theoretically sound ICT sourcing strategy / restructure had a 4-year horizon and the current Liberal Government was going to be ousted by Labor hence the likely changes in ability to force redundancies no matter what the return, rendered the ROI useless. Sheesh - I thought I was an ICT consultant, not a political expert ! ! PS: this one was in the V2 days - would have been fixed by V3 of course :-)
Shocking results can sometimes = valuable experience.
Colour blind
I still think one of my own worst mistakes was presenting the benefits/costs on a slide that was entirely green and red to a CFO who was red green colour blind.
This does highlight a catch with the current training. IT teaches you about ITIL, not about how to be manager in a typical organisation.
Expert or jack of all trades - need them both.
Oh the price of fame... glad you are getting benefit from the podcast. It's been more informational and fun than I thought it would be.
Couple of things.
Skep, I didn't say you were sucked at ITSM, though you your multi-tasking needs some work.
I was actually talking about LinkedIN, and how by looking up their past history you could see whether or not this persons background gave them the credibility to speak on a particular subject. My point was actually what others have here said as well as your own. A person who has demonstrated qualities for a particular task is the persons whose opinion we would trust the most.
When I ran the ITSM consulting team for Vigilant, I in fact looked for solution architects to have the experience were they needed ingenuity and a more broader understanding of the total outcomes. This usually came from working in smaller organizations.
As for the particular expert like Event Correlation, or CI Attribute models, I looked for someone who could really focus on that task and develop and harness the awareness of the gotchas. The "knowing what they don't know". And by your own admission this was typically found in larger organization where they could afford to have someone "focus" and be "dedicated" to a particular process.
Btw, Jim and Charles are both LinkedIN to me. Feel free to send an invite, I'd love to learn more about your background.
My apologies and love to my NZ fans. As Obama would say - "it was a human moment".
My Best Experience
You know, I really can't agree more with you on this one. I have spent the last 5 years or so consulting to large enterprise organizations about ITSM and IT Transformation and the things I go back to most often are my experiences 15 years ago running technical operations for a mid-market healthcare firm. We spend a lot of our time helping large organizations institute organizational and behavioral change - and I believe that a lot of those types of challenges are unique to Fortune 1000 types. But when we talk about core ITSM functions and process, the experiences that I rely on most are those times when me and my small team had to build and run our IT organization from the ground up. We were in the thick of it. We did not have the luxury of specialization - we had to understand how the process was supposed to work from start to finish - because we owned it start to finish. It's also why I'm a big believer in simulations. It provides a view (albeit limited) into how the whole thing is supposed to work in concert - something that most enterprise practitioners (and potentially their consultants!) have very few opportunities to experience in their normal work. Thanks for the great post.
Experience
I thought it was another great pod cast - and they did all big you up the previous week ;-)
Someone tweeted this quote the other day
"Experience is not what happens to a man; it is what a man does with what happens to him." Aldous Huxley, "Texts and Pretexts", 1932
I rather like it in the context of the whole Instant Expert discussion.
I think Matt raised a good point. There is a lot of generic ITSM expertise around, but sometimes we need advice from those with knowledge of a specific industry or situation. For that matter we sometimes need help from those with a specific expertise in one area of ITSM. A great service desk expert is not the first person I would turn to for help in building a cost model for services.
On the other hand we can learn a lot from those in dissimilar situations. And sometimes they aren't that dissimilar. I remember one meeting in a very big company where half way through a funding debate we realised we didn't know if we were talking about European billions or American billions. In truth the number of zeroes didn't matter.Apart from the numbers the same debate would have taken place in a small company about two options costing thousands.
Size isn't everything.
Experience of failure included in expertise?
Hi everyone - just back from more travel and jet lagged - so I will start by admitting I may not have digested this whole thread properly. I am supporting Skep a bit here as well. Expertise must be linked to successful outcomes. In accepting success is based upon a cycle of learning from mistakes, and a modicum of training - I must say I would not employ an 'expert' plumber based upon their description of mistakes they have made or seen - not initially.
No - I would place much greater emphasis on their successes backed up by references. Only then might I invite a discussion on lessons learned from mistakes seen or perfomed as a (final) differentiator. Again - although impressed by expertise of books and theory - its practical application of the theory that represents more valuable expertise to the customer. Theoretical expertise seems to be more important to the standing of the plumber within their own professional community (?).
Back to supporting Skep - I agree that its the range of problems or scenarios and perhaps complexity that seems more important rather than size of organization within which they occur. Both can occur within smaller organizations and the challenges of working with limited resources is more likely in smaller. This is why I tend to focus on helping IT organizations of less than 250 staff.
The larger organizations typically share the same problems but also present more organizational (polictical?) based buffers and run arounds. So, expertise has another dimension - has the individual got expertise of solving problems in organizations that share my size, complexity, political makeup and industry characteristics?
Which makes me think - will the ITIL Master qualification certify a professional's proven experience, expertise, in applying ITIL to ITSM problems and require proof of successful outcomes, or the theoretical application????? Will it certify an individual's success and describe the characteristics of the organization within which the success was achieved?