Software Leaders – Are you bigger than your team?

As a “leader”, are you “bigger” than your team?  Do you want to be?  Should you be?  Some are, some aren’t, some want to be, and some don’t. Some self-describe their “leadership” whereas others don’t, they let their leadership skills be judged by their team successes and accomplishments. By the way, I hate the term “leader” as a self-describing term, although not to diminish great leaders who choose to describe themselves that way.

I read countless headlines on resumes or LinkedIn where people have self-described themselves as “A passionate leader who…”, “A great leader who….”, “Innovate leader who…”, etc.  The problem is that these are just words someone uses to describe themselves as a leader without providing the gusto.  What is important is what your teams’ have accomplished.

I was originally going to name this article, “You’re not bigger than your team”, whereas bigger could mean better, above, superior, louder, or more important, but it sounded too preachy and I don’t want to generalize. Maybe you are bigger than your team? Maybe it matters, and maybe it doesn’t. What I am going to describe are the reasons why it’s unnecessary and could be debilitating to be “bigger” than your team.

I’ve had the tremendous opportunity to lead both large and small software teams over the course of my career, but what was always important was the success of the team. You need the team for success, and the success of any leader is based on the success of the team.

A manager is “above” the team, just by definition, but this article isn’t about “managing”, and it’s certainly not another “boring” article about management vs. leadership, because who wants to read one of those, and I certainly don’t want to write an article that’s been written many times over by many other people. This is a quick article on my take on leadership based on my experience “leading” (there I am self-describing…) software teams.

  • Get things done. As a leader, be a very high performer and get things done. Help all team members to get things done. If the team knows you’re “invested in this”, they’ll want to be invested too.
  • Your due (and the teams) will come.  When your team delivers, people notice.
  • Understand the mandate. Understand what’s expected of the team and make sure the team understands it as well, but don’t lose sight that we’re all people and we’re not machines.
  • Meet your mandates.
  • Consider the long term implications of your mandates I consulted on a large enterprise project about 5 years ago where a “leader” decided that the only way to make the project deliverable was by having the entire team work 12 hours a day plus weekends for 6 months (fortunately my consultant role was outside of this “working machine of people”). They got the job done, but destroyed their entire software department in the meantime. All key people went to their direct competitor and others just found jobs elsewhere. The leader got his bonus for the deliverable (on the team’s blood, sweat, and tears), but was later shuffled out (aka, fired). Unfortunately, in this case the organization had embraced a culture with short sighted incentives that destroyed the team in the long term. 
  • Team collaboration – the team has to know each other and be responsible to themselves and each other. This will help ensure high team performance.
  • All ideas should be considered from all team members equally, including any of your “leader” ideas.
  • Take the role and the team seriously, but build a high level of rapport between yourself and the team members as well as between all team members.
  • Know that successes are team successes, and failures are team failures, but still have pride in the team.
  • Dysfunctional teams (and organizations) praise leaders and blame team members. Don’t be that. I consulted with another enterprise client several years ago where I had the unfortunate opportunity to witness team leaders given awards for minor team achievements (where as the team members got to also clap for their supreme leader of doing a great job of leading them – the team got nothing). I also saw team leaders pointing fingers at team members as the reason for specific team failures – which of course lead to meetings with HR personnel about performance, etc (what the?). If your team is continually failing, the leader of the team should always be the one in question. That’s where the buck stops. As a leader if you recognize that, you’ll understand it’s on you to make sure your team is performing and meeting mandates.
  • Performance reviews are pointless – just don’t do them, they signal that you value individual performance over team performance. I’d prefer to see a team performance review. Nothing wrong with having your team give you a performance review though. If you’ve developed that kind of rapport with your team, then you should be able to get honest feedback.  I’ve found many people, even in senior positions, completely unwilling to solicit feedback from anyone other than those they report to.  It’s unfortunate as it shows who’s opinion they value (the people they report to, and not those who report to them) – don’t be that person.
  • Mentor – create a system of mentorship whereas you (the leader) or other team members are mentoring each other for the collective benefit of the success of the team.
  • Always retrospect.  Always learn.  Your own personal introspection’s can be valuable as well (I do these subconsciously all the time).
  • Pressure – I learned many years ago that a little pressure is always good.  It’s better in small doses (occasional spikes in pressure are fine too).
  • Adapt – All teams are different.  Logistical or other factors may change team dynamics such as team members who work remotely overseas.  However, more frequent tele-meetings and communication can bridge the gap.

In the end, just be a good leader and find a way to ensure your team is successful no matter what.  You can’t sit on the sidelines.  Do everything you can.  Be cool about things.  Get things done.  Make sure the team gets things done.  Think things through. Think clearly. It’s basically pretty simple.  Always remember that it’s about the team, and not you.  That’s why you are not “bigger” than your team even though you may be demonstrating remarkable qualities of a leader.  It’s the team that gets things done, and those results are what is measured.

Those really are the basic principles of successful teams and are values and goals I try to instill in software teams. It’s only one part of delivering successful software, but it’s an incredibly important part.  There are always exceptions, and team & organization culture will play a part in team dynamics.  What works with one team won’t necessarily work the same way with another, so adapting while continuing to perform is important as well.  Organizations that understand this have created great teams because they have the right people, the right leaders, and the right approach.

Post a Comment

Your email address will not be published. Required fields are marked *