CMP -- United Business Media

Intelligent Enterprise

Better Insight for Business Decisions

UBM
Intelligent Enterprise - Better Insight for Business Decisions
Part of the TechWeb Network
Intelligent Enterprise
search Intelligent Enterprise



May 15, 2000, Volume 3 - Number 8



Rain Dancing, or the HR/IT Relationship


The good, bad, and indifferent approaches to recruiting and retaining IT employees

Walt whitman rostow, the mit economist, once wrote that, “rain dancing is a time-honored and noble tradition, and so long as the focus remains on the rain, a worthwhile one. But when the focus shifts to the dance, I for one, begin to lose interest.”

For the current generation of technology managers in mainstream companies, traditional human resources (HR) managers, with their attention on process and behavior over results, have become problematic. As one CIO friend stated recently, “I used to look toward HR for help; now I just hope they don’t get in the way too much.” It doesn’t have to be this way, and, in fact, there are some terrific exceptions, but the typical experience today is negative. In this article, we’ll describe our observations on the HR department requirements for today’s information technology departments and the performance of some of those HR groups we’ve observed first and second hand — the good, the bad, and the indifferent.

First, we will acknowledge that doing HR management for IT groups in traditional companies is substantially more difficult than it was even a few years ago. The dot-com world has created a seller’s market for capable systems’ professionals and is an environment that defies traditional roles and relationships. With the vast majority of America’s recent, noninheriting billionaires arising from the technology field, mediocre technology consultants fetching $250 per hour and more from the large consulting houses, salaries for Computer Science graduates with three to five years of experience approaching $100,000 plus equity in startup companies, and dot-com sign-on bonuses including leases on BMWs, relying on traditional corporate HR policies to recruit, motivate, and maintain software development talent is a long shot. Let’s face it, 10 or 20-year pension vesting schedules don’t look appealing in a world where three-year stock vesting schedules are replacing four-year schedules as the norm. One recent study showed an average turnover for programmers in Silicon Valley at an all-time low of four months. Competing in this world is hard enough, but trying to use consistent HR policies across multiple disciplines in a large corporation is doomed to fail. And that approach is, in our collected experience, the hallmark of failing HR groups. HR must recognize the unique requirements for IT professionals in recruiting, as well as motivating and retaining talent. Let’s consider some examples.

Recruiting

The Good. The best recruiting philosophy we know, aptly named by an associate of ours, Danielle Ondrick of Watershed Technology, is the “No Bozos” approach. This approach works by starting with a small, competent core and recruiting only those resources that are as good as or better than the average team member, as determined by the team. Rejects are usually identified by the use of the word “bozo” in the interview summaries.

This approach works well for two reasons. First, it explicitly recognizes the unique character of competent IT professionals by letting other competent IT professionals who will depend on the new team member decide who gets to join their team. Second, it exposes the potential recruits to the people with whom they are most likely to bond from the outset of the experience.

The Bad. The worst approach we’ve seen to recruiting was in a company we both worked for. (It wasn’t our policy; cancelling it in our respective areas was our first action as CIOs.) This company had a formal, stated policy that it was better to hire individuals with some business background and teach them technology than to hire people with technical background and training. Honest. (Yes, the company is located in Hartford, Conn.) This policy, the “head-firmly-buried-in-the-sand” approach, is basically a testament to the denial theory.

This approach is a disaster for the same two reasons that the “No Bozos” approach is successful. First, the approach puts the onus of hiring on the HR department and, sometimes, the hiring manager, rather than the team. HR departments tend to be clueless. Hiring managers, especially in large companies, are important to the overall decision and process, of course, but aren’t usually in a great position to make decisions on their own (especially the more junior positions), as they tend to be less technical and more susceptible to flattery than their teams, and usually desperate to get enough qualified resources on their projects. Second, the qualified talent will run. The HR description of the business goals, the COBOL training programs, and the generations of employees are not going to be helpful. And showing the C++ programmer to his 6’36’ cube with the 15” monitor next to the A/P clerk won’t, either.

The Indifferent. To be honest, most (though not all) companies have progressed, even if unwillingly, beyond the ostrich theory. But we still see a lot of dancing such as HR preliminary screens, handwriting, and personality tests, and a host of other nonproductive or counterproductive practices, usually centered around HR overinvolvement in the hiring process. The best practices involve HR in facilitating and scheduling interviews, presenting formal offer paperwork, negotiating rates with external search firms, and that’s about it. And to do that effectively, they must be available 2437. The hiring managers and their teams should do everything else.

Motivating and Retaining

Most of the work of motivating and retaining talent falls to the team, the manager, and the project’s success. The HR influence is pretty much confined to three areas—compensation, the work environment, and matching the IT culture with that of the rest of the organization.

Compensation

