This article on career rotation reminds me of a point.
In Big, the hit movie from the late 1980s, star Tom Hanks rises from a clerk in data processing—that’s what technology was called back then—to become vice president of product development for a toy company. That quantum leap in status and pay took him all of a week to pull off. Some would-be fast-trackers might call that the ideal job rotation.
Some companies have always encouraged ambitious employees to rotate out of their discipline—technology, finance, marketing, operations, etc.—and into a different department, often one in which they’d have to push themselves to succeed.
The rationale is simple: By seeing how other areas of the company operate—getting the proverbial big picture—an employee becomes more valuable, and the organization as a whole gains. Six to 18 months in a new assignment arms an employee with additional knowledge and layers of skills.
That career advice is more geared to people in big corporations who aren’t in tech jobs but managerial or other non-tech components (business analysts, project managers). Nobody is going to take a technical writer and try him out in QA, for example, or give him 18 months to taste development. However, rotation is important to keep your peeps, especially your QA bunnies, from burning out.
Let me explain. No, there is too much.
One of the shortest postings in my career came when I was put on a QA team on a long deathmarch of a multimillion (and I mean two) and multiyear (and I mean like four) project to develop a custom piece of software for a client. I joined the team some months in, when they had a mostly working Java desktop application (perish the thought! because the application surely perished). I started testing an area of it and tearing it up. The client didn’t like this, didn’t like that, wanted more of that, and altered the specs so that my employer had to change it. I spent nine months essentially testing the same features of the same application and often logging the same issues when I left.
Don’t do that to your testers. Let them see different things, different projects. If you swap them around, they get more experience with the gestalt of the application/business/et cetera as well as learn new techniques, technologies, and music fitting for QA when they work with different people.