Before you abandon this article, be honest with yourself and answer these few questions:
Then…Congratulations, you are a technical leader! This article is for you, read on!
Joking aside, technical leadership is often seen as the ability to supervise a team of technical experts while making decisions related to engineering and software development. From this kind of profile we are expecting to have a mix of some of these skills (it could be other ones related):
Technical Skills:
Management Skills:
However, Technical Leadership can manifest in many different ways (especially within Codurance), without the formal ‘lead’ title. For example, some of the initiatives that a technical lead can implement, could be:
It is important to note that technical leadership does not necessarily mean knowing “everything there is to know about technology”. It is important to ask questions and of course learn from your colleagues things you don’t know.
From our perspective we think this role is important because it is the person between project management & having technical discussions with the team and also is the touch point between other engineering teams (in a nutshell).
As a tech lead, colleagues are expected from you things like; foster a collaborative environment and inspire the team to work towards the same goal. That’s one of the most important things a “leader” does, not just tech lead or having all the technical knowledge in the industry.
Tech leads are (potentially) responsible for mentoring other members on the development team, making key decisions about technical stuff (architecture, frameworks, technologies, etc…) , taking the ownership on relevant tech aspects and more.
As well as being responsible for making key decisions, they also have the authority to arbitrate across the team.
Individuals who believe their talents can be developed (through hard work, good strategies, and input from others) have a growth mindset. They tend to achieve more than those with a more fixed mindset (those who believe their talents are innate gifts).
Maker to Multiplier
Note: do not confuse growth mindset with being promoted without having all the features that we mentioned above.
The ‘Peter Principle’ is a concept in management developed by Laurence J. Peter, in which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.
Having defined what technical leadership means, let’s now explore technical leadership in more detail, starting with various patterns that technical leadership can take. Based on our joint experience, we have seen technical leadership manifest in different shapes. For example, certain individuals have a passion for knowledge sharing and teaching others. This itself can take a whole host of forms such as writing a blog, forming a book club, speaking at a conference or facilitating a Community of Practice across teams. All of these things enable that person to multiply their impact across many others. Taking ownership in this way is a form of leadership, albeit perhaps without the leadership “tag” or “title”.
A former colleague of mine, Dan Abel came up with the “Butterfly Model” of technical leadership.
This model speaks to the fact that when playing the role of technical lead for an engineering team, there are a number of concerns that you need to be aware of and therefore a range of activities you will need to undertake across your time in the role. Dan categorises these under four areas:
Engaging with Business - Facing outwards from your specific team and engaging with the other teams across the wider business, from both technical and non-technical roles.
Engaging with Team - An inwards focus towards your specific team. Working to build and nurture the individuals and the team as a whole. Acting as a role model for them to follow.
Delivery and Risk - Taking ownership of technical risks and technical debt. Contributing to a plan the team can deliver on.
Architecture and Infrastructure - Working with your specific team, championing something good enough; focusing on the technical dimensions.
When starting a career in software development, it can be very easy to assume that in order to be a leader of a team, you need to be the most skilled software developer within that team. However, many of the best technical leaders we have seen between us across our careers have not necessarily fallen into this category. Dan Abel’s model alludes to the fact that to become a good technical leader is to become good at a mix of different skills, some of which are not directly technical in nature. This is perhaps a nice segway into another model of technical leadership, which in many ways compliments the Butterfly Model and that is Servant Leadership.
To be a servant leader is to focus on serving the needs of the team and it’s members, above your own personal interests or goals. This approach has a strong emphasis on skills such as listening, empathy, and a commitment to the personal and professional development of others.
To put this into the context of technical leadership might mean for example forgoing working on some more interesting aspects of a project to ensure that other more critical areas are given attention. Typically this might mean the technical lead of a project is less “hands on” writing software code and instead spending more time meeting with stakeholders outside of the team to ensure alignment or remove potential blockers. In doing so, the technical lead is creating an environment where the rest of the team can flourish and be more effective.
Often in complex software development teams there can simply be too much for a single technical lead. Projects such as these often have characteristics such as a number of complex integrations to external systems, complicated business processes that need to be modelled in software or a degree of coupling with several other teams. In situations such as this, it can be useful to compliment a team’s technical lead with one or more feature lead roles.
As the name suggests, a feature lead takes ownership of a single, specific area of the project. Often this can be a business feature but also be taking ownership of a system integration of business processes. The feature lead takes on some of the activities the team’s technical lead would be required to do, but just for the specific are identified. This might include handling and escalating blockers, ensuring the entire team has clarity on the work to be done in that area, working with a business analyst to ensure a backlog of User Stories is captured for the work to be done. It is important to note that a feature lead is not expected to solely deliver the work for their allotted area. The work is still driven through the entire development team as usual.
The feature lead model can be a good mechanism for introducing individuals to technical leadership of a software development team, without having to take on all of the tasks a formal technical lead for a team will do. The feature lead will still consult regularly with the technical lead and it will be the technical lead that ultimately still owns the technical vision for the team.
Formally, within Codurance technical leadership has 3 main profiles:
As well as these three formal roles, there are also other areas within Codurance where technical leadership occurs frequently. For example, people running events, such as; a Community of Practice, book club, Lunch & Learn, etc. Codurance also has a strong connection to the wider community and many of our people speak at external conferences or deliver workshops. None of these activities require a formal “leadership” title per-se, but they are nonetheless examples of technical leadership.
How do we embrace these patterns in Codurance?
In the same way the Butterfly model references a technical lead as being a well-rounded profile that has all skills across a number of areas (Engaging with Business, Engaging with Team, Delivery and Risk and Architecture and Infrastructure), at Codurance our formal Technical Lead roles also demand skills in multiple disciplines. As a result, we view people with skills profile as being a highly experienced Codurancer that can run a full project and/or portfolio with trust and reliability.
Secondly, Servant leadership is something we consider “mandatory” in a Codurancer that wants to be seen as a leader; caring for your team, removing barriers and setting aside your own personal interests in favour of the wider team (where need be).
Lastly but not least is the concept of a Feature Lead. This model is one of the most important in order to start in a leadership role or “leadership behaviour” even if you are leading a very small and precise piece of work, you are taking ownership of that. All of your colleagues (whether they be technical or not) as a result will view you as the leader of that component. This can be helpful in building confidence in yourself as a technical leader, without necessarily taking on the full formal title as technical lead for a team. Within Codurance, this is one of the ways of working that we embrace regularly as a way of fostering technical leadership as part of a Codurance person’s career progression.
This article has described a couple of different models of technical leadership such as the Butterfly Model. It is important to note though that there is no one “right” way to be a technical leader. The models discussed here should be used rather as a reference and inspiration for shaping your own technical leadership style. As stated at the beginning of this article, technical leadership can take many forms - all equally valid. Different contexts will likely often also require slightly different technical leadership styles. For example a more junior software development team will likely benefit from having a far more “hands on” technical leader that is able to Pair Program with developers on the team and establish good patterns and practices in the codebase. Whereas, a more experienced team might benefit more from a technical leader spending less of their time coding and more time ensuring the developers can be effective.
We have also shared how we approach technical leadership at Codurance while working with our clients.