These days, managing technical compensation is a losing battle, at least for the key technical positions. There is a dire shortage of competent, qualified people, and market economics generally rule. Of course, there are geographic areas without the BMW phenomenon, and many IT positions are not in undersupply. But for experienced C++, Java EJB, database, and telecommunications professionals, it’s a very hot market. Assuming you’ve been able to hire some of these key talented resources, the goal in compensation policy is to make it work for, not against you.

People generally won’t leave over money issues, so long as compensation rates stay pretty close to market. Unfortunately for HR policies, market rates for these key IT positions, and for any skill related to the dot-com phenomenon, have been escalating much more rapidly than for nonkey and nontechnical positions. A corporatewide COLA increase will likely leave your last year’s hires underpaid and vulnerable. In many markets, technical employees are receiving semi-annual, quarterly, or even monthly, salary adjustments.

And cash compensation is only part of the issue. In the good old days, like 1998, startup employees accepted lower cash compensation in return for equity. Now competition is so fierce for technical employees that startups offering significant equity are needing to offer market salaries and bonuses as well (BMWs are still rare). But with startups paying market salaries, traditional companies only offering salaries and small bonuses are at a marked disadvantage. Phantom equity, significant project, and “stay” bonuses are becoming a defensive necessity.

The Good. Straightforward market pay with at least quarterly reevaluations based on market rates for comparable skills is best. Formal studies aren’t a requirement—reasonable job descriptions and a good relationship with an external recruiter will do.

The Bad. Stay away from anything having to do with internal focus, equity across technical and nontechnical groups, or anything containing the word “annual.”

The Indifferent. These practices usually involve internal studies and positional, rather than skill-based, leveling.

The Work Environment

Every employer should recognize that employees are key assets who go home every night and need to be given a great physical, intellectual, and emotional space to which they want to return.

The Good. “It’s your office, try not to trash it.” That means providing private offices, multiple machines, 19” monitors, generous furniture, and great chairs. Everything should be 2437 — food, HVAC, supplies, and support. Everyone from the senior managers to the programmers should have pretty much the same-sized offices.

The Bad. There should be no dress codes, cubes, PIIs, regulated work hours, or building access restrictions. We actually worked in one “clicks and mortar” (mostly mortar) company where developers couldn’t get into the building after 7 p.m. “One size fits all” of you, and it’s a 6’36’ cube.

The Indifferent. Everything in between: Going halfway feels good, but doesn’t accomplish much. Business casual may be better than suits, but it’s still a dress code. Bigger cubes are better, too, but they’re not offices. “One size fits all” means one set of corporatewide policies where titles and levels, not job function and contribution, drive office sizes, equipment, and treatment. And think about this: almost every HR person we know gets a private office and doesn’t understand why a programmer would need one.

IT Culture and the Rest of the Organization

All of this can and frequently does heighten the tension between the new technical group and the other parts of the organization—including older technical groups. Working to alleviate those tensions in a positive and constructive way is the new HR function, but often puts the HR group in the uneasy position of managing the necessary change in the workplace that accompanies the successful implementation of new technology. The situation is all the more difficult because the new technology solutions are disruptive—they change the way that businesses are managed and operate. Frequently, the new applications being developed by these new, frequently younger IT professionals will force job changes, reorganizations, and even job eliminations.

The Good. The good HR groups manage the middle-ground of helping make the new IT groups work well apart from, and integrated with, the rest of the organization, recognizing that the special skills and market circumstances of the group are key ingredients of the company’s success — which is not that foreign, actually. Most organizations have entirely different compensation, motivation, and work environments for their sales forces and design and professional employees already. Treating the IT HR policies as extensions of these approaches, rather than similarly to clerical or manufacturing groups, is a good starting point.

The Bad. There are two really bad approaches here—trying to treat the IT group like clerks, which just fails, and calling attention to the differences and impact without proactive integration. We worked with one company that circulated a questionnaire about a software development project designed to achieve a 50-percent reduction in a department’s headcount to the members of that department, asking them about their involvement, approval, and comfort with the project. Duh.

The Indifferent. There really isn’t an indifferent score here; if an HR department is indifferent about integrating a key group of employees, it fails. Treating the new technical team as a necessary evil, a tolerated aberration, or even as a set of outsiders doesn’t work any better than pretending they’re just the same. Either approach makes these talented and critical employees feel like second-class citizens, which in today’s market is a sure way to lose the good ones quickly. The HR group is a critical factor in the success of this work, but to achieve it they must move away from their traditional, process-driven focus and do whatever it takes to get the job done and make the company successful.

As the new CEO of a startup we know says, “There’s no question who are the second-class citizens around here—it’s everyone not in the CTO’s organization.”

He wants it to rain.

 

 

John Trustman (jwt@trustman.com) is a principal of Delta Technologies Inc., a consulting firm specializing in corporate software development and focusing on very large systems and Internet delivery.

Susan Meshako (meshakos@ngmmail.msagroup.com) is the CIO of National Grange Mutual, an East Coast P&C Insurance Co.
 

 





IE Weekly Newsletter
Subscribe to the newsletter
    Email Address