10 Things You Need to Know About Building Your HR Technology and Managing Coders

by Frank Roche on April 3, 2013

in Management, Technology

I’ve had quite a bit of experience managing coders. Here are 10 things you need to know about building your HR technology and how to manage the people who create it.

  1. Anything you can describe can be built. If a coder tells you it can’t, get rid of him and hire someone who can.
  2. You’re the HR expert, make that clear. The overwhelming majority of coders don’t know anything about your HR processes, but they think they’re smarter than you and will try to push you around with “what will work.”
  3. Pay for expertise, not hours. You’re making a mistake if you pay coders by the hour. How’s that work out for you with the plumber? Only difference is that coders cost a lot more.
  4. Demand interim updates. If a coder isn’t willing to show you his work-in-progress, he’s hiding something and is taking dangerous shortcuts.
  5. Don’t get bullied. It’s more common than you think when coders go down a path and then when it’s not what you specified, tell you it’s too difficult and costly to change the code.
  6. Don’t get change-ordered to death. Be very, very cautious that you don’t end up paying twice what you planned because everything you ask about is a change order.
  7. Make sure your HR software features walk-up functionality. The best HR software doesn’t need a manual. If using your HR technology requires a training class you’ve done it all wrong.
  8. Unit test. If your coders aren’t unit testing and showing you the results, they’re exposing you to significant risk. It’s better for a sub-section of code to fail rather than the whole bloody packet.
  9. How it looks isn’t the same as how it’s experienced. Anyone can draw pretty pictures. What you want is coders who understand the full user experience and translate that into calls to action.
  10. Remember that HR software is a communication device. Everything about your HR software says something to your employees and managers. Why would you spend inordinate hours on PowerPoint layout but only give a cursory evaluation of the user experience for your software?

Here’s the thing: Think about coders like writers. Make them know the content. And don’t get pushed around and put off because “coders are quirky.” Nope, they’re a dime a dozen, just like writers. And just like writers, the good ones are invaluable. And the bad ones? Well, they should go ahead and do their “quirky” thing in their mom’s basement.

P.S. I used “him” to refer to coders, but they come in both chromosomal varieties. I tried the “him/her” construction but it didn’t work in this instance. But the same both goes for men and women coders.

{ 0 comments… add one now }

Leave a Comment

Previous post:

Next post: