Should You Be The Smartest?

Should you, the leader (think manager, director, VP, etc.), be the best technically on your team?

I struggled with this early in my management career. When I managed teams with excellent developers, I felt a need to show them I could get down and dirty into the code. Periodically, I'd make minor changes just to show them I "still had it."

However, technology changes.

Fast.

The only way I could remain competent in technology was at the expense of my manager role. So here I was, facing a dilemma: To manage technical folks, I had to remain technically at the top. To remain technically at the top, I couldn't spend time managing.

So I did what we used to do when we coded ourselves into a circular loop.

I hit control-C and stopped my internal “programming”. I gradually developed new internal programming.

My management value isn’t determined by being the smartest technically on the team. It is based on recruiting and retaining people technically superior to me. More than that, it is developing each of them to grow in their professional (and yes, personal) lives. This recognition changed my relationship with my teams. Most importantly, it freed me from having to prove my technical skills every day.

Instead, I could focus on learning the business in order to help my team make better technical choices. That’s right - in order to get the most out of a technical team, I had to transform myself into a business leader.

You may be saying to yourself (and the many friends who are certainly huddled around your monitor as you read this), “You have to be technical to manage technical teams. That is the only way they respect you.”

I would agree – to an extent. I’m not suggesting that you ignore technology. It is a matter of focus. Instead of spending days writing code, consider the value of time spent learning your business and what your customers are attempting to achieve. You then have an opportunity to return to the technical discussion with a perspective that your team members may not have (as a complement to this, see my post on building customer facing teams).

Keep in mind that many successful coaches were great players. But when their teams won the championship, they were on the sidelines, not the field.

History: Its there for a reason

I recently had discussions with several senior engineers about “modern” software architectures. The conversation turned to service-oriented architecture. While discussing the merits of SOA principles, I was struck by their consistency with principles developed 30 years ago or more. For example, fundamentals such as information hiding, modularity, and coupling. These are time-tested principles that have been the foundation of major evolutions in software architecture since the 1970’s (and perhaps earlier).

Don’t get me wrong – I’m not suggesting that SOA is merely a new name for old concepts. The SOA discussion was merely a trigger for me to consider how we, as practitioners of our discipline, learn from and incorporate lessons from our past. My observations have led me to believe few development folks spend much time seeking and learning from the past. For example, how many members of your team have heard of Fred Brooks, Jerry Weinberg, Tom DeMarco, Dave Parnas, Barry Boehm, Watts Humphreys, and many others who paved the trail for large system software development and managing teams? Of those that have heard of these people, how many can articulate the key concepts and contributions these folks have brought?

Let me fast forward to my point, or more accurately, my question to you. What are you doing to know the history of software development, and what are you doing to encourage your team members to do the same?

You may ask why I seem concerned with lessons that are in some cases 35+ years old. I would tell you that the variety and depth of reading/learning I’ve done has served me well.

New technology doesn’t appear as “new”. Process innovation looks more like a natural evolution of what I know, versus, well – innovation. I view emerging technology and practices with a critical eye of “how is this like what I know” and “to what degree does it differ”, as opposed to “wow – I have to learn a whole new (insert your favorite thing that will be obsolete in 5-10 years).”

By learning about software engineering history, I have at my fingertips some of the best and worst methods that have been learned in the trenches. That gives me a much broader experience base than what I would have if I limited myself to only what I’ve seen firsthand. This in turn, increases the set of responses available to me when faced with “new.”

So next time you are looking for a new book, consider an “oldie-but-goodie”. You might just find that someone has grappled with very similar problems years ago that you are facing today.