Levels of Technical Leadership

Benefits of the seamless transition between IC and TL at the senior level

Commonly, ICs are assigned (or organically grow into) TL responsibilities at the Senior and Staff levels. Often, at the beginning there is no associated formal process nor a need to relabel the position. This flexibility ensures that ICs who grow a sense of ownership over a product area are organically recognized as leaders by their team, adjacent teams and engineering managers (EMs). In turn, this yields two different benefits:

• It provides a sense of recognition and purpose to ICs, which contributes to morale.
• It organically staffs local technical leadership for all areas of the product under active development, by ICs who have current knowledge of their area, at no additional cost to the organization.

This seamless transition can perdure for a few years of growth. From my experience, the org culture can be so defined that ICs can be made to enter and also leave the TL role at this level, without incurring a feeling of loss or demotion.

Shortcomings of IC-driven leadership

ICs, by definition, look at situations from a technical and solution-building perspective. The work instruments wielded by an IC are derived from their own skill and their knowledge, but also limited by them.

For example, the ability to acknowledge and advocate that a particular project would be best achieved by hiring new employees with a new/separate set of skills was traditionally seen as out of the scope of responsibilities for ICs.

Moreover, most ICs tend to gravitate towards technical impact; either by increasing depth in one or more areas, or the ability to realize broad technical projects through their direct involvement in the realization. This is incidentally what most organizations reward through promotions.

Meanwhile, a mature organization also needs staff who audits, controls, refines and communicates technical strategy. It also needs technical staff to continuously work to train and educate PMs and other departments in understanding technical constraints to product direction.

While ICs tend to organically grow the skills to fulfill these responsibilities over time, they are often perceived to be a burden, secondary to the primary mission of solving technical problems. The result is that fulfilling these responsibilities through ICs results in sub-par and inadequate technical leadership.

At a certain level of scale, leadership needs to be staffed by individuals who seek and celebrate these responsibilities.

Needs for cross-team and cross-project leadership

The unit of reasoning to organize technical work is the project. The unit of resource to realize technical work is the team. These units are necessary to compartmentalize work and provide a scope to ICs; this is necessary both for morale and for technical progression. Healthy projects and teams need to remain focused in scope.

Therefore, as the business grows, projects and teams become more numerous. The organization then grows a need for staff who coordinates strategy across projects, analyzes risk, develops concurrent alternative plans to de-risk business critical initiatives, and architectures teams to realize complex projects. The need for technical staff to identify patterns across projects and teams and consolidate best practices across entire sub-organizations also grows.

At that scale, ICs cannot any more fulfill these responsibilities, especially across multiple teams while also remaining technical experts in their area and building solutions through their direct involvement.

Oftentimes, a nascent organization can rely exclusively on its Chief Architect and/or their CTO as accountable for these responsibilities; with incidental (albeit informal, and therefore unreliable) support from (senior) staff engineers. As the organization grows, this narrow implementation of leadership quickly becomes unsustainable.

Designated responsibilities as growth incentive

While the organization could hire technical leads with a proven track record and extensive understanding of their leadership responsibilities, it is also beneficial to foster leadership behavior within the existing staff pool.

There are multiple ways to promote leadership internally. The best way, arguably, is to demonstrate by example. A more experienced leader can serve as a role model. However, relying exclusively on role models limits the growth of the organization to the behaviors exemplified by the current most senior staff.

Therefore, it is also useful to identify and name the skills and responsibilities that are known to be necessary to the organization. This can be achieved by reflecting on the current unanswered needs of the organization or sourcing them from other organizations.

Explicitly naming these skills and responsibilities provides three separate benefits:

• It enables staff to develop curiosity and interest for leadership roles.
• It enables staff and management to develop internal career growth plans towards leadership roles.
• It ensures that due attention is given to all aspects of technical leadership, and not just those that happen to be exemplified by current staff.

Unfortunately, these paths to promotion are often not well expressed in the more “basic” career ladders that are adopted at the beginning of an organization’s history. ICs may not even realize they have an interest for these paths, for lack of clear identification.

Leadership behaviors in excess of IC expectations

As an organization grows and the complexity of projects grows, it is just natural that an increasing large contingent of IC staff starts displaying “additional responsibility taking” behaviors that are not aligned with traditional management’s expectations for the IC role. Here are some examples:

• a staff member who is designing staffing plans for multiple teams to support technical initiatives, supplementing/complementing the EM role.
• a staff member who is routinely educating product managers to safeguard alignment between product strategy and technical capabilities.
• a staff member who is seeding technical design drafts for multiple teams concurrently without actually driving the design to completion nor its realization.
• a staff member who circles back and forth between TLs from separate teams to maintain cohesion in their technical approaches.

These behaviors come at the expense of direct technical impact; there is simply not enough time in a work week to push these behaviors to a fruitful outcome and also focus on direct technical impact. From that perspective only, these behaviors are detrimental to recognition and progression on a regular IC career track.

Meanwhile, obviously such an organization does rely on these behaviors, increasingly over time. They are beneficial to the organization and thus should not be disincentivized either.

Designated responsibilities to recognize growth

When an organization lacks a framework to acknowledge and promote technical leadership behaviors, especially at the more advanced levels, staff members who exemplify them have to navigate a faustian trade-off:

• Either they need to stack up hours to achieve both their IC ambitions and fulfill these leadership responsibilities, resulting in poor work-life balance; or
• They need to negotiate promotions with a friendly manager outside of the standard framework recognized by the organization, which is fraught with peril: the manager may not be friendly, and the staff members have no framework to rely on as recourse when political considerations thwart promotions.

This is where designated, explicit leadership responsibilities have additional benefits:

• They enable staff to deliberately make trade-offs in how they allocate their time, with confidence of alignment between their behavior and the needs of the business.
• They enable staff to point to identified evaluation criteria and argue objectively with management when supporting their case for employment promotion.