Technical Leadership

Introduction

I can’t speak from much experience, but I do aspire to enter the role of a technical lead someday, with aiming for such ambitions, I’ve already begun preparing myself for such a role. An example of how I’m currently training myself for such a role is trying to think of some of the worst or complex scenarios that a technical leader may have to face, trying to provide professional, yet suitable solutions around such problems.

An example being where one may have to work with a developer who has more experience, more knowledge, etc, yet this developer may be a bit of a ‘hotshot’, this developer isn’t necessarily the best team player, maybe this developer is a bit of a know it all. How does one deal with such an individual? Of course such question depends on a wide variety of variables, including company policy, not to mention other variables such as the extent of such negative behaviour.

But the bad issues aside, to preair for such a role, I’ve been looking into the different styles of leadership, of course each style has its own set of pros & cons, and of course there’ll never be a one fits all solution. Again, context plays a massive role in the style of leadership that’s required to ensure that the work produced from a team of developers is produced to an expected quality, if not better.

Disclaimer

Please forgive me if you’re currently employed as a technical leader & you find this read a bit naive, of course I can’t speak on behalf of experience as a technical leader. But only the different styles of leadership I’ve been exposed to, in addition to my professional opinions & beliefs.

Charismatic Leadership

Possibly one of the best features to have as a technical leader is good charisma, the ability to influence others & generally come across as a friendly individual, by default this is an excellent quality to have. Whether this is purely due to nature of if you’ve had to work on it, it’s far from a negative.

Being a charismatic leader, in my eyes is someone who’s supportive, professional, yet approachable, someone who’s got your back to so speak, if not maybe even a friend. In my personal experience, one of my line managers in a previous role utilises this form of leadership to the dot, I recall on instance where the development team had a huge amount of work to deal with, he didn’t sit idle & do nothing. Instead, this line manager stayed with us, in the office until ~23:00 one night, helping us where possible, encouraging the team to strive forward. This specific individual rewarded the team, with a simple act of purchasing us a Burger King meal. If this isn’t a relatively excellent example, I don’t know what is, he would always provide the necessary support & he’d celebrate the team’s victories, big or small.

This strategy of leadership is so simple, yet so effective, however, it’s not always the best, again, depending on the context, such as working in a high risk environment. In such a scenario, it may be best to adopt a more bureaucratic style of leadership, ensuring that your team implements the utmost best of practices & ensuring that your team is following policy to the T.

Bureaucratic Leadership

With this style of leadership, to put it in plain English, I like to think of it as someone who will only play by the rules, no exceptions. Of course such form of leadership is necessary in many development teams, as stated, if there’s any form of risk involved, then this may be the better approach to follow. The only issue I see with this style of leadership is that it may limit the amount of innovation & creativity a team can work with.

An example as to when this style of leadership may be appropriate is when you’re working for a financial institution. Of course I’m not saying that as a technical leader in such a scenario, you’re to be a bit of a hard a**, but rather ensuring that the team isn’t implementing technologies or utilising tools that may introduce some form of risk. Whether this is a risk to the customer journey or a potential risk to the actual data that passes through your applications.

Laissez-faire Leadership

This is possibly one of my favourite forms of leadership, this form of leadership essentially ensures that the technical lead isn’t micro-managing everyone in the team. This form of leadership typically involves allowing your team to simply get on with it, this style of leadership is also referred to as ‘hands-off leadership‘.

I find that with this style of leadership, it allows the team to communicate better, as it allows team mates to make decisions, whether they’re technical or non technical decisions. One strong advantage to this form of leadership is that in my view, you act as an overseer, you only provide any form of technical guidance & assistance as & when needed.

Democratic Leadership

Of course, democracy is a proven strategy, wildly adopted by politics, it does indeed work for some teams, by promoting & even rewarding key members, it ensures that teams strive to perform to the best of their abilities. Everyone is given the same opportunity to participate, ideas are shared freely & communication or discussion is highly encouraged.

After all, communication is key for any team, this applies to both technical & non-technical teams. One thing that I really like about this style of leadership is that, provided it’s implemented well, it encourages honesty, fairness & other good qualities within a team.

Conclusion

So, I’ve very quickly gone over some of the different styles of leadership that’s stood out to me & as I’ve stated, the right style of leadership depends on the context, massively. But in my personal opinion, I believe that in order to be an excellent leader, you’ll need to adopt different concepts or strategies from an array of styles.

As an example; you don’t want to spend your time micromanaging your team-mates, that’s an incredibly inefficient way to spend your time as a technical leader. But at the same time, there will be scenarios where you’ll want to step in & take a bit more control over what it is that your team will be working on. An example being where you have a graduate developer, this developer has been assigned the responsibility to implement a feature on the payment portal that’s essentially a client side feature. In such context, you’d want to ensure that the work has been done correctly, after all, through the use of attacks such as XSS, it could be possible for an attacker to obtain financial credentials.

This is where of course standard processes such as encouraging extreme programming principles & peer reviews come into play. Even if no mistakes are made, it never hurts to have a second pair of eyes to look at the processes that are being implemented into an application.

In my experience as a developer, aspiring to become a technical leader, I can’t stress how important communication is, just talking to teammates, it’s the most effective way to communicate, period. An example as to when I’ve found face-face communication critical is when dealing with an application that is incredibly stateful & the state management implementation is very complex. This included diving beyond the application, actually analysing the underlying business processes, so of course, trying to communicate concerns related to this matter via teams/slack/email would’ve proven to be a nightmare.

Anyhow, I’m going to bring this article to an end by simply stating that the content within this post could go far beyond the scope that it’s covered, including different agile methodologies, strategies, etc. I hope that you’ve enjoyed, provided you’ve made it this far & I hope that what you’ve read has either given you an idea on how you could improve your technical leadership or how your boss could improve their leadership skills, etc.