In an IT manager’s world of shifting priorities and stretched resources, it’s easy to forget that “reorganization” is a dirty word to most employees. Sure, we’re trying to make a smart strategic move, but to our team members, it just seems that a detached senior manager had a bright idea. The only real changes in their world are moving offices and dealing with a new jerk in quarterly meetings.
Unfortunately, they’re often right. Of the 10 or so reorgs that I’ve been through as both a team member and manager, I can think of only a couple that resulted in some real gain for my company. My frustration, which I think is shared by most ground-zero staff, is that after the initial buzz, it’s like nothing happened—I didn’t have new resources at my disposal. I wasn’t facing new challenges. The company wasn’t tackling any new opportunities. It was business as usual.
Of course, the perceived benefits of the reorg may have not been readily evident to me down there, three layers below the executives who just shuffled direct reports. That’s management’s fault; it’s our job to make sure the brilliant strategies we debate in meetings ultimately trickle down to where the work gets done.
So the next time you hear that the company is thinking about a reorganization (and it will, of course), consider these transitional tactics to make the change meaningful to your team. Some of them are fairly simple; a couple will take a little elbow grease. But I’ve found them to be invaluable, not only in practice but also as a litmus test for whether it is really worth it to redraw that Visio org chart. If these approaches don’t make sense, maybe team assignments should remain the way they are.
- Attach 6-month and 12-month success metrics to the new organizational structure. This one is probably the best defense against truly needless reorgs. You wouldn’t launch a new Web site or product line without a set of tangible goals; you should be equally circumspect with major shifts in your company’s structure. If you’re combining the network and e-mail administration groups, then set a target date for cracking that Active Directory/Exchange 2000 nut. If you’re combining three units with their own Oracle DBAs, there’s got to be some measurable saving in contractor dollars out there. At the very least, a manager should have some more free time to tackle a quantifiable strategic project, such as formally evaluating an EAI platform. Reorgs have to have a bottom line, or they don’t make sense.
- When you get a new boss, make sure that some aspects of your direct reports’ jobs change too. Sure, Java developers are always going to have the same core responsibilities. But if your group is moving into a larger unit that includes QA and some Web Ops function, make sure your guys make new contacts with those new peers to improve processes and capitalize on the perceived synergies that motivated the reorg in the first place. If you’re breaking out into a self-contained unit, then make sure your team is creating and distributing documentation and policies that solidify your new role as a specialized unit. Senior team members may rate a change in their formal job descriptions to designate them as liaisons to other units in family or to vital contact points that have moved farther away in the formal corporate structure.
- When you get a new team member in a reorg, you must modify their job description or formal goals. If employees aren’t going to be doing something substantially new, then leave them where they are. Again, this doesn’t denote a change in the employee's core role or skills, but there has to be some advantage that you can quantify in the employee’s goal set for the next review period. Otherwise, you’re just spinning wheels.
- Set up an occasional group meeting or other communication for everybody under your functional umbrella. You face an obvious logistical challenge if you’re high enough up the management structure that your team encompasses 40 or more people. But if these employees’ work is so closely related that they should be organized in the same unit, they have information to share. And there are a ton of details and great ideas out there that you may be missing out on. Regular reports on the success metrics you’ve set for the new organization are a great starting point; e-mail distribution lists and Microsoft-based intranets are a good idea, as well. Whatever method you choose, be sure to focus on the common goals and standards of the whole unit. If you can’t think of any common goals and standards, you have an organizational problem.
- At the highest level, don’t confuse a “reassignment” with a “reorganization.” In multilayer organizations, a simple workload adjustment or mission change for a vice president is often incorrectly positioned as a “reorganization,” with the commiserate flood of title changes and road shows to the satellite offices. If your company really does need to just make a couple of changes at the highest levels that won’t affect operations a couple of layers down, don’t call it a reorg and keep title-shuffling to a bare minimum.
- Carefully track any existing personnel issues through the reorganization process. Let’s be honest; reorgs have largely earned their reputation as lame ways to shuffle problem employees, particularly in smaller organizations. I’ve found this largely to be because managers tend to call a “do-over” when they take on a new employee out of a misplaced sense of fairness. Of course you want to be open-minded, but don’t overdo it. I once inherited a notorious problem staff member in a reorg who turned out to be a reasonably solid employee. She had some basic issues that required management attention, but she had simply been passed from manager to manger without getting the consistent coaching she needed to make a turnaround. The worst-case scenario here is that your other employees immediately turn sour on the new team structure because now they have to work with so-and-so. It rapidly erodes your team’s confidence in the company and you as their manager.
Of course, I’d like to be able to say that you should reorganize only once every two years or provide some other blanket safeguard against this aggravation. But reorgs are a reality of business, and sometimes you have to do them simply because the current organizational plan wasn’t the best guess. But at the least, take these or other concrete steps to make sure your team doesn’t come to view what should be a great opportunity to do a better job as just more management noise.
Ken Hardin is a freelance writer and business analyst with more than two decades in technology media and product development. Before founding his own consultancy, Clarity Answers LLC, Ken was a member of the start-up team and an executive with TechRepublic.com and ITBusinessEdge.com.