When people ask for help, don’t do it for them – empower them to do it themselves. They’ll feel better about themselves, and you’ll have less to do later.

I work in a position where I’m 25% help desk and 75% developer (well, it’s more like ~40% help desk, but that’s a rant for another time. ;) ). I spend the first few hours of every day working with users on the usual help desk-y items, specifically related to our website and the tools to maintain it. It’s not my favorite part of my job, but hey, it’s a living, right?

When I first came to this position, the help desk part of the job was swamped. They couldn’t keep up with then never-ending flow of items, usually small stuff (e.g., “How do I login to the CMS?”, “Can you do a minor update for me?”, etc). Usually, these were items that the user was capable of doing, but either wasn’t sure exactly how or simply didn’t want to do them. More than half of the support time was spent with these items. The developers on the receiving end of the support line were being used a tools to do little bits of “this web stuff” instead of as a resource. What a waste!

I decided that this had to stop – I was hired as a developer to create applications and tools, not to fix broken links or to update page content. So I started taking the this approach:

If it’s something that a user could handle, show them how to do it themselves. Unless it’s an emergency, do not do it for them.

There was some resistance at first – people were used to just having our department handle these little items. But people started to see where they could search for information (I had to update our public knowledge base to get info out there), as well as other online resources (I commonly point people at Google with suggested search strings). People started to see that they didn’t need us for these small items.

As time went on, people started really appreciating it. They could just get things done themselves without having to turn to Computing Services for support. Not only did this let them get things done faster, they could take all the credit, guilt-free. :)

Now we have most of our users creating and editing much more interesting and dynamic content, with better practices for maintenance and management of content. It’s no utopia, of course, and maintaining the high level of user-education requires diligence. But now, I feel that our users look at our department less as a necessary roadblock, and instead more as a resource to keep them moving.

It’s subtle, I know. Now, though, I’ve got fewer emails in my help desk inbox, and I can spend more time doing my actual favorite part of my job: coding.

-sean

For any project, find a user-champion that will carry forward, advocate for, and ultimately, love your project.

The other day a colleague and I were discussing a dauntingly large project. Effectively, we are planning on completely re-developing our web strategy and moving to a new technology. A huge task, no doubt.I rather adamantly suggested that we break the project into smaller pieces, and focus firstly on one chunk that I felt would have the most “bang for the buck” (the main CMS, if you must know). I advocated a rather agile approach, getting some users on board with us as a pilot group, and then expanding from there.

My colleague didn’t think it was a good approach, so dismissively challenged that I try to make it work with some of our most difficult users.

These are, apparently, a group of neophobic users with a history of poor relationships to our department and a host of other hurdles tied to them. If I could get them onto a new system, he stated derisively, I could get any of our other users on it.At first, I was defiant. I wanted to prove him wrong (I’ve always been one to challenge people with they dismiss my ability to surmount a goal). I quickly realized, though, that working with a group of users that do not want to be worked with is a fool’s errand. I quelled my defiance.

Success of a software development project, in my mind, is all about taking the (long-term) path of least resistance. It’s about finding those paths that will make your (or the future developer’s) life easier. That way, it becomes less of a painful slog, and more about facilely getting it done. More about feeling good about what you’re doing. More about enjoying coding.

Adding complexity and more headaches to chase down uncooperative users does not sound fun, nor do I think they will assist with getting a project going. They won’t push for it, they won’t tell others about it (positively), and they ultimately, won’t care about it. These people will more likely weigh me down, and make me despise the project before it ends (if it ever does!). Not a good time.

On some (very) successful software projects I’ve been involved in, both for this position and prior, I’ve had users that immediately took to what I was doing. The cheered on my successes (since it was a new feature, bug fix, or just better training), and they espoused praises of the application. The praise got around, I got more recognition as a successful developer, and other people started asking about using the software, too. It was growing without a word from me!

These, my “champion users”, were key in getting and refining the project requirements. They pushed to get support, they told my managers when things were going well, and they offered suggestions when they broke. I’ve started to realize that, even if you dearly care about a project’s success, if you don’t have a project benefactor (read “user”) on your side to champion it to others, you’re probably screwed.

So I’ve started making a point to always get one with me. It helps me plan, it helps me work, and, in the end, it helps me feel successful. Once we get ourselves a nice huge Katamari of users to provide momentum, we can roll up the difficult cases. :)

Back on the project itself – To my colleague, I advocated to instead find users that care about what we would be doing, have a stated need that we could fill, and have previously been upbeat towards new things coming from us. If we had these, champions, I argued, they would help us move forward on the project.

Eventually, he quelled his challenge. I was told that I could pursue my project of choice, and that I could pick the pilot user group I wanted. I was pleased. :)

Does this mean I will be successful? Nothing is certain, but I like to think that it will be a key component in ‘making it work’. At the very least, working with people that genuinely appreciate what I’m doing will make it that much more fun.

-sean