Let me level with you—great customer service doesn’t motivate me. Yes, I am a customer from time to time, but I really just want to transact and get the hell on with my day. Recently, a group of enterprise software providers formed a coalition with the goal of shifting the design of enterprise IT services to the user, rather than forcing the user (or the customer, or the employee, or whichever moniker you prefer) to adapt to the constraints thrust upon them.
I’ve worked in enterprise IT for 13 years and I’ve used lots of systems. Working in technical support and in network operations, I had 99 problems and the software I was trying to use every day to do my job shouldn’t have been one of them. Why shouldn’t I have nice looking software when I’m in the office? Why can’t I be offered the kind of user-experience of …
It’s not often that anyone would bother to review a white paper. After all, a white paper is usually free (perhaps in exchange for your email address) and not that much of an investment in time to read. A white paper has come along that I really must point out to you, though. If you’re interested in improving your IT services, this particular one is valuable, and you don’t even have to pay with your contact info.
I’ve long believed that the parents of ITIL® and Knowledge Centred Support (KCS), (AXELOS and the Consortium for Service Innovation, respectively), should join forces in some meaningful way. This white paper looks like being a kind of first step. Though, I don’t know what might come after. AXELOS and HDI have come together to release Synergies between ITIL® and Knowledge-Centered Support (KCS℠). Written by Roy Atkinson, John Custy, and Rick Joslin, the paper …
Disclaimer: Most of my readers will know that I’m affiliated with Zendesk. Zendesk do pay me for content and consulting on ITSM and knowledge management stuff. This book review I’m about to do, which covers mapping Zendesk functionality to ITIL processes, has not been commissioned by Zendesk, nor endorsed by them. It is my objective opinion as an independent consultant.
A couple of weeks ago Crystal Taggart released a short guidebook to the Amazon Kindle store. This isn’t the first guidebook she’s released; there’s also a Quick Start Guide to using Axure 7 for rapid prototyping and 10 Secrets for Launching a Software Startup. Crystal describes herself as a technologist and entrepreneur who specialises in creating and implementing solutions that solve business problems. Her most recent book, a Zendesk Quickstart Guide is a step-by-step guide to mapping ITIL processes quickly and easily.
It’s no secret I’ve always liked Zendesk for how it looks, but …
I’ve heard more than once that the Pink Elephant conference was something to behold. And if I was only to go once in my lifetime, I wanted it to be this year with Canadian astronaut, Commander Hadfield, as the keynote. So, I ponied up with the outrageous fees that IT conferences can command and I’ve been asked, “was it worth it?”
As a fee-paying delegate, (rather than being there on a speaker ticket), my plan of attack was much different. With so many tracks and no lunch breaks, one really does need to have a plan of attack. I couldn’t just stroll around and visit what took my fancy at the time. I had my book and my highlighter and I had the four days mapped out. It came a little unstuck on day 3, but let’s not talk about that.
I can’t rattle off a few gems without first giving …
Props to @MylesCarrick for the title. He sparked a conversation on twitter this week with that sentiment. So, I’m wondering what you look for in a document management system.
Here’s a few things I can think of:
1. Some sort of built-in, configurable governance for file naming convention—A lot of the problem I have with document management systems is that people still name things randomly and folders are often filled with unrelated, random contents. Some guidance for naming convention that didn’t rely on verbal reinforcement would be ideal.
2. Files and folders default to public. Explicit exclusion for folders/files that must be private—One of the challenges of knowledge management is that, as an organisation, we don’t know what we know. Transparent file storage allows for discoverability when we’re searching for something. The current sharing models require us to explicitly ALLOW access, rather than explicitly DENY.
3. Semantic clustering and recommendation engines—Related to my …
I’ve talked about my preference for ordered taxonomies before. In another article, I even claimed that folksonomies weren’t scalable. Everything is Miscellaneous: The power of the new digital disorder, by David Weinberger may have just changed my mind. Published in 2007, the book isn’t new, but I came across it on a list of recommended reads for knowledge management.
Weinberger, co-author of the international bestseller The Cluetrain Manifesto, has an easy-to-read conversational style. In Everything is Miscellaneous, he lays out humankind’s fixation for heirarchy across history. “ur knowledge of the world has assumed the shape of a tree because that knowledge has been shackled to the physical.”
From Aristotle to Apple and Amazon, the way we work with information and knowledge has changed. Apple freed our music libraries so we could order our music how we wanted. Amazon clusters books in as many ways as we can so that we may …
It became pretty clear in 2013 that the service integration wave was building up. It was discussed at the conferences and it’s been covered in blogs. As more IT managers fold the point-solutions of today in with traditional vendors and legacy systems, it’s more balls in the air while you maintain happy user and customer relationships, design cohesive SLAs, and ensure you don’t underestimate your total cost of ownership, amongst a myriad of other things.
And what of the contribution of knowledge management? Your records of the who and how of escalation become more important when there’s more than one place to go—and that might be dependent on the system or the time of day or any other factor. Your goal with your users, of course, is to hide the stitches, and they don’t care who the various service providers are. They only care that the services are working as …
If there was ever a time when gender bias should be on the table for discussion, it’s 2013. I recently answered a question on the Back2ITSM Facebook group about diversity in IT. This post includes much of what I said there, with a few extra bits.
I agree with the questioner that the appearance of quotas and affirmative action can create a sense of exclusion But, the inequality exists and without efforts in a number of areas, the tech industry at large will miss out on access to a pool of amazing talent. It won’t be solved with one single action. This goes right back to the beginnings of education and STEM classes. And human nature means we find comfort in being with like-minded folks. It’s not that surprising that guys dominate IT. The majority of school teachers and nurses are females, just to throw in a comparison.
Let’s fast …
I was invited to present a workshop as a guest speaker for a team off-site, recently. It was an express introduction to knowledge management and the group I presented to were enthusiastic about knowledge, even though they hadn’t yet implemented any KM programs. This particular group of people are managers in different roles across the IT operations team. There are a couple of challenges for them to work with: their team is distributed around the country, and they work in a traditional industry that could be subject to fallout from an ageing workforce.
When I do a knowledge management workshop, I like to start by getting everyone’s name and job title. There’s nothing new in that, and it’s more helpful to me than them, especially when they already know each other.
But I also keep three columns of numbers.
The first is how long each person has had that specific role; the …
Today’s post comes from Michael Domanski and Sean Murphy. Michael is a software developer and Sean is an entrepreneur with a history of business development and customer support. Together, they are bringing tools for knowledge management to small teams. Learn more about Knowledge Flow.
What’s the most unnerving thought when interviewing a high profile expert?
Just imagine how depressed you would be after securing an interview with a subject matter expert and then conducting an interview that is a mix of stuttering and banal questions. I had tons of angst myself when I started conducting interviews. It’s not easy to interview an expert, mainly
because of the depth of their knowledge. It gets even harder when you realize just how precious their time is. To make my experience even more stressful, I knew at some point some of those people may become my
customers. Thus, I not only needed information, I also needed to make it look as if I knew what I was doing.
Since there’s little information (very little) about this subject on the internet, I decided it may be a good thing to share
some lessons learned. Let’s jump in.
8 tips to guide you through interviewing your experts
1. Research the subject matter and people you want to contact
Your interview always should have a main subject. E.g. if you were to talk to a SEO expert on the matter of recent
changes to Google algorithms, research as much as possible on your own. This background will enable you to
ask questions that are informing to your readers and provide new or niche insight into the subject. Also, pay
attention to the background of the person you interview. Ideally you want to have a list of people to interview that you
have almost personal relation to.
2. Rules of engagement
I usually contact people via email. It’s almost a given that experts get a ton of email every dail. At this stage you
should know them well enough to write an email that will interest them enough to contact you back. If you don’t
think you can write a good email, read “Writing that works” by Kenneth Roman (make sure it’s the 3rd edition). Do
write a personal email, e.g. when I wrote to Adii Pienaar from WooThemes, I’ve included a small personal hook,
which got a brief discussion over email and a comment: “Nice email, got my attention”.
3. Draft an interview agenda
You know the subject, you know the person you’re going to interview. Now, with your target length of time for the
interview in mind, draft an agenda of the key items that you want to discuss. I usually write it and then review it with
my co-interviewer. We discuss it and then send it to the interviewee in advance so that they can prepare. My advice
is to always have someone have a look at it.
4. Have a co-interviewer
The main reasons I can think of for having help is:
Fluidity. If you are out of questions for the moment he can take it from there.
Notes. I added tip on taking notes and having help makes it much easier. One of you asks the
questions, one analyzes the answers and takes notes.
Brief and debrief. You can discuss the agenda and discuss what you have learned.
5. Prepare the environment
There are two types of settings for an interview. First type is “in person’ interview. It has the obvious benefit of you seeing the person you’re talking to. This gives you more clues about the feelings someone can have about the subject. On the other hand, those types of
interviews are expensive. They require you to secure a proper space and time to get there. You should never do an
interview in a space not private enough. I personally don’t believe in “coffee shop” interviews. The list of
distractions in such places is very long and you want the undivided attention of the person you’re asking questions.
Second type is the remote interview. Skype and gotomeeting are two most used tools for this kind of interviews.
While the interview can be much harder, you can only hear the other person and see facial expressions or body
language, it has some logistic advantages. The whole setup is dirt cheap and the time spent on getting there is exactly 0 seconds. It’s also very useful when interviewing people over long distances.
6. Take notes
Take note of key words and phrases that your interviewee uses and pay attention to any term they repeat. Try to
write down things as they’re being said. You can draw your conclusions later. This is easier if you work with a
partner. That way, you won’t have to worry about losing the thread of conversation (believe me, it’s hard to take good
notes and follow the conversation at the same time, pay attention to how a good lecturer structures their
7. Keep it on course
If you said the interview is going to take 30 minutes, be ready to end a few minutes before. A good guide is the
subject’s energy and engagement. If they seem happy, you can go over the promised time. If they’re showing fatigue,
try to wrap soon. It’s important to avoid data overload. If you ask too many questions, it can be hard to process them coherently. Having a planned agenda, with some questions and a general thread of thought will help you a lot.
In case you got something wrong, at the end of the interview be ready to show or read a short summary to your
subject. While this is not as good as a thought-out follow up, it gives you the confidence, that at a high level, you
have the same view of the problem as the expert you’re interviewing. This is the end of the interview, but this is not the end for you and your partner. After the interview you debrief on the
situation, what you have learned and what you think is important to take note of. I also try to mention any
conclusions that seem obvious to me and that I drew based on the interview.
After the debrief I work on the formal summary of the interview. This may seem like a lot of work (and it is) but it’s
very significant since:
it enables you to confirm your conclusions with the expert
it makes you think hard to create a coherent picture and wrap it into words
Personally, I believe this is a step you should never omit. Even if you eventually end up not using what you have
learned, you will have a good notion of why it’s not useful. You will also be able to follow up with your subject and, if
you collaborate on it with your partner, you’ll be confident you haven’t overlooked obviously important information.
Fear of missing important information or the nuance of an insight are two reasons why I always email the
summary to the interviewee. Most experts are used to not being understood completely right away. Because of that,
most of them will read and correct what you got wrong. This is very similar to taking an exam and submitting your
answer. It’s crucial to perform this step, since you are going to base your action, or lack of it, on the conclusions
you deduced from the interview.
If you’d like to read more about conducting interviews, I recommend starting with this blog post. Having that in
mind, the set of rules outlined above is solid enough to get you through most interviews with very good results. I’ve been
using it now for two years, and it’s been tested by Sean (for a much longer period of time). Yet we’re still
curious what you think of it, so don’t hesitate to send us your feeedback.