When Efficiency Wastes

Efficiency is one of the mantras of the IT world.  Repeatable, efficient processes.  We all strive for them.  We all want to do things better.  Faster.  Cheaper.

Let’s ask ourselves for a moment, though, what that efficiency really gains the business.  The truth is, it can gain two things:  1) Save money in department’s budget, and 2) Reduce the time it takes to do things (which is the same as saving money).

The thing is, efficient for IT is not always effective for the company.  Let’s consider your IT helpdesk.  Which is more efficient- reducing your call times so that your people can handle more calls per day, or spending the time on each call to ensure that the user’s problem is solved and that the user is provided training that helps prevent the problem in the future?  Is it more efficient that your software development project is finished on time and on budget, or is it more efficient if the project overruns by 10%, but adapts along the way as more details are learned, in order to better meet the company’s needs?

I’m not saying to abandon efficiency for perfect customer service.  This is a mistake as well.  The company has only so much budget for IT, and you have to spend it wisely.  It’s the same conundrum as the old “the customer is always right” scenario- there is a point you reach that it can cost you too much to satisfy a given customer, and it’s no longer economically sensible to do so.

IT is like sales in a way- it’s all about delivering what the customer needs, for a price that they can afford.  Strive for finding that balance.  Don’t fall blind to why your IT function exists and what its real goals are.

Attitude is Everything: Six Points to Investigate When Hiring

There was a time when tech skills were scarce.  Hiring new IT staff was all about finding someone qualified from a technical perspective.  Skills were everything; certifications, even better.  That day has past us by.

The reality is that if you look at your IT department today carefully, you’ll find that most folks there are not working in a job that they originally trained for.  They might have started out writing COBOL.  They may have started out with a degree in marketing.  They might have gotten into programming because it pays the bills while they try to get their band signed (in fact, if you work in Nashville, that’s probably 25%-50% of your entire company’s staff).

This means that your IT staff has adapted over time.  They’ve acquired the skills to keep succeeding.  Given what the IT industry is like, in fact, you can be certain that absolutely any candidate that has worked in the industry for five years or more has adapted and picked up the skills they need for the job as they went, as technology skills typically have a shelf life of just that- about five years.  Adapting is not a bonus in IT- it’s a survival skill.

So what should you be looking at to hire people?  Attitude.  Communications skills.  The ability to fit in your company’s culture.  The key here is to find a personality that works, not just a set of skills.  You wouldn’t pick a dog for your kids based solely on its color, height and weight; you shouldn’t pick staff based on a set of statistics either.

Here’s a short list of useful guidelines and a few questions you can use for each:

  • Look for people fit to the pace.  If it’s a challenging position that will have to hit the ground running, look for someone seeking challenge.  If there’s a lot of repitition involved, look for someone comfortable with routine.
  • Look for people interested in today’s challenge.  If they ask about advancement opportunities, that’s great; people should be ambitious.  Be sure, though, that they’re interested in the problems you have now.  You don’t want someone looking ahead so much that they’re not doing the job you hired them to do.
  • Look for honesty.  Ask a tough question or two, like why they’re leaving their old job.  Anything that smacks of honesty is good here, even if it’s “I hate my old boss”.
  • Look for a willingness to take responsibility.  Ask how they would handle reporting a massive budget overrun to an executive.  How they would handle a systems outage at the end of the day.  How they would handle a major and valid customer complaint with your software services.  What they would do if they found out that one of their staff had screwed up a major account.  Watch for answers that smack of ”I would deliver a straight answer, take the lead to find a solution the problem, and report on the results.”
  • Find out how the person handles confrontation.  How they would handle the firing of a staff member.  How they would handle it if an executive ever blew their top at them.  How they would handle an irate customer.
  • Find out how they prefer to communicate.  Ask how they would handle delivering bad news to someone else on his team.  In another office.  A customer.  How would they handle requesting help from another department.

There are other factors to consider as well, depending on your company, its culture, and the particular job, but this is a good starting point.  How a person handles conflict, how they communicate, how they take responsibility, their level of honesty- all of these things are things that can make or break a new employee, regardless of their technical skills.  Make certain that they have the minimum skills to meet the position, obviously, but  you can always teach technical skills- teaching attitude is much harder, and much more difficult within the context of your organization.

DIY projects

There’s been a lot of buzz in the last year about Do-it-yourself IT folks.  Business people bringing their own bits and pieces of IT functions into the workplace, circumventing the traditional IT department.  CIO magazine even did a big article on it (a copy of the article made the rounds around our business departments, in fact).  While organizations are starting to address this issue, I see a bigger one brewing:  DIY projects.

There are business units at companies all over the world right now circumventing their Project Management Offices and/or Project Managers.  Sometimes they just form projects within their departments and try to do it themselves; other times it’s more radical.  I have actually been involved as a vendor to a Fortune 100 where a business unit cut IT out of a million-dollar software project by outsourcing the bulk of the work to us and hiring us to manage it.  This wasn’t done as outsourcing, per se- just a complete and outright circumvention of IT.  The reasons given behind the scenes were that IT’s standards were too strict and that IT took too long.

Given the number of projects out there that overrun budgets and/or timelines, the idea of business units cutting out the Project Management Office, IT, or any other subject matter experts within your company are frightening.  Even if the project succeeds, consider that the vast majority of projects require maintenance and management once they ‘go live’.  This will either be done by the very staff that was cut out of the original project (if the business unit turns to IT), by business team folks whose jobs are actually to be doing something else (if the business unit tries to run it themselves), or by the vendor (thus setting you up with a permanent dependency on the vendor- your business unit did know to check out the vendor’s long-term viability, right?).

This kind of thing is just trouble in so many ways its not funny for any business out there.  Usually this sort of thing going on in your organization is a result of some problems you haven’t been paying attention to.   The question is, how do you quell these things?  First, I recommend addressing your problems leading to this practice, for one, and providing strong vision and leadership can help as well.  Vision and leadership will inspire trust, and a lack of trust in the status quo that others can meet the business unit’s needs is always what leads to these sort of rogue ops.  Second, find a way to embrace the project.  Instead of shutting them down, say “How can I help?”  Get involved. Don’t get in their way; that’s why they are circumventing you in the first place.  When you need to do course correction to get things more supportable or compliant with your corporate regulations (or any legal regulations you must comply with), communicate.  Help them understand why the extra bits are necessary.  Be a partner, not a roadblock.  If you can help people understand that you are there to help, and you show that you can be a help, they’re more likely to come through the right channels next time.

Still, I’d love to hear what other folks thoughts on this.  Any comments?  Can anyone comment on how their organizations are handling this problem?