Want to create a noxious gas? Combine ambitious yet clueless engineers, a flat functional organizational structure, and the upcoming midyear career discussions. Soon toxic fumes will emanate from individual contributors (ICs) in response to impotent explanations of upward mobility by overwhelmed managers.
Why the wanton whining from wishful workers? Because the technical leadership path is poorly understood, and the organizational leadership path is narrowing. The flat functional structure of most of Microsoft’s divisions today reduces the number of engineering managers and tends to up-level those positions. So now a developer can reach the level of vice-president within discipline, but it’s tougher for that developer to start out in a lead position.
Functional organizational structures tend to drive most engineers into the IC ranks. The good news is that Microsoft® has a robust growth path for IC engineers. At the time of this post, most senior and principal band developers are ICs. It’s not until you reach the partner band that most developers are managers. The trouble is most ICs and their managers have trouble describing technical leadership. How do you get started? How do you reach the senior band as an IC? Glad you asked.
There are many ways of going forward
I covered the Microsoft career stages and how to generally move up in my column Level up. I covered how to get from senior to principal as an IC in my columns Lead, follow, or get out of the way and “Get yourself connected” (chapter 7). The question remains, “How do you first establish your technical leadership and become a senior IC?”
For completeness and clarity, there are three ways to reach the senior band:
1. Become an organizational leader (boss), typically an engineering lead. As I mentioned earlier, these positions are dwindling, especially among the developer ranks.
2. Become a technical leader (guru), typically an expert in some area. This is the focus of the rest of this column.
3. Become a historical resource (sage), typically a longtime team member. This path takes the longest and has the most limited growth potential.
In each case, you are influencing the work of other engineers—as a manager, as a thought leader, or as a resource. Of course, many engineers are combinations of bosses, gurus, and sages. However, being assigned a position as a boss is getting tough, and becoming a sage is a very slow process, so let’s focus on becoming a guru.
Ask the expert
Being an effective technical leader means influencing the opinions and actions of other engineers. In science fiction, that influence is accomplished through mind control. In real life, that influence typically starts with expertise.
Basically, you want to become the “go-to” person for some area. The area could be
§ A technology, like LINQ®.
§ A performance area, like power consumption.
§ A functional area, like copy/paste.
§ A quality area, like accessibility.
The key is that when someone on your team has a problem in that area, he goes to you for a solution.
I know I’ve got a bad reputation
Once you’ve picked an area, you must convince your peers to see you as the area expert. You need to build your reputation around that area—also known as your personal brand. You want to be known as the “LINQ legend” or “power pro.”
Your first step is to become well-versed in your desired area of expertise. It helps to pick an area you are passionate about and already know fairly well. You can read books and attend talks on the subject, join related distribution lists, seek out other experts around the company, and volunteer to take on significant problems in that area for your group.
Support from your manager can make a big difference. Your manager can help you get the right assignments, approve the right training and conferences, and generally help you to establish yourself. Of course for any of this to happen, you must tell your manager about your interest in becoming an expert in your chosen area.
The next step is being opportunistic. When your area of expertise comes up in conversation (written or verbal), have something intelligent to say that is supported by evidence. “Yeah, Eric Meijer talked about that in his LINQ webcast. The right approach is to …” You can do this in a code review, on your blog, on a distribution list, in a wiki, on Stack Overflow®, MSDN®, or some other forum—wherever or whenever expertise is needed. The more you contribute in a helpful—not showy—manner, the more people your expertise will influence.
Quality is job one
“But what area should I choose?” Some people naturally migrate to particular areas of interest, but many engineers like technology in general. In addition, often all the “good” areas already have experts on your team. So what’s a fledgling expert to do?
Go for quality! There are plenty of “-ilities” that don’t get enough love—maintainability, manageability, accessibility, compatibility, sustainability, availability, interoperability, reliability, traceability, scalability, survivability, testability, and usability, not to mention the big three: world readiness, security, and privacy. Heck, I’ve probably missed some. Surely, there’s an -ility for you.
The great thing about being a guru in a quality area is that the knowledge is transferable to other teams. Many quality areas don’t get the attention they deserve, and quality is important to every product. You can continue developing your expertise your entire career, and your personal brand will stick with you wherever you go.
That’s a stretch
There are a few pitfalls on the path to expertise. You want your choice of expertise to be your own. Your lead or co-worker might suggest a work area to you that appears challenging, but really doesn’t hold your interest or seems like a death trap. Stay away from that area. Remember, if you are going to be the point person for an area, you’d better like it.
Even if you like the area suggested, you need to watch out for stretch assignments. Stretch assignments are terrific—they can really accelerate your career. However, nothing comes for free. If you fail at a stretch assignment, then you fail. You don’t get an exceptional review for failing, no matter how much time you put into the assignment. Instead, your reward is extra experience.
Why do stretch assignments? Because the extra experience you receive is extremely valuable. Your career will move forward faster in the long term. In addition, if you are lucky enough to succeed (and there is always an element of luck), then you can get an exceptional review. Regardless, you want to accept a stretch assignment knowing the risks and as well as the potential rewards.
Your success in being a respected expert depends greatly upon your ability to effectively communicate your expertise and influence the work of others. If you don’t listen well in order to understand people’s problems and communicate well in order to describe your solutions, then your vast knowledge is for naught. People might as well consult a brick.
For pointers on listening and providing feedback, try reading I’m listening. For pointers on general communication, try “You talking to me?” (chapter 8). The point is smarts will only take you so far. Think of all the successful experts you know—they are all good communicators. Think of all the expert wannabes you know—they all have something in common too.
You can do it
You’ve got to be a smart, capable engineer to reach the brink of the senior band at Microsoft. The next step as a technical leader is available to everyone. It requires hard work, but it’s not especially complicated.
Choose an area you are passionate about. Learn all you can about it. Tell your manager about your interest. Work in that area and on your communication skills. Advise others in that area. Socialize with experts in that area. Become the go-to person for your team.
Soon you’ll be spreading your influence across your team and turning heads in the process. It’s rewarding, it’s fun, and it provides real meaning and value to your work. It’s your road to individual leadership—time to buckle up and drive!