11 June 2008

And that’s alls I know…

Before I left my last job, a colleague asked me to impart whatever wisdom I had. Here’s what I said.

Being a Consultant

Everything I know about consulting can be summed up in the following:

  1. Listen to your customers.
  2. Understand your customers.
  3. Be their trusted advisor.

Listen to your customers. A consultant’s #1 skill is listening. If you can’t listen to your customers explain their problems and needs, you won’t get anywhere. I’ve worked with others who, because they’re consultants, think they already know what the customer needs before the customer has a chance to describe it. It is, after all, the consultant’s job to know what to do; that’s why people hire us in the first place. But this approach is wrong-headed for a couple of reasons. First, “what to do” is highly dependent on what the problem is. Without listening to what makes this customer special, it’s hard to say off the bat what’s right for their situation. Second, listening to the customer gives them confidence in you. They see that you take them and their problems seriously. And finally, often people just really like to get their problems off their chest. When you give them a friendly ear, they unload, and they feel relieved already just because somebody is listening to them, even if you haven’t done anything yet.

Understand your customers. So you have to be a great listener. But the next step is taking what you hear and figuring out what to do about it. This is where the “consultant” part comes into play — your special expertise, the reason people hire you instead of doing it themselves. You need to understand their problems as if they were your own and apply your expertise to give them workable solutions. And by “solution”, I mean the whole deal — not just a tool that fixes their problem or a process sketched out on a piece of paper. You have to consider the whole kit and kaboodle, including the hurdles your customer may need to overcome with their bosses or colleages to actually do something with the tools and processes you’re suggestion. The “solution” should be a way to actually solve their problem, taking into account everything you’ve learned about their situation.

Then, when you have solutions, you have to deliver them in a way that your customer understands. You need to be patient, because they do not have your expertise (remember, that’s why they hired you). You need to be diplomatic, because often your solution will involve telling them they weren’t doing something in the best possible way before, and they could do better. Of course they do want to do better, but they don’t want to be embarassed or feel scolded in the process. This is what we used to refer to as the “your baby is ugly” problem. If someone’s put a lot of time and work into a project — their “baby” — and then the consultant comes along and tells them how awful it is, they’re really put off. You have to be gentle and work with them, and focus on the improvements they can make rather than the mistakes they already did.

Be their trusted advisor. Through this process, your customer comes to trust you. They rely on you. They call you up or have you sit in meetings to get your opinion about this thing and that thing, and they bring you in because they’re starting Phase II and they want your input. This is the kind of relationship you have to strive for — being your customer’s trusted advisor. (I’ve never read The Trusted Advisor, but it’s come to me with high recommendations. I’m adding it to my reading list.) This kind of relationship smoothes over the sales process, because you don’t have to prove yourself to the customer. They know you and they like working with you, and they trust your abilities in guiding them to do the right things. Moreover, they trust you to treat them with regard, to handle their problems delicately, and to not embarrass them with their boss.

That’s it; that’s all there is. Consulting is all about relationships, and if you have good ones, you almost can’t fail. You can be a top expert in your field, but if you can’t do these three things, clients won’t like working with you because even though you’re smart, you don’t feel very helpful. I’ve seen consultants who were really good at listening to customers, understanding them, and being trusted advisors — and even though not all of them necessarily had top-notch expertise on tools or technologies or whatever the client actually needed help with — those people get repeat business, because clients actually feel that they are getting helped.

Of course, to be the best consultant, you really do have to have the knowledge that the client needs. That’s the second part of what I said.

JW’s Philosophy of Learning

Some people are constantly amazed at what I know about various subjects, especially technology and how various pieces of software work. I am going to let you in on a little secret: there is no secret to amassing this knowledge.

(With credit to Dorothea for the phrasing): The way to learn is to beat on things with rocks.

That’s it. Just keep trying until it does what you want it to do. When you get there (or even if you don’t), I guarantee you will have learned something.

OK, I can recognize that this is a statement of philosophy, but as an actual game plan, it may not be all that helpful. So here are five tips on how to be a more effective rock-beater:

  1. Define the problem well
  2. RTFM
  3. Change one thing at a time
  4. Someone else already knows
  5. Don’t believe it until you see it

Define the problem well. This may seem like a no-brainer, but if you don’t know what it is you’re trying to do, it’s hard to come up with something effective to do about it. Before you start hammering away willy-nilly, take a step back and say, “What do I need to accomplish here? What’s vital in what I’m trying to do, and what’s just nice-to-have? Is this really a problem, or is it caused by something upstream that’s really what I need to be working on?”

