Technical Leadership Progression, part 2
In Technical Leadership, part 1, we talked about how someone grows into a technical leader aware of their team. In this post, we’ll continue on to describing a Tech Lead who takes ownership of their teams’ success, and then moves into the higher levels.
First, though, a quick reminder of the process as a whole. People in general move from self up to the enterprise, and from awareness to ownership at each of those levels:
Last time, we talked in detail about the Self Awareness, Self Ownership, and Single Team & System Awareness stages. Onward!
Single Team & System -> Ownership
If people find they enjoy being the go-to problem solver for the team, the next step in technical leadership is advocating for the team – taking on some measure of ownership and responsibility for it. This means speaking for (and potentially fighting for) the team, and it means being stubborn on their behalf. It also means fighting for the health of the system(s) the team takes care of.
There’s more strategy and direction-setting here, with focus on deliberate improvement. These are things like:
- setting and explaining the team’s technology direction
- improving processes and architecture to lessen existing team pain
- encouraging a team culture that appreciates improvement, innovation, and customer service
This role requires strategic thinking, amazing communication skills, and influence – vision is always a hard sell, but it’s an especially hard sell in organizations with a massive backlog of projects to complete, or in organizations where someone outside of IT drives project priority. Because vision is a hard sell, and because “but why you clean up tech debt?” is something most everyone in IT has heard, a technical leader has to represent and sell the system and the people who work on it.
One important thing to keep in mind, if there’s friction with the other leadership of the team (project managers, HR managers, other technical leaders), it will become vital to resolve here – no one wants to fight for a team or a system while also fighting for the right to do so.
Depending on the size of the organization, the Multi-Team/Multi-System sections and the Enterprise sections could overlap. These descriptions assume an organization large enough that “multiple teams” is not the same thing as “the entire enterprise.”
Multi-Team/Multi-System -> Awareness
This is very much like the Single Team Awareness, except…well, across multiple teams or systems. Someone becomes known for understanding That Esoteric Nerd Thing, so much so that people from outside of their team start to ask for help and debugging.
One option is to just answer those questions and send people on their way – but another is to take the opportunity to learn about those teams’ personalities and their systems and help them find the best solution. Technical leadership in this stage requires learning to communicate with even more people and being okay with even more interruptions that pull away from shhh, just let me code stuff.
Multi-Team/Multi-System -> Ownership
Again, this is very much like ownership of a single team/system – multiplied by however many teams. It’s a shift back to strategically improving and proactively solving architecture/process/culture problems – but this time, taking into account the perspectives and needs of multiple teams/systems.
This tends to be a logical grouping of teams, typically teams that report to or through the same management chain or teams that work on roughly the same thing. This kind of work requires a lot of focus, attention, and time – and to be successful in this role, working with each team as often as possible is hugely important.
Also similar to Single Team Ownership, building relationship and understanding with other members of leadership is vital here – multiplied by each team.
Enterprise -> Awareness
If the organization is big enough that there’s a distinction between multi-team and enterprise, zooming out enough to see the enterprise as a whole comes next. This level is less about helping people than Single Team and Multi-Team Awareness, and more about learning and understanding – the business drivers, how IT fits into those business drivers, where the inherent friction is between those two things (spoiler alert: there’s always some), and what can and should be done to remove that friction for maximum efficiency. Many people stop here, too. This requires seeing and understanding a lot of politics, and sometimes…it’s just better not to know.
Enterprise -> Ownership
This is coordinating improvements or implementing new things across the enterprise. It’s also advocating on behalf of IT as a whole or the company as a whole if those thing are separate. This type of role tends to include researching, understanding, driving, and teaching how to implement initiatives that could affect everyone using a particular technology stack or process.
It requires a massive amount of influence, communication, coordination, understanding – and determination. It also requires a strong community as support, because this is probably the most frustrating version of technical leadership – the politics that are seen and understood at Enterprise Awareness now must be navigated. For the people who love fighting on behalf of people and systems, though, this is the most rewarding type of technical leadership.
Why you tell me this neat pattern?
Our technical backgrounds are primarily and most recently as IT Architects. This included a lot of mentorship, and this progression came up for everyone (including us! We are our own favorite guinea pigs!) as they went from developer -> tech lead -> architect -> senior/enterprise architect. There are new struggles and new things to learn at each stage, and it can be really helpful to know that that’s completely normal and that everyone goes through it.
There are also important skills that are required (like that people patience thing) and occasionally people just say thanks but no thanks. So, in addition to giving people who are interested in technical leadership words for their struggles and some chill that those struggles are normal, it also helps give them a rough idea of what their career could look like and what they should expect.