For TechRepublic members in the Northern Hemisphere, Spring has just begun. For many of us, this is a time to clean out a garage, basement, or attic. Even more important, it’s a time for taking stock of your assets, discarding what’s no longer needed, and hopefully uncovering some forgotten treasures.
In other words, it’s time for inventory.
As IT managers, you’re familiar with several kinds of inventories. To track physical assets, you and your people perform periodic hardware inventories and audits. To ensure that your organization isn’t using unauthorized or unlicensed products, you perform software inventories. Trying to maximize network bandwidth and minimize legal vulnerabilities, you might do routine checks on your servers, looking for illegal music or movies.
However, in this column, I want to talk about a different kind of inventory. I call it an “experience inventory.” By following the examples I lay out here, I believe you might uncover some hidden assets that can help with your current projects.
Panic at the mall
While managers occasionally like to blow off steam by comparing their staff to errant children, there is one way in which most technical managers remind me of children—elementary school children.
You see, my wife used to be an elementary school teacher—mostly kindergarten and first grade. It seemed as if every time we went to a mall, we’d run into one of her former students along with a parent. My wife, a companionable soul, would chat politely with the mother or father, while throwing in a greeting to her student.
The child, on the other hand, would almost invariably freak out. At first, he or she would stare confusedly at my wife, as if trying to place her. Next, a light would go off in the child’s mind as recognition set in. Finally, the child would start to panic, looking back and forth from my wife to the stores in the mall.
After this happened two or three times, I asked my wife about it. She laughed, saying “Don’t you see? I’m not supposed to be here. I’m the teacher—I live in the school.”
Too many IT managers treat their employees as if they lived at the office. By that, I’m not talking about workloads or home/life balance (important issues, of course, but for another column). Rather, I’m saying that we tend to act as if members of our staff never existed before they came to work for us. If you’re looking for an analogy, it’s as if we believed our recruiters worked exclusively with the Witness Protection Program, and the previous experiences of our people were a forbidden topic of discussion.
You benefit from their experience
This is where an experience inventory comes in. Rather than a formal interview or set of procedures, an experience inventory is a series of things you can do to find out about past projects that your staff has worked on, either before they joined the organization, or before you became their boss.
Just to be clear, I’m not talking about a skills inventory. I’ve talked before about how valuable skills inventories can be, but this is a different animal altogether. Rather than try to compile a list of team members having experience with specific programming languages or operating systems (as in a skills inventory), what you’re trying to do here is identify team members who have worked on past projects that might bear on your current or future workload.
Look at it this way. How many projects does your group work on in a year—10 or 15 significant ones? Now suppose you manage a team of 10, each of whom had, on average, three years of work experience, before you became their boss. Added together, your team could have worked on as many 450 different projects before working for you. Even if you discount that number by half (to allow for overlap), that’s still 225 projects. Isn’t it extremely likely that several of those 225 projects are quite relevant to some of the stuff your group is working on today?
Remember, the idea here isn’t to find exact matches, but similarities. After all, our industry advances so quickly that much of our specific knowledge about technology rapidly becomes irrelevant. However, our strategic insights into technology are timeless.
An example: The developers’ dilemma
Here’s an example. When developers first started writing applications for personal computers, memory management was a huge issue. For years, programmers kept slamming into the 640K RAM limit for DOS-based machines. Even after manufacturers started building PC with more than 640K of RAM, developers had to be cognizant of how operating systems handled this extra RAM. The bottom line was that programmers evolved sophisticated memory management strategies for their applications.
Over time, the price of RAM went down, and the ability of PC makers and operating systems to use this RAM increased. The result was that memory management became less important. (Another result was that we got stuck with a lot of bloatware, but that’s another story.)
However, with the proliferation of handheld devices and embedded systems in recent years, some developers have had to become re-acquainted with memory management concepts. It’s a hot topic again at many developer conferences.
Does this mean that the programming techniques used by Turbo Pascal developers for applications running on PCs with Windows 3.1 are transferable to applications running on the latest Palm OS or Windows CE handheld? Of course not. However, many of the general principals and strategies used by those developers in the late 1980s and early 1990s are still sound today.
Conducting your own inventory
Now that you understand the concept, here are some tips on how to do your own experience inventory.
- Ask in a team meeting: This strategy sounds obvious, but the key is in how you ask the question. Always remember that you’re not as interested in finding a skills match as you are in finding someone who’s had to solve a similar problem. For example, rather than asking “Has anyone worked with this software before?” you might frame the question differently: “Has anyone done much printer troubleshooting in a mixed OS environment? How did you approach the problem? What worked for you? What didn’t?” By asking the question in this way, you encourage your people to think back through previous projects to work that might bear on the current problem.
- Do a survey: If you manage a large team, you might consider sending out an e-mail survey asking team members to answer some questions about past projects. Such a survey could not only help you find an approach to a specific current problem, but could also help you make staffing decisions for future projects.
- Go back to the resumes: If you still have the resumes for your current team members, they can provide some insight into the kinds of projects each worked on in the past.
Have you done your experience inventory?