RTFM. Read the *#$%^@ manual. (This is especially dear to me because I used to be a technical writer.) Now, I know, not everything has a lovely manual like the kind I used to write. But by gosh and by golly, you won’t know until you take a look, will you? I can’t count the number of times someone has asked me a question that’s perfectly good, but also perfectly easy to answer if they’d spend 5 minutes taking a look at the documentation.

Change one thing at a time. If you’re trying to suss out how something works, you must think of yourself as a scientist performing a little experiment. You must change just one thing at a time to see what happens. If you change two or three or twenty-seven things at a time, how will you know which one is the one that actually worked?

Somebody else already knows. The chances are high that there is someone out there who can answer your questions. Maybe it’s your colleague in the cubicle next door, or maybe it’s somebody with a blog or a book or on a forum or mailing list. (Part of the trick is knowing where to look; do some research. The Internet is your friend, and so is your library.)

If you ask, these people are often eager to teach you what they know. However, a word of warning — there’s a reason this is the fourth tip and not the first one. “Define your problem” and “RTFM” first, or people are likely to be a little peeved at you for dumping your ill-defined problem on them, or asking things you could easily have found out yourself. Get as far as you can on your own, then ask for help.

Don’t believe it until you see it. This is the flipside of “RTFM” and “Somebody already knows”. Some document or person can describe how something is supposed to work, but you should still try it out. (This is especially true when the document happens to be a piece of marketing literature for software.) By trying it yourself, you make it yours. You really understand how and why (or even if) it works.

Good luck

So that’s all I know, and it works for me. I can’t promise any more than that, but I do hope it helped my former coworker, and I hope it helps somebody out there in the blogosphere, too.

10 April 2007

Too busy to blog?

My last post was an email I’d just written to a friend. As I was writing the email, I thought, “I should blog this”, largely because I’d read this just an hour before:

When people tell me they’re too busy to blog, I ask them to count up their output of keystrokes. How many of those keystrokes flow into email messages? Most. How many people receive those email messages? Few. How many people could usefully benefit from those messages, now or later? More than a few, maybe a lot more. (Jon Udell, “Too busy to blog? Count your keystrokes.”)

The whole post is definitely worth a read.

I’ve been pretty absent from blogging lately, but I think I’ll take this to heart, both for this blog and for work-related emails that might be better served by an internally-facing blog. My company is reasonably compact (certainly in comparison to Microsoft, anyway!) but we still have a lot of challenges spreading information around when people aren’t all in the office together and communicating face-to-face. We’ve reached a size now where, even when we are all in the office, some people are still out of the loop on X, Y, or Z because they weren’t present at the conversation in so-and-so’s office, or over the lunchroom table, or wherever.

And speaking of not blogging in a while, it reminds me that I also have a post on Yahoo Pipes and Dapp and many related issues that I started ages ago — like when Yahoo Pipes debuted — that I still haven’t finished… Too busy… ;)

13 December 2006

A brief technical note

This site used to be running on a machine at my house (which was quite constructive for learning how to administer Apache, but not so convenient during power outages). Because my ISP blocked outgoing port 80 for home accounts, I had to go through some contortions and there was an ugly “dystmesis.com:8081″ in my URLs. I’ve moved the site over to the hosting company that I use for other web stuff (the wonderful TextDrive), and it now features wonderfully clean “dystmesis.net” URLs, which are easier to remember and also play nicer with Technorati and other search engines and services. Through the magic of mod_rewrite, all the old URLs should still work, however.

17 May 2006

John Rollins passed away

John Rollins, of John Rollins Booksellers in Kalamazoo, passed away the other day. I really like Rollins bookstore when I lived in Kalamazoo. It was big and bright and had lots of books like a chain store, but was independent and full of friendly, helpful people. Unfortunately it gave way to Borders, Barnes & Noble, etc. in 2000.

28 June 2005

Languishing in cyberspace

This little blog has been languishing, undernourished with informationy goodness. Work has been busy, life has been busy, and so on. I think it will come back newer, better, more forcefully and dynamically, and with 200% more informationy goodness when I begin library school in the fall. I’m certain to have an occasional rumination between now and then.

Until then, stay tuned.

4 March 2005

Styling test

This is an h4

This is some text. Blah blah blah. This is code.

This is a blockquote. This is some text. Blah blah blah. This is some text. Blah blah blah. This is some text. Blah blah blah a–z. This is some text. Blah — blah blah. This is some text. Blah blah blah. This is some text. Blah blah blah. This is some text. Blah blah blah.

Read the rest of this entry »