I don't mean to imply that it's a bad thing to be promoted — quite to the contrary. But as you move up the corporate ladder, things change. And you have to change, too.
Anyone with ambition — by which I mean "I'd like more responsibility (and a bigger paycheck), when I'm ready for it" — has to accept that moving up in the organization requires new skills. That sounds benign and obvious; after all, one reason to hope for a promotion is that you want to learn and do more. But consider how many people you've known who were good developers but lousy managers. I'm sure that a few people spring to mind; I get an immediate mental picture of a guy named Eric....
Anyhow, if you've been promoted (either within the company or by moving to another firm with a shiny new job title), you may think of your new challenges in terms of expanding your existing skills. In reality, writes Michael Watkins in Your Next Move: The Leader's Guide to Successfully Navigating Major Career Transitions, any promotion requires you to exercise personal discipline; the qualities that made you successful so far might be weaknesses in your new role. "Wise leaders in transition therefore ask themselves, 'What am I good at (or enjoy doing) that I need to do less of?' and 'What am I not so good at (or don't like doing) that I need to do more of?'"
That's a brilliant set of questions to ask oneself. When I start a new position, I am easily overwhelmed by the Impostor Syndrome — that sudden certainty that I don't know anything and they're all going to realize it momentarily, despite my intellectual knowledge that I'm qualified. (It's a common feeling, I assure you. Though in my experience women seem to want to talk about it more than men do... ah, that's another discussion.) When I feel insecure, it's entirely too easy to fall back on what we know how to do well, which almost by definition is the stuff that you often did in your previous position. It's easy to turn to an area of competence instead of confronting the hard new skills... and I think it would help me to keep the "What shouldn't I do?" questions in mind.
Watkins book is very much geared towards business executives who may be less annoyed by his CorporateSpeak than you and I. But plenty of his advice is relevant even at lower echelons such as developers who are promoted to team lead. You still need to write code, but you're also supposed to grow leadership skills. Your relationship with former colleagues is going to change. As Watkins enumerates, anyone being promoted has these challenges:
- A broader impact horizon (I told you he used CorporateSpeak), by which he means you have to address a wider set of issues than you did previously
- Greater complexity and ambiguity, with more social and business variables to consider
- Tougher organizational politics, with more powerful stakeholders
- You're further from the front lines. With more distance between you and the people "executing on the ground" (as Watkins puts it — you might be tempted to say, "Doing the real work"), you have to develop the ability to influence others rather than tell them what to do. (This issue becomes more relevant the higher you climb the company ladder.)
- More scrutiny. In other words, more people will notice if you screw up.
Watkins has useful things to say about each of those challenges for the just-promoted, but the one that got my attention was the necessity to influence differently. "The process becomes more political — less about authority, and more about influence — which isn't good or bad, simply inevitable," he writes. Many techies see this new awareness as selling out, and they believe that anything that can be labeled as political is inherently bad. Thus you may be tempted to back away from learning to shape your decisions based on others' expertise... and you might just try to do a task yourself when it's more important to delegate (even if, yes, you could do it faster than your old teammate).
If you're promoted ahead of someone else, you'll have politics to deal with anyway. If someone else also wanted your new Team Lead position but was passed over for it, you may need to cope with her resentment, or at least her uncertainties about why you got the job and she didn't. (Boy, can I relate to that. I started looking for a new job two months after Eric got the job I believed I deserved.) According to Watkins, anyone who'll be leading former peers must focus early on rites of passage and establish authority deftly.
This sounds as though I love Watkins' book. In actuality, I have strongly mixed feelings about it and several chapters apply only to senior management. (It's unlikely that your company will transfer you to another country, yes?) However, the specific suggestions he offers for people promoted over former coworkers are among the strong positives.
Watkins has several other suggestions beyond the ones I mentioned, but the one that grabbed my attention was a good idea that I've never even heard of anyone implementing: holding a "new leader assimilation session." The key piece is for a facilitator to anonymously collect data from the team members, such as answers to "What do you want to know about the new leader?" and "What do you want the new leader to know about you?" I can imagine how useful that information would be to the new team lead, and if nothing else it'd make the whole team believe someone cares about their feelings during the transition. Maybe not as much as being involved in the hiring process, should a new team lead be brought on from outside, but it'd help. If you've encountered any effort to smooth a transition from developer to team lead (or higher), whether or not it worked, I'd sure love to hear about them in the comments, and I dare say others would be interested too.
This story, "Surviving a Job Promotion" was originally published by JavaWorld.