Crisis? What Crisis? A Contrarian Perspective

This article was originally published in Cutter IT Journal, June 2001.

Software organizations take forever to hire technical people, we overwork them, our projects are late, we can’t get everything done. We must have a people shortage, yes? No.

True, we have plenty of problems, but we have enough people to do the jobs we need done. What we don’t have is skill at hiring and managing the people we have.

If we had a staff shortage, I would expect to see us managing technical staff as a scarce resource. We would:

Manage the organization’s project portfolio strategically. Without enough people, we’d be reluctant to take on more work, and we’d manage the project portfolio carefully.
Focus on the minimum a project needed to accomplish, instead of the maximum. We’d focus on getting some things done.
Optimize project and other work to take full advantage of IT staff. We'd eliminate the wait states, make-work, or work because "we’ve always done it that way".
Compete for people by offering training, conferences, and other perks that technical staff enjoy.
Quickly hire candidates we think could be successful in our organization. We wouldn’t consider having candidates wait for us to look through all possible resumes.
Recruit continuously, whether we had open requisitions or not.
Train for domain or tool expertise, rather than hiring on the basis of tool or expertise criteria.
Effectively use non-traditional workers, such as part-timers, non-degreed staff, telecommuters.

I don’t see us managing our staff this way. In fact, I see just the opposite. We don’t seem to value this "scarce" resources, our technical staff. If we treated our people (and ourselves) as if we were all scarce resources, we might not think we have a staffing shortage. To manage our human capital well, we need to:

Plan our work, so that we have the right people available when we need them.
Create a working environment, where people can actually work at work.
Select candidates who can get the job done.
Hire candidates quickly.
Rethink our attitudes about how people can and do work together.

The problem is not a staffing shortage. The problem is the mismatch between the work we’ve taken on and the staff we have available. To reduce the mismatch, we can manage the work, our existing staff, and our hiring process more effectively.

Plan the Work

Planning software projects involves both selecting which projects to do when, and choosing which people are needed when. With a scarce resource, you’ll need to plan the work carefully to avoid bottlenecks. How many times have you witnessed a conversation like this between a project manager (PM) and a functional manager (Manager):

PM: I need Jenny, the Oracle DBA; Max and Don, the two testers; and Elisa, the GUI person on my project by the end of this month. If I don’t have them, I won’t make the release date.

Manager: Well, they’re still on their other project. What if we hire more people?

PM: Well, we estimated the project with these people. I’d really like to have them.

Being dependent on just a few people for successful projects sets up a feedback loop. When one project is late, the following projects are bound to be late, as long as you’re always dependent on the same people. Even if you hire new people, the new people slow the project [see footnote 1], because they are new to your organization and the product. When people are not ready on time for your project, the project will be late.

If you’re going to have people working with no down time between projects, you either need to start the next project on time, or not care about the consequences of successive project slips[see foonote 2]. When all of your staff is working at full tilt, you have no control points to change the feedback loop. You have no way to easily replan your project portfolio.

When you manage technical staff as scarce resources, you avoid staffing bottlenecks and reducing staff efficiency with context switching.

Manage the Bottlenecks

When people are fully committed to their current projects, they can’t take time to plan what they’re going to do next. They can’t take time for training, so they aren’t ready for the next kind of technology. They can’t start low-level thinking about the next project or product, until they are freed up from their current project. If you keep everyone working at maximum capacity, you may find it difficult to sufficiently staff the project enough to actually release it. At maximum capacity, you need to hire more people so your projects can survive when people on your staff take vacations, or get sick

Sometimes, the bottlenecks show up in only one portion of your project staff, usually the writers or testers. Then, it’s time to examine what the writers and testers are doing on the projects, to make sure they’re working to move the project forward. I once worked with a test group that faithfully recreated all the builds, but didn’t do any testing. The test manager demanded more people, but the project manager worked with the test manager to see that the testers started to test the product, not just the build procedure. The project manager eventually brought on a release engineer, so that the testers didn’t need to test the build procedures at all.

Avoid Context Switching

One way many organizations try to manage the bottleneck or project competition problem is to allocate people to several projects at once. Some managers think this is a way of seeing that all projects make progress. Unfortunately, the more projects a person works on, the less effective he or she is [1,2]. If you plan projects so that people multitask, you’ll need more people than if you plan for people to work on just one project at a time.

