Things your employees don't care about

Admission up front - this (brief) piece is a straight up rip-off homage to a post by Pete Warden titled 'Things users don't care about'. You should click over and check out Pete's list, from a technology service provider perspective, of things that a solution's users don't care about.  In case you don't click over to the post, here are just a few of these nuggets of insight on things users don't care about:

How long you spent on it.

How hard it was to implement.

How amazing the next version will be.

What you think they should be interested in.

Whose fault the problems are.

Fantastic stuff. And if you look across these examples, and several of the others Pete provides, it is pretty easy to discern the common themes. Namely, that users, customers, or employees from an HR service provider perspective, generally don't care about your problems. In IT it might be buggyDon't care. software, a difficult to manage supplier, or a lack of budget to procure new hardware or software. In sales it could be an inflexible pricing structure or an inability to promise a delivery.  And of course there are a million 'HR' problems that, mostly, your employees simply don't care about.

Government immigration rules making it hard to get visas for the three foreign engineers?

Don't care.

Recruiting system doesn't talk to the Payroll system making your team do double entry of data?

Don't care.

The list of 'mandatory' job requirements for the open position I'm trying to fill is so long, it's making it impossible for you to deliver a deep slate of candidates?

Don't care.

(I admit at least on that last one, your hiring manager should care, but that doesn't mean she does.)

Sure, in a perfect world and in an high-functioning, collaborative, 'Best Places to Work' kind of environment your problems as an internal service provider would actually resonate with your customers and employees. But most of us don't work in places like that.

Even in really great organizations, IT or Legal or Auditing or HR are still often simply looked at as the necessary evils of doing business. The 'users' or customers might, and often probably do care about the needed outcomes you deliver, but not one bit about the myriad of struggles, travails, and long hours you have to spend to deliver those outcomes.

It's the outcomes that matter, not what had to be overcome along the way. Within reason of course. Don't decide to go all Lance Armstrong on us.

But truly, it's a Honey Badger world when you are overhead. And Honey Badger, as we all know, simply don't care. (link to the video you have seen a thousand times, but it remains NSFW).

Who Bricked the Electric Car?

You may have caught the story last week about Tesla, the maker of extremely high-end electric vehicles, (EVs), and the accusation that if the $100K Tesla Roadster's battery pack was allowed to drain all the way to zero, (basically to go completely dead), that the car could not be simply re-charged in the normal fashion, and that in fact the entire battery pack would have to be removed and replaced, (at $40K).

This phenomenon, and already some are disputing how much of a real problem it presents, has been termed 'bricking', as in without the ability to operate the $100K Tesla has been effectively turned into a brick. A stylish one no doubt, but a brick nonetheless.  And having your $100K car essentially rendered useless without dropping another 40 large for the repair would have to classify as a bad day, and if indeed this is even a remote possibility, one would hope Tesla has taken adequate precautions and will look to improve the technology such that this kind of bricking either can't happen or really almost would never happen.

But for now, it appears like at least the possibility for bricking exists, according to a follow-up piece in Engadget, the Tesla company (sort-of) acknowledged that a full battery drain would indeed 'brick' the car and issued the following statement:

All automobiles require some level of owner care. For example, combustion vehicles require regular oil changes or the engine will be destroyed. Electric vehicles should be plugged in and charging when not in use for maximum performance. All batteries are subject to damage if the charge is kept at zero for long periods of time. However, Tesla avoids this problem in virtually all instances with numerous counter-measures. Tesla batteries can remain unplugged for weeks (or even months), without reaching zero state of charge. Owners of Roadster 2.0 and all subsequent Tesla products can request that their vehicle alert Tesla if SOC falls to a low level. All Tesla vehicles emit various visual and audible warnings if the battery pack falls below 5 percent SOC. Tesla provides extensive maintenance recommendations as part of the customer experience.

Essentially Tesla is saying, 'Look, we sold you an incredible piece of technology, the most fabulous EV on the market. All you really need to do on your side is to not leave the car idle for months on end and forget to charge it up. And we will even offer to call you up to remind you to run out to the garage and plug in the thing in you forget. For months. Seem reasonable?'

Probably pretty reasonable.  Tesla, like just about any other make of cars, gadgets, games, or even business systems at some stage arrives at the end point of their ability and responsibility to ensure that the consumer will have a great experience with their purchase, and won't actually do something really dumb with their new shiny object after they take it home.

Over on Talented Apps last week, Meg Bear hit upon this point when she re-stated Meg's Law for Talent Management software development -

It is the intention of our team to build excellent, usable software to optimize a well thought out talent strategy.  BUT if you suck, there is nothing we can do in software, to fix that for you. 

And I am pretty sure Meg's Law could apply to Tesla as well.  I am sure it is their intention to build the best EV in the world, but if you suck, and you forget that an EV actually needs to be plugged in once in a while, we can't fix that for you. Or rather we can, but it will cost you $40K.

Sadly, the organizations that Meg is referring to, the ones with the terrible talent strategy, can't get off that easy.

A User Interface Lesson from the Produce Department

I have always been a huge proponent and implementer of Employee and Manager Self-Service systems for the enterprise.  These systems come with lots of promises, easy access to information, reduced administrative burden on the HR department, and the opportunity to give 'ownership' of HR data to the employees and managers.

It's a win all around, right?

But the problem with many self-service solutions is that they inherit the user interface and design elements from the core enterprise systems that they sit on top of. Boring or ugly design, lots of menus to navigate though to get to what you are looking for, and terminology that is straight out of the programmer's manual.

HR Self-service systems need to be simple, easy to understand with no training (and by people who may not even read English all that well), and extremely efficient.

They need to work more like this:

Wegmans - Pittsford, NY

A simple self-service kiosk for weighing and printing price labels for produce. Bag up your items, place them on the scale, enter your code, and get the price label.

Look at the key elements, large and colorful action buttons, graphics that help users (especially ones with limited English skills) to make the correct choice, and a speedy, simple transaction.

The current most popular items are prominently featured with large, color pictures, giving the shopper one-touch access to complete their transaction. I bougt some Green Peppers, and with one touch, I had my label and was on my way.

Why is this important for HR Systems?

Think about how in your employee self-service system, the online Pay Slip is almost certainly the most frequently accessed function. Is the link displayed prominently, like the Green Pepper? Is a shortcut available to provide one-click access? Or do the employees have to endure something akin to this:

Employee Self-Service - Employee Payroll Data - Payslip Information - Current Payslip

In the grocery store kiosk I kind of expect to have to punch a few choices, even look up a code to buy something exotic like a kiwi. But for tomatoes, peppers, or corn, I expect a quick and painless process.

So how do your employee self-service systems stack up? Do you make it easy for employees and managers to do what they need to, especially for the most common transactions?

Or is every interaction with the system like trying to find the right code for kiwis?

Let the users help themselves

If you are in a mid to large size organization that has implemented either Enterprise Resource Planning (ERP) solutions, targeted Human Capital Management (HCM) applications, or really any enterprise-wide IT solution it will not have taken long to realize shortly after implementation you were faced with a rash of questions, issues, and problems that were discovered by the end users of your applications.Flickr - Jaydot

I know, you prepared detailed end-user instruction manuals, or even video tutorials.  You held numerous forums, demonstrations, and hands-on training sessions.  Maybe you even anticipated and posted a 'Frequently asked Questions' section on the company intranet.

You thought you had all the possible scenarios covered in your rigorous system and user acceptance testing.

But of course, once the system was subject to more widespread use, beyond the project team, conference room pilot, and the pilot department or division, you started running into issues, questions, bugs, and use cases that you had not anticipated, nor tested for prior to go-live.

And so, like in almost every major enterprise implementation before yours, you feverishly spent the first few days/weeks/months getting patches, updating user procedures, adding more and more items the the FAQ list, and generally fighting fires to keep the system running, and close the books/pay the employees/send the files to the bank, etc.  Honestly, even the very best implementations that I have worked on have to go through this insane stage, where the hours are long, the list of issues is enormous, and the light at the end of the tunnel seems very distant.

But eventually, the issues die down, the urgent problems are resolved, and soon, you as the implementor arrive at that place where you are sort of in limbo, kind of on standby. Not implementing anything new, because the organization is still trying to digest all the changes from the go-live, and still dealing with issues and questions from the user community as they arise.

After a while the questions and end user feedback starts to morph from 'This does not work' type questions, to 'Can the system do this' or 'I wish we had the ability to do that' type inquiries.  And typically as the system gets rolled out to more and more users and locations, and members of the project 'core team' either leave (in the case of consultants), or move on to other projects, the connection between HR or IT and the end user community tends to weaken, and at some point the questions, problems and issues start to increase.  Attrition, job rotation, and normal turnover all conspire against you, the 'super' users you could rely on may no longer be there, and soon you find your user guides, FAQs, and tutorials are not enough to keep up with the increased number of questions and issues.

And if you are like most organizations that I have been around, you respond by updating the manuals, FAQs, and tutorials. Maybe you hold more training sessions for the new users. You address the help desk calls one at a time, until you feel like you have stabilized the system once more. 

But what if instead of repeating the same pattern over and over again, of users finding issues, and asking questions of the project team or IT, you give them the platform and opportunity to help each other?

Instead of each individual question or problem  flowing from the user  to the central help desk, or support analyst, and back again to the user, usually via e-mail, what if you had the users enter all the questions in a shared question and answer forum, or even a wiki?

Larger organizations have hundreds, if not thousands of users, the chances are pretty good that most specific issues have been previously encountered by someone else in the user community.  Creating user forums with different sections for the various components of the application (Payroll, HRIS, Self-Service, etc.), that are accessible to all users, searchable, and monitored by the support team can be a great way to reduce time to resolution, lower support costs, and build a stronger, shareable body of organizational knowledge that potentially will also ease the transition of new users of the system. Additionally, you can include specific sections for enhancement requests, or for desired changes to the system or the underlying business processes.

This 'users supporting users' model has had quite a bit of success and publicity in the consumer spaces, most typically with tech goods and services like computers, home electronics, and popular consumer software.  Why not leverage the concepts with your internal enterprise users?

Have you deployed end user support forums for your community of users yet?  I would love to hear some case studies.

Put a real user on the team

Many vendors like to tout their system's 'Ease of Use', but ease of use is much more than a cool interface and some neat Web 2.0 embeds.  Too much flash may actually detract from 'real' users ability to perform their jobs.

Most software evaluation projects I have seen have forgotten one critical factor: the inclusion of a 'real' user on the evaluation team.  The Director of HR or the Assistant Director of Recruiting are not usually 'real' users.  If you are reveiwing a core HRMS, get one of your HR services staff on the team.  If you are testing out a new Applicant Tracking system, get a front-line recruiter AND one of your important hiring managers involved early.

When I see some of the cool new systems and user interfaces I always remind myself that the easiest to use system for a real user that I ever have seen was old school Oracle R10.4. It was black and white, character based, and all commands were keystrokes, not mouse clicks. Once a power user got the hang of it, an employee record or a AP Invoice could be entered without the user ever looking at the screen.  Try doing that with any of today's modern use interfaces.

I am not saying that those old character based systems were better than what we have today, but I am cognizant that most every new feature and capability has the potential to make the system more difficult and complex to use, and the best way to understand that before it is too late is to include 'real' users on the evaluation team.