My thoughts on Technical Leadership

I always knew than every software house needs some level of technical leadership competence to create sensible environment for interns and junior developers. Recently I realized that this competence can be beneficial for every team and every team member, even experienced one. Some companies have a dedicated position of “Technical Leader”, a person who carries responsibility for managing team’s technical skills and oversees technical aspects of the projects. Other companies put this responsibility on a “Team Leader” which is fine as long as team leader has time and skills to do this. The question here is whether a good team leader will be always also a good technical leader. Does it takes special set of soft skills to be a good technical leader? Last but not the least ,there are companies that don’t care about it or don’t realize they lack this competence (probably most dangerous situation).

I’m looking for some good reading about it. So far, I found those two books : Scaling up Excellence and The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise. The second one is more about building scalable solutions but contains a few chapters on technical leadership.

I think there is real need for technical leaders in our industry. Some soft skill required to be a good technical leader overlap with those required for being a good team leader, but others are orthogonal. It doesn’t mean that one person can’t be good at both, though. I’ve worked with some really good team/technical leaders. It’s not important what was the name of their positions, they are really good at both competences.

Team of juniors/interns

Technical leadership for interns and juniors is extremely important and at most companies neglected. Throwing interns or juniors to ongoing project just like that can be beneficial but it also can  be harmful. With just a bit more effort you can make adoption process much more smooth and beneficial for you, interns and your company.

I actually experienced how it is to be a tech leader for interns. It’s a good experience and my “students” probably agree that our meetings and workshops made a difference and were worth the effort. This is kind of leadership where you offer shortcuts in learning curve. One can write thousand tests before they realize that obeying dependency inversion principle makes code easier to test. One can also be taught to obey it from the beginning and write the first thousand tests in half the time.

This is kind of leadership where you use both your experience (you give a lot of examples) and your authority to back your point. They may not fully understand it straight away, but it will come home quickly. It’s a bit like planting a seed, they will have to care for it, but you can point them in right direction, expose them to new experience and instill strive for knowledge. If you do it right, they will pursue knowledge, whether eventually you hire them or not.

Sometimes it’s as simple as  pointing right materials, sometimes you need to organize workshops and expose them to real life project. But the effort/outcome ratio will be almost always encouraging (depending on your recruiting strategy :)).

When you’re pointing them to right materials remember that it’s not only about concrete books or articles. Show them also most relevant portals, blogs and conferences like, and whatever else you use to keep yourself in  the loop.

If you teach rudimentary concepts like SOLID, it may be prudent to highlight that although in most of the cases it’s good thing to obey SOLID principles in some cases, sometimes you may face situation when it’s justified to break it. In a sense you want them to be open minded, not just blindly following the standard.

It makes sense to commit time and resources to mentor newbies, they will be contributing to  projects more effectively. If you entice them to learn and explore they will bring more knowledge to your team (like the apprentice who outdid the master).

Remember that not only your students learn a lot. Being a mentor shapes also you. I must point out that experience I gained during the time I spent with my students is invaluable. It changed how I look at things, how I prepare presentations and trainings.

Experienced team

Desired state is to have a team that can discuss and agree on architecture changes. Team should be technically mature enough to understand different architectures and designs and be able to apply them in a right place. It’s opposite to a situation where only one person decides on the design. One person deciding on design and architecture is not always bad thing, but it may became a huge problem. Especially if the person in question is an “architect” with 1 year of experience repeated 15 times.

Assuming we have an experienced team do we still need a technical leader? If your team is not only experienced but also keen to follow on things that are not directly relevant to their current projects, then you can probably get away without tech lead. Think about changes like migration to a NoSQL data storage, from a single node to a distributed architecture, on premise to cloud. Will they be able to figure it out by themselves? Or maybe you need a person dedicated to mentor others? This person can be one of the team members. The real question here is, whether a team can self-organize change of this magnitude? Or do they need structure to hold on to?

In this category I also put teams that are seen by management as experienced, but objectively they have 1-2 years of experience repeated multiple times. And I wanted to elaborate on this topic as I found myself in such a team, but this post was a draft for a few months and eventually I changed my mind. Why? In the end the process of changing team like this will be very similar to team of juniors or inters. The only difference is that it will be much more difficult. You will find yourself fighting with established culture. Fighting with culture of mediocrity is even more difficult when the team and management live in denial or delude themselves that culture they maturing is good because it worked for so many years. I won’t give you any tips right now but I may follow up on this in the future (it’s a nice way to say “I don’t know how to do this … yet”).

Leave a Reply

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