Context switching is a problem for managers too. Don’t think you’re not a scarce resource–you are. If you’re trying to manage too many people or too many projects, how good a job can you do? Can any of your projects make progress if you can’t take time to think about them? If you’re currently playing the shell game of moving people around from project to project, plan a way to stop. If you’re playing a shell game with your time, decide what’s not on your list of things to do anymore. We all need uninterrupted time to do our work, managers included. The more you have to think about, the more time you need.

Manage the Project Portfolio

How much work are you responsible for? Are you a project manager, trying to get the most important work done? Are you a manager responsible for a variety of projects?

The more work you’re responsible for, the more important it is to manage your project portfolio–the work you oversee. If you have the opportunity to plan and prioritize the projects in your portfolio, then you can staff projects appropriately, plan when you need to hire more people, and train new and existing staff as needed. If you work in a relatively chaotic environment, such as a startup, where you expect to continually replan your project portfolio, then plan for less than 100% staff utilization.

Even if you don’t have the ability to plan which projects are done when, you can still manage which people are assigned when to your projects. You can avoid 100% utilization or sharing people between projects. Full commitment, or sharing people between projects, is not necessarily a sign of a staffing crisis. Full utilization is not about the ability to hire more people, but about the ability to manage all the work you have to do, whether it’s multiple projects or one project. If you have an insufficient number of people, and you can’t hire more people, then you’d treat the technical staff as a scarce resource, and protect the sanity and health of the people currently on your projects.

When you’re managing your project portfolio, you prevent projects from going into death march mode. We allow mandatory overtime and death marches when there are enough people to hire, but we have chosen not to. We choose to leave the project in its full definition, and to leave the staffing as is. If there weren’t enough people, what would you do when everyone burns out, and can’t continue to work?

Minimize Project Deliverables

If you're planning the project work to avoid bottlenecks and managing your project portfolio, you're already treating your technical staff as a scarce resource. Another way to treat technical staff as if they are a scarce resource is to reduce the project deliverables.

Sometimes, the best way to plan your project portfolio is to ask what the minimum deliverables from the project could be, instead of defining and architecting a complete product. We all get caught up in wanting to do a great job with a product, but sometimes the best job you can do is to not do the project at all, or to deliver something very small, or to develop just a portion of a product.

Too many projects exist because they are someone’s pet project. When you manage your technical staff as scarce resources, you take a long hard look at each project in your portfolio. Should you do this project? Could you do the project later? Could you make a smaller set of deliverables? When you treat your staff as scarce resources, it makes more sense to strategically plan what they will work on, and what they won’t.

If you don’t manage portfolios and people allocation, then you know you have access to enough people for your organization. You don’t have a hiring crisis; you have ineffective portfolio management.

Create a Working Environment

Maybe you do manage portfolios and people allocation, and you still feel as if you don’t have all the people you need. What do your scarce resources spend their time doing? What’s your "overhead" rate? How much time do people spend doing things other than project work?

One of my clients boasted about how they had done away with the HR administration positions; now all of the employees could fill out their own forms. When I spoke with some of the engineers, they had nothing good to say about the on-line forms. "It took me three hours yesterday to fill out all the forms now that I’m married. But if I hadn’t filled out the forms, I wouldn’t have gotten the insurance I wanted." Do you really want your highly paid professional staff spending three hours filling out forms? How many other activities like this exist, necessary work that prevents people from getting project work done?

Assess the amount of make-work in your organization. Some examples are: meetings about non-work activities; some "all-hands" meetings so managers can disseminate information; metrics gathered that are never used; preparation for project reviews; and so on. Is all this work necessary? Does it provide enough value to any of your projects that it’s worth spending time on by the technical staff?

Optimize IT Staff Work

Some of this work is necessary. However, most of the work is not. Most of this work helps managers and administrative staff manage their time better, not the technical staff. Every time you have an all-hands meeting to disseminate information broadly that’s not project work, you are optimizing someone else’s time at the expense of your software staff. This may be appropriate in some situations, but not when you’re treating the technical staff as a scarce resource.

