Berlin

November 4 & 5, 2024

New York

September 4 & 5, 2024

Creating technical leadership in context

This talk will cover how Joy and Nathan overcame challenges at Plaid through the creation of a technical leadership structure parallel to management.

Speakers: Joy Zheng  &  Nathan Tindall

Register or log in to access this video

Create an account to access our free engineering leadership content, free online events and to receive our weekly email newsletter. We will also keep you up to date with LeadDev events.

Register with google

We have linked your account and just need a few more details to complete your registration:

Terms and conditions

 

 

Enter your email address to reset your password.

 

A link has been emailed to you - check your inbox.



Don't have an account? Click here to register
October 04, 2024

It seems like every engineering team reaches a tipping point where bottoms-up technical steering where everyone “just knows who to talk to” no longer scales.

It becomes increasingly difficult to maintain shared mental models for how systems operate and should evolve over time. As a result, technical debt accumulates that no one feels empowered to take on, and cross-cutting initiatives stall without centralized strategy, accountability, and clear decision-makers, especially due to the historically flat nature of the org. Resolving technical disagreements often relies on either organizationally empowered EMs (violating our principle that technical leadership should come from ICs) or the accumulated social capital of the proposers (a non-inclusive system), rather than folks who are clearly empowered and accountable for making decisions.

This talk will cover how we overcame these challenges at Plaid through the creation of a technical leadership structure parallel to management. Since 2020, we have had a few iterations of our program. The first attempted to empower ICs by carving out time and accountability for engineers to focus on technical excellence, separate from a lot of day-to-day work on their teams. Based on learnings from this first iteration, we set up later iterations to better align with team structures and responsibilities.

We will discuss our learnings from these iterations and why we settled on our current approach. This includes our strategies for advocating for this type of program, what type of buy-in we needed from engineering management in order to make it happen, and how we knew that we had finally reached the tipping point that warranted a larger change. In our experience, creating a successful program is highly dependent on specific properties of your organization, so we will also share the specific attributes of Plaid that informed our choices, and how this might vary at other companies.