One of my projects this year is a training program for developing Tech Leads. In preparation for the course, I developed this diagram below to explain what areas we focus on and found the model resonated very well with people who interact with Tech Leads, but probably don’t really know what Tech Leads do. I also found it has been a useful model discussing it with new or current Tech Leads about areas of potential growth. This model explains the Tech Lead role as intersection of three other roles – A Developer, a Leader and an Architect.
A Tech Lead is developer who is a Leader
A Tech Lead wouldn’t be the same without being technical and there are a whole bunch of development skills I would expect any capable Tech Lead of having. In today’s age of agile development practices, there are a whole set of engineering practices, I would expect Tech Leads capable of doing such as refactoring and Behaviour/Test-Driven Development.
What makes a Tech Lead different from developers is their breadth and depth using leadership skills to help the team move towards a goal. Unlike developers who can avoid giving feedback to their peers, a leader must be able to give and receive feedback to help people develop and be more effective. This means not only focusing on the technical aspects, but also the team and people aspects such as relationship building, motivating, delegating, and influencing.
Tech Leads must work to resolve conflict. Conflict itself is a sign of a healthy team, but only when the Tech Lead creates an environment where conflict is resolved.
Developing skills in the Leader role
Developers have little opportunity to practise leadership skills. Tech Leads are fortunate to have many resources that address the leadership circle. Leadership skills are important to all leaders regardless of industry or position and you can find a plethora of books, training courses and websites.
A Tech Lead is hands-on Architect
I have written in the past that I expect effective Tech Leads and Architects to have some level of coding ability. I have even gone so far to suggest they should ideally spend a minimum of 30% of their time in the code.
Developers spend much of their time in the code, but unless they start thinking of the bigger picture, it is difficult for them to start thinking beyond that. Tech Leads must help the team to:
Build systems, not software
This mindset shift helps developers think about a lot more than just the software – to start thinking of the quality attributes of software systems (or the Cross-Functional/Non-Functional Requirements) as well as the whole interaction with the deployment environment in which the software lives.
When someone plays the Architect role, they are naturally taking a broader view of the software – how long it’s going to last for and how it is going to evolve over time.
Developing skills in the Architect role
The Software Architect role is much newer compared to general leadership and although there are some resources available, I cannot recommend many of them because they either focus on the tooling, or they teach little that help people bridge the gap.
Although people are writing books, articles and training courses that address this circle of skills, more still needs to be done.
What I’m doing about it
Most training courses that exist focus on a single tool, a single approach but rarely focus on a broad view that also gives developers a better understanding of the Tech Lead, particularly the Architect side to the role. I have run a hands-on course for Tech Leads that helps people build more awareness and gives people and opportunity to practice some of the skills outlined in the model above.
Although we touch about some of the skills in the “Leader” role, I focus the contents more on the “Architect” role because there are fewer resources available. If you’re interested in this course, please get in touch and I plan on writing another blog entry detailing what we cover.
If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.
The streak of great posts continues. I really feel I get to realize something reading this stuff, thanks!
Hello, Patrick. Thanks for interesting post and circles of TL responsibility! It’s now like roadmap for me. Please, write more about your TL course.
Interesting thoughts Pat. In your diagram, there are no skillsets that are mapped to the intersection of three circles representing Dev, Arch and Leader. That would have been more insightful, given that the line separating a (good)Architect and a (capable)Senior Developer is especially a difficult one to draw.
So writing code, test cases are definitely in the intersection of the three roles, but what differentiates an Architect from a Tech lead for example. In many organizations, Architects are not expected to manage people, conflicts etc. though any coding, agile architect would find himself in the middle of those situations sooner or later…
Thanks for the helpful diagram, Pat!
What I am missing, though, are aspects/tasks representing a clear understanding for quality. What I would like to see from a Tech Lead is the genuine urge and capability to deliver useful software/systems rather than just playing around with the latest s***. Therefore he needs to help the team to understand what distinguishes working, good software from half-done, poor software; e.g. establishing a problem-oriented and customer-focused approach with a clearly defined and set of non-functional requirements the development complies with …