Even if you don’t waste time on non-work projects or on unused metrics or presentations, I suspect you still have meetings that waste tremendous time in your organization. How many meetings do you and your technical staff have? Are the meetings all worthwhile? How many of these meeting attributes do you have in your organization?

Our meetings always start on time.
Our meetings end on time or early.
I feel free to leave a meeting if I’m not needed.
We have action items out of every meeting.
We have agendas and minutes for every meeting.

If your meetings exhibit many or all of these characteristics, they're likely serving your purposes. If not, you probably shouldn't be having them. One of my colleagues, Steve, said: "If I only had to be at meetings when everyone else was there, I’d get back at least two hours out of every day."

Steve is an architect, and is called into high level meetings often. Since the managers are always late for their meetings, he ends up with bits and pieces of time waiting for them instead of concentrating on what he has to do.

Steve’s company chose him for his position because he was able to work quickly and create high level designs that technical staff could understand. Steve’s days are so fragmented now with meetings, that he’s started working from home so he can avoid interruptions.

Steve’s boss wants to hire another architect to help Steve get all the work done. Steve groaned and said, "Another interruption! All I need is the time to do my job." Steve’s boss is convinced Steve is in denial about the problem, and is looking for an architect anyway. Unfortunately, Steve’s boss doesn’t understand enough about the product and the technology to do a technical phone screen, so Steve is having to do those, too.

Steve only spends half his day doing project work. The rest of the day is in meetings, marketing products, and compensating for his non-technical manager. He accomplishes more at home, but then he pays for it the next time he’s in the office, making up the time on his non-project work.

Steve’s boss may actually need another architect, but what he needs more is to increase his knowledge of the product, and start protecting Steve from the outside-the-boundaries work that Steve is doing. Steve’s organization may have a technical staffing problem, but it has certainly hired inappropriate people into management positions.

Select People Who Can Do the Job

Maybe in your organization, you manage the project portfolio, and there is little overhead work. Maybe you’re just having trouble hiring the people you want. In that case, maybe you’ve overconstrained your job descriptions. If we assume technical staff are scarce resources, we have to choose which parts of the job description are essential attributes, and which parts are desirable, just like project requirements.

Job descriptions seem to come in two categories: laundry lists of everything you might ever want a candidate to do, or two sentences that could apply equally well to developing software for the space shuttle or supply chain management. I can sympathize with hiring managers who write those job descriptions. Frequently, the descriptions go to the Human Resource departments, where a non-technical person or a software application reviews resumes before sending on possible candidate to the hiring manager.

The HR staffer doesn’t know what technical qualifications to look for on a resume, so they look for keywords. Software doesn’t know how to look for anything but keywords on a resume. Candidates aren’t stupid; they’ll put anything that might be a keyword on a resume. The result: severe keyworditis, and your inability to screen appropriate resumes from your ever-growing pile of them.

Companies that have trouble hiring tend to write narrow job descriptions without considering transferable skills and investing in training for current and new staff. Too many software companies think they need people with college degrees in computer science or engineering. That’s too bad, because some of the most talented software people I know don’t have college degrees. A degree is a sign of perseverance in an academic environment, not the ability to perform on the job, certainly not a software job. If we have a hiring shortage, why are we not hiring more people without degrees, and giving them training, if necessary?

How old are the people you’re hiring? How much are you willing to pay them? Those of us who’ve passed the magic age of 40 tend to have a more difficult time finding jobs than younger technical staff. When I ask hiring managers about this, they say things like, "I really need someone with 3 years of Java experience." When I ask why they won’t train experienced engineers, the managers say, "They’ll leave in a couple of years anyway. Why should I train them?"

Experienced technical staff cost more money than younger, less generally experienced staff. More experience can bring more maturity, more loyalty, and more experience making software that works. If we don’t have enough people, why are we not making offers to experienced engineers, even if they are experienced in a different area?

We don’t need to hire just people who are only warm bodies, just anybody. We can find people who are close enough to the job descriptions we have, and hire them. After all, we rarely fire people because of their technical incompetence; we more often fire people because of their inability to perform in our organization, a cultural fit problem.

Hire People Quickly

