It's OK not to lead

When I first entered the workforce, I was in awe of the programmers around me.  I'd spent 4 years of college learning how to implement Alpha-Beta pruning and various flavors of sort(), while these guys had been building things that real people used in the real world for years, or even decades.  I imagine it was, on a much smaller and more cerebral scale, the way a college football player feels upon turning pro.

This didn't last.  After a while, I viewed them less with reverence and more as simple peers from whom I could learn, given their comparable wealth of experience.  As the years passed, the scales began to balance as I acquired more and more experience.  I was no longer the greenest developer around, and there was a healthy mix of people more and less experienced than I was.

The Path to Leadership

As this transformation took place, I started to develop opinions and preferences of my own, based on experience and on becoming a student of the craft.  I began to read books by people like Uncle Bob Martin and Michael Feathers.  And, sometimes, these opinions I was developing didn't line up with those of some of the people around me.  I started to notice that the practices advocated by industry thought leaders were dismissed or ignored by some of the people around me.

At the same time, I began to notice that the people making technical decisions from positions with names like, "Architect," "Principal Software Engineer," and "Team Lead," weren't necessarily the best, technically.  Often, these leadership roles seemed to be as much a function of number of years with the company and familiarity with the domain as they were a function of technical acumen.  And where the developers more experienced than me seemed diverse in their skill, philosophy and approach, the decision-makers seemed disproportionately to value a "crank out reams of code" approach.  And, of course, when you have differences of opinion with the decision-makers, it doesn't tend to go your way.

As I grew in my career and moved around a bit, this philosophical friction with entrenched technical leaders led me to the conclusion that the path to joy was to become a company's technical decision maker.  I'm also an ambitious, overachiever sort, so wanting to 'ascend' to a leadership position fell in line with my goals anyway.  I'd work hard and bide my time until I earned a leadership position, and would remain unsatisfied with my lot in life until that time.

Leadership Realized

There was a happy-ish ending to the first part of this story.  I found my way into leadership, through a combination of hard work, years in the field, and moving around some.  I was finally in a position where I owned the decision making.  I was no longer subject to determinations that the best approach to a public API was one giant class with hundreds of static methods.  I could preside over a clean codebase and a clean approach.

And, I did.  Things went well.  But there was a hidden irony to this which was that, as I acquired more leadership responsibilities, I dealt less with actual implementation.  I had all of the freedom in the world to make technical decisions, and no time with which to make them.  I delegated the work, for the most part, and trusted team members to do the right thing.

What I finally realized was that what I wanted wasn't actually to be the lead, per se.  By nature, I'm nothing resembling a micromanager, and I was't looking to be the person that made decisions for groups.  I was just looking not to have that done to me.  I didn't want to be micromanaged.  It took a lot of years, a number of promotions, and a wide variety of roles to understand this.

Team Member Is Just Fine

I was working as a CIO when I had this epiphany.  I had the IT and software development organizations reporting to me, and writing code was something I did in the evenings in order to keep my skills sharp.  Some serious reflection and evaluation of my situation led me to back away from that role and strike out on my own.

I became a freelancer, doing a mixture of application development, coaching, and IT management consulting.  The result was that I got to return to situations where I was closer to or directly involved with actually building stuff, but where I still was not being micromanaged.  And, I was quite happy with that.

But another interesting thing happened during this time, which was the departure of any remaining feeling that my role on a team represented achievement or rank.  The formation of a software team isn't as simple or obtuse as "the best, most qualified person is the leader."  I could choose to plug into a team to lend a hand and take technical direction from someone else, without it somehow lessening my standing or the perception of my competence.

This was a huge and surprising relief.  You see, being a team or department leader can be exhausting.  The buck stops with you and so you only get a small grace period where your answer can be "I don't know."  There's a point where anyone on the team can say, "gosh, that's just over my head -- I need help."  As the leader and closer, that's where you step in and handle it.  And, that's a lot of pressure.

I'd love to be able to give my younger self this message, but I'll have to settle for giving it to everyone reading.  You can find good teams, run by folks that aren't micro-managers.  You can put yourself in situations where you're empowered to make good decisions.  If you want leadership positions and to follow that path with your career, by all means, do it.  But understand that it's not a better position nor is it an indicator of alpha status and competence.  Pitching in, writing code, and contributing to a team is a great way to spend a career.   It's perfectly okay not to lead.

Deliver the most demanding and beautiful touch-friendly dashboards for desktop and mobile apps with over 75 HTML5 charts, gauges, financial charts, statistical and technical indicators, trend lines and more. Download Ignite UI now and experience the power of Infragistics jQuery controls.