This document describes why and how a tech company can offer a career path to its engineering technical leaders, that is, different tracks for “deep ICs” versus “broad ICs”.
To motivate this evolution, we identify two separate pressure points: from the business, to grow an increasingly skilled and mature technical leadership organization. Then also from engineers, to acknowledge a growing misalignment between their effective leadership responsibilities and their nominal responsibilities on the IC career track.
To release this pressure, this document identifies technical leadership as its own distinct organizational role. It has its own gradient of skills, responsibilities and organizational impact, starting as a partial overlap with the individual contributor (IC) role at the senior level and forking into its own career progression beyond that point.
Considerations about employee compensation are left out of scope here and deferred to a separate discussion.
A young tech company with large ambitions requires strong and adaptive technical leadership. As the complexity of projects grows, so does the amount and quality of the technical leadership.
It is customary for a starting business to grow technical leadership organically, “on-demand”, by adding and removing TL responsibilities from ICs at the senior level.
While adequate to maintain high levels of technical quality on individual projects, the focus of ICs remains to solve problems and build products; leadership generally remains a secondary concern. To incentivize further leadership involvement, it is customary to promote a career ladder where individual contributors (ICs) above the senior level are invited to work on “multi-system projects”, develop “organizational awareness”, think about “long-term technical strategy” and shape “direction and future of entire products”.
As we will discuss below, this IC-centered vision of technical leadership does not properly incentivize the actual leadership responsibilities needed by a growing technical organization. Additionally, it does not properly acknowledge the tasks and responsibilities taken up by employees who fulfill the existing leadership needs of the organization. In short, an IC-center technical ladder, as is commonly set up in starting organizations, is inadequate to support a growing business’ needs for technical leadership and the career goals of certain employees.
However, we cannot argue either that a IC career ladder is a defective approach altogether. Commonly, the “Staff” and later career levels reflect the growth of ICs into technical depth and impact, which any organization also needs to foster. An attempt to stretch a single IC career ladder to accommodate both the org’s needs for technical depth and organizational leadership would likely fail to achieve either.
This is why should identify and describe a distinct set of technical leadership roles and identify its responsibilities.
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.
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.
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.
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.
The previous section identifies the need to evolve technical leadership for the organization’s benefit. It so happens that another need exists for the benefit of current and future employees: to acknowledge and reward actual leadership behavior in excess of the skills & responsibilities identified on the IC career track.
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.
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.
To address these organizational needs, the table linked below complements an existing IC career ladder with a technical leadership career ladder with a similar structure, and a large overlap at levels Senior/Staff for the reasons identified above.
We’re also assuming here that the IC ladder has levels beyond T5/T6, to promote a further evolution in technical depth and execution skills. In comparison, this technical leadership ladder promotes technical breath and organizational impact. They fork at level T6/L6 and evolve in parallel from there.
(If local cultural expectations require the “Director” word for roles that direct staff, even indirectly, consider using “Director of Technology” instead of “Tech Lead” in your implementation of the ladder, as a non-management title, to separate it from “Director of Engineering” for managers.)
To introduce such a ladder to an existing organization, it is useful to communicate to all engineering staff that the role expectations at level Senior and Staff are very close to those expected on the TL ladder at that level. The new ladder thus continues the opportunity to switch from one ladder to the other without prejudice, should an IC desire to do so.
Additionally, the existing leadership should consider relabeling the roles of the staff who was already carrying the duties of the more advanced levels of the leadership ladder, as a way to acknowledge and clarify the responsibilities they had already taken.
So what do you think? Did I miss something? Is any part unclear? Leave your comments below.