Even if you receive appropriate resumes, how long does it take you to respond to a candidate? Most of the hiring managers I know take days to respond to resumes, not hours. In a real shortage situation, hiring managers would respond in minutes, because if they had a good resume, they wouldn’t want that candidate to slip through their fingers. Even if you are one of the few hiring managers who responds to a candidate quickly, how long does your entire hiring process take? Does it take you more than two weeks to invite a candidate to an in-person interview? How many interviews does each candidate have? How long does it take you to make an offer to a candidate?

Unfortunately, many organizations have hiring processes optimized for their internal staff, not for candidates. It’s not uncommon for candidates to send in their resumes, and then wait two or three weeks to be called for a phone screen or an interview. It’s also not uncommon for candidates to go through two or more rounds of interviewing. And it’s rare to find companies who can make same-day offers (i.e., offers the same day as the interview).

When we treat technical staff as a scarce resource, we’re much more active in our recruiting efforts. We recruit continuously, using multiple recruiting techniques, rather than waiting until the paperwork is signed off for an official open position. We search out potential candidates, and quickly assess their ability to work in our organization. We make same-day offers. We don't wait for the perfect person to come along, interviewing scores of candidates, leaving jobs unfilled for months at a time.

Utilizing non-traditional employees

We are lucky in our field. Not all work has to be done between 9am and 5pm in a centralized office. People can work remotely part or all of the time, work fewer than 40 hours per week and still be quite successful doing technical work. In my experience though, it’s harder for hiring managers to hire people who don’t fit the "40 hours in the office" workweek model. Most of our organizations are not set up for telecommuting or making part-time workers successful.

If you have a shortage of technical staff in your geographical location, there is someone looking for a job who would fit. As hiring managers, we need to be willing to explore remote workers.

Some people prefer to work part-time. Part-time workers may not fit with how you’ve planned your projects, but I know of many part-timers who accomplish almost as much as a full-time employee.

Summary

If we had a true shortage of people in our field, we would treat our technical staff the same way we would treat any other scarce resource. As managers, we would change the way we hire and manage them, and manage our projects. We haven’t– at least, not yet. There may be local shortages of particular technical skills. We certainly don’t have enough skilled technical managers. But the evidence doesn’t point to a shortage of people.

If you’re having trouble staffing your projects, consider your options:

Manage your project portfolio. Resist the temptation to double-book people on projects, in the hopes the projects will be done faster. Manage when people start and end their work on projects, so you don’t set up a persistent slip feedback loop.
Create an environment in which people can get their work done –an environment without make-work and other time wasters.
Avoid over-constraining your job descriptions, and be clear on why you have specific requirements in a job description. Respond to candidates quickly and hire people who fit culturally, even if you have to train them for the technical work.
Reconsider how to manage part-timers and remote staff, so that you can get your projects done on time.

We don’t have a shortage of technical staff. We may have a shortage of effective technical managers, but there is enough technical staff to get the work done, as long as we treat our technical staff as if they were scarce resources.

Acknowledgements

I thank the following people for reviewing early drafts of this article: Martine Devos, Mark Druy, Dale Emery, Elisabeth Hendrickson, Dwayne Phillips, Stever Robbins.

References

1. DeMarco, Tom, and Tim Lister. Peopleware: Productive Projects and Teams, 2^nd edition, Dorset House Publishing, New York, 1999.

2. Weinberg, Gerald M. Quality Software Management, Volume 1, Dorset House Publishing, New York, 1992.

Footnotes

1. It requires time from your current staff to educate new people, so not only do you not get an immediate productivity increase, your productivity actually goes down as you hire more people. After you've sufficiently assimilated the new people (3-6 months), they no longer drag the original staff's productivity, but their productivity is not yet that of your original staff. Only after the new people have been on staff for 9-12 months does their productivity match that of the original staff.

2. Not all projects have to be done quickly. In my experience, any product that’s past its early adopter stage doesn’t need frequent releases. In fact, your customers would prefer that you ship fewer revisions of the product, because they are not ready to install the new revision.

Johanna Rothman observes and consults on managing high technology product development, looking for the leverage points that will make her clients more successful. You can reach her at jr@jrothman.com or by visiting www.jrothman.com.