Managers love a good lead. Your “go to guy”. Your problem solver. She can collect a random set of inputs and come back with the right thing to do even if not a single one of the inputs hinted at the true problem.
I had two calls today with different types of leads (hence the pronoun switch in the opening paragraph) and both of them impressed me with their understanding of leadership in the team context. The goal of the lead is to get to the right answer for the tough problems using the best information and resources available.
Some leads are thought leaders. “Let me go off and think on this one a bit.” Other leads are researchers and consensus builders. “Let me get with our UI developer and designer and see if we can’t find a solution.” Still other leads are coaches, which is one of my favorite types.
I am familiar with the recruiting practices of some of the larger software companies in the valley and have noticed that several of them seem to be only recruiting leads and leadership personalities. Some top-notch engineers slipped through the cracks because the process did not account for teams and different leadership styles. Put another way, while I love a good lead, the best teams I have managed were great because everyone executed their role well. Michael Jordan starting winning championships when he started passing more.
I created the follow graphic to illustrate what I mean. Please, no jokes about this not being a pyramid though I do love a good pyramid too!
The image shows various roles on a project. Typical challenges, issues or areas of functionality you might encounter are listed in the center. This team might be used to develop and deploy a large-scale application in a hosted environment. Your team make-up might be different, for example, smaller development teams often have one lead/architect/data architect.
Take integration in the lower left as a good example for how this chart works. Programming interfaces can be very detailed and time-consuming to learn. Server engineers tend to be more disciplined and focused. Also, you should use the same person who designed the integration to implement the solution to limit the learning curve to one person. You need the system admin to work on protocols and security issues. As another example, user stories often come together from a collaboration between design and development teams.
You now see the challenge if you hire only leads for your teams. We can set aside all the comments like “too many chefs spoil a meal” or “too many chiefs and not enough Indians” if you like. Simply put, the best people to solve problems might be those who actually prefer not to be in leadership positions. You’ll end up with a treasure trove of people who might be really into the minutia of data or very interested in understanding how systems communicate with each other. The best teams are filled with diversity and overlapping interests.
The lead is essential and the best ones form the foundation of a strong team. Once you have that person, your best bet is to surround him with specialists, experts and code jockeys who all understand their role in the team dynamic well.
