It’s been some days since my last post but that has not been by my wanting. In any case i have been learning a lot in the meantime that I shall soon discuss here including Visual Studio Team System, Team Foundation Server and more.

Speaking of teams, well, it is common for companies and especially software companies to have engineers working in teams (you know, like the C# team, or the VSTS team at MS etc…). Well, a bit of a dicey issue when it comes to teams is leadership.

Theodore Roosevelt, one of the greatest American presidents, (and quite frankly having done A LOT of research and reading some of his speeches… truly a REMARKABLE man!) said:

Everything rises and falls on it’s leadership – John C. Maxwell

So in a team you might have say a program manager, project manager, team lead or technical lead or any combination of these.

Leadership is influence – John C. Maxwell

And so it is the task of these people to influence and chart a direction and channel the efforts, talents and expertise of their team towards the achievement of some vision and indeed, vision is the glue that holds together a the team!

A few weeks ago an experience drew me to want to learn more about this area of leadership i.e. Technical Leadership. In the process of learning about this I came across this very interesting article from hacknot.If I ever were to be in such a position these would be the equivalent of the ten commandments. The article is titled ‘Great Mistakes in Technical Leadership‘, here I give a short synopsis of the article, with some additional insights from my readings in leadership. There are many more articles and you can download a compilation of articles in pdf format that deal with topics ranging from management, agile methods, project management, programming vs. developing and much much more here.

Great Mistakes in Technical Leadership

The article starts with an interesting quote:

If you are a good leader who talks little, they will say when your work
is done and your aim fulfilled, ‘We did it ourselves.’ Lao-Tse

And the author goes on to explain the unique position of the Tech Lead as he sits in between management and the team and has to represent both sides and act as a form of interface between them. Interestingly he says that probably the most basic rule in technical leadership, an almost equivalent to the ‘First do no harm’ in the Hippocratic Oath would be ‘First do nothing stupid’.

The Great ‘Do Nots’!:

Mistake #0: Assuming The Team Serves You

Perhaps the most damaging mistake a Technical Lead can make is to assume that their seniority somehow gives them an elevated status in their organization…

If anything, it is you that is in service of them, given that it is part of
your role to facilitate their work

I can’t quite remember who, but in a leadership book I was reading recently, there was this quote (I hope I get it right)…

Leadership is when something goes wrong it is your fault, when things are OK it’s because of US and when things succeed it is because of them!

Theodore Roosevelt, one of the greatest American presidents, (and quite frankly having done A LOT of research and reading some of his speeches… truly a REMARKABLE man!) said:

The best executive is the one who has sense enough to pick good men to do what he wants done, and self-restraint to keep from meddling with them while they do it.

 

 

Mistake #1: Isolating Yourself From The Team

Here’s a catchy one:

I must follow the people. Am I not their leader?
Benjamin Disraeli

The author says:

As military leaders know, it creates an artificial and ultimately unhealthy class distinction between soldiers and officers if the latter are afforded special privileges.

My mentor normally tells me that if you lead to far ahead of the team you are only but taking a walk. According to the author this is especially the case when the Tech Lead is isolated from the team’s work area and does not interact with them much or has been given certain privileges that tend to create a rift between the leader and their team.

Mistake #2: Employing Hokey Motivation Techniques

On this point I must say I totally agree with the author. (Sponsorship to MIX, or TechEd or the Web 2.0 conference would be a BIG motivator to me, personally)!

Clearly technical people motivated in unique ways. Motivation is one of the leaders most challenging functions, in my opinion. Influence is in a sense synonymous to motivating in a certain direction.

Programmers regardthe sorts of rewards that managers typically receive as superficial and trite… So if you want to motivate a developer, don’t start cheering “Yay team” or force him to wear the team t-shirt you just had printed. Instead, give him something of use… Developers are also constantly mindful of keeping their skill sets up to date, and so will value any contribution you can make to their technical education… just as long as it has career value to them.

Mistake #3: Not Providing Technical Direction And Context

I would liken this to what John C. Maxwell (you can tell I have read a lot from him), calls casting vision. It is looking ahead and foreseeing any eventualities that are likely to affect the current progress of the team and making decisions or bringing them up for discussion by the team, of course in a technical sense. The author specifically talks about the tech lead being in a position to clearly specify the software’s architectural structure before implementation begins.

Again, as my very values mentor constantly reminds me:

‘Wilfred, you just can’t lead from behind!’

Makes terribly good sense doesn’t it! Theodore M. Hesburgh says:

The very essence of leadership is that you have to have vision. You can’t blow an uncertain trumpet.

Something I found very interesting under this point is the fact that the team lead should.. ‘always be prepared to admit that a decision you’ve made was incorrect’, when the case is as such.

Mistake #4: Fulfilling Your Own Needs Via The Team

The basic point is this, the team does not exist for you, you are there as a servant to the team! It’s what someone calls the principle of the ‘Servant-King’. The technical lead should be more concerned about ‘making efficient use of people’s time and effort.’

More in the next part soon to come!