An enormous misconception among managers, and particularly IT managers, is that they should be better at everything than everyone who works for them. Nonsense -- it's the manager's job to map the team's strengths and weaknesses into a smooth picture, not do it all yourself. Seems like a pretty obvious professional value, right? Now picture this: some 23-year-old DBA fresh from Oracle U. is telling you how the basic schema you helped architect four years ago, the one that you've been able to scale through four application revs, the one that won a corporate-wide performance award for you and your buddy who's gone on to start her own consultancy -- well, that schema is pretty stupid, according to your junior report. I'd like to say most managers understand that you can't just snap back and tell your inexperienced team member to shut up, even with nice words. I'd like to, but I can't, because it happens all the time. Getting defensive about your own accomplishments, goals, and motives is a natural human instinct that you've got to contain as you initially respond to such criticisms. But checking your ego doesn't stop at just refusing to get into an argument with some smart-aleck kid. Because the kid may be right. Recognising, and even rewarding, employees who have better ideas than your own while maintaining your position as the team's alpha dog is absolutely one of the toughest challenges in management, especially in an industry where bright young talents are often referred to as "fighter pilots" or "rock stars." You want to hold on to these rising stars, and if you're smart you'll take advantage of their good ideas and passion to show you (and everybody else) how smart they are. Those are their strengths. Rock stars can drive you and other team members crazy with their rash comments, careless bravado, and resistance to constructive criticism. Those are their weaknesses. Drawing a map that makes these two routes converge at success can be a nightmare. Here are a few tricks I've picked up over the years that have helped me wrangle young employees' ego without undermining my own leadership position. Some of them may sound a little duplicitous at first blush, but I've found them to pay off in the long run. Remember that you were once the smart-aleck kid that's now staring across your desk at you. I know this seems like a given, but it bears constant repetition. If you let challenges to your ideas or practices get to you on a personal level, the junior team member will sense it and it will taint all your future constructive efforts. Look back at past conflicts you had with your own bosses --it's natural, they happen -- and use those experiences to build empathy with the frustrations that your junior team member is probably feeling. Let your rash young employee try out a bad idea and fail -- or maybe succeed. Like I said, some of these tricks may sound a little sneaky at first. But nothing teaches like experience, particularly in the case of headstrong young talent. When a junior member challenges a practice or standard, even one you initiated, at least consider developing a controlled environment in which he or she can try out the idea. Of course you don't want to rewrite your SOP on the spot, but what's it going to hurt in the long run if some low-priority project delivers a couple weeks late because you dropped the formal Gannt updates on the project timeline? And who knows, maybe the deliverable will come in a couple weeks early. The kid may be right, after all. Make the challenging employee explain what went wrong, and how we can do it better next time. When you let an employee challenge a team practice, make sure going in that he or she understands you expect a report about how the experiment went, and ways the team can use the experience to improve in the future. Don't be mean, but don't be overly gentle in your criticisms of mistakes, either. Allowing a team member to buck the system a bit is a gesture of respect on your part, and it entitles you to be candid in evaluating the results. Go out of your way to give credit where credit is due. If a team member's mold-changing idea pays off, make sure everybody knows that it was that team member's idea. Nothing erodes the basic trust between a manager and an employee than the notion that the boss is making himself look good at the employee's expense. And no matter how hard you try to avoid giving that impression, it's an unavoidable suspicion. Note the team member's input at the next team function, and if at all possible make sure that the email you send your own boss about the change in practice includes a full attribution to the team member who came up with the idea. Don't be afraid to draw the line. Don't let a headstrong employee confuse your willingness to entertain challenges to team standards for unwillingness on your part to enforce standards where you deem appropriate. My best advice here, particularly if you find yourself faced with a potentially disruptive employee, is to revert to management-speak to establish a line between "practices" and "business values." Peer review of code may be nonnegotiable because it reflects a core business value of maintaining a reusable component library; peer review of a low-priority functional spec may be a practice that's fair grounds for an experiment. Clearly laying out the ground rules will give the challenging employee a framework for constructively criticising your ideas, and you won't find yourself backed into the no-win "Because I said so" corner. Get used to it; it never stops
No matter how much experience you gain as a manager, dealing with criticism from your employees will always be among the toughest challenges you'll face. You're going to become increasingly confident in your experiences and decisions, and there's an unlimited supply of smart-aleck kids out there who will interpret your attitude as stodgy and intractable. Just remember, as those kids learn through the mistakes you let them make, you'll be able to confidently place them in project leadership and mentoring roles. And then one day, as a final sweet irony, they may even become managers and have to put up with this stuff for a living. Created by developers, for developers, Builder.com brings software developers fresh, real-world perspective on topics from programming to architecture to management. Builder.com will improve the way developers work with the information, tools, and services to help them conquer the challenges they face everyday in real-world development.
For all job and work-related news, or to search for a job and get information on training, go to ZDNet Jobs.
If you have something to say about work and employment issues say it here at the Jobs Forum.
Let the editors know what you think in the Mailroom.
