Learning how to delegate when transitioning from tech lead to manager.

Problem

I joined Lyft starting as an IC on a growth team. Growth teams like ours are focused on experimentation, and ours in particular was leading the charge for product groups in proving everything through A/B tests. I quickly showed my seniority with deep technical knowledge and became tech lead. I wanted to transition to the manager role and had that opportunity given my startup experience, but I was still writing code for many experiments end-to-end, as well as setting up the Leanplum experiment variables and targeting configuration. My direct reports were writing code but were constantly feeling blocked because they didn't feel comfortable making decisions about product details or experiment variables. They would feel blocked and not move as quickly if I was not directly with them monitoring their code and experiment setups.

Actions taken

I had to delegate more of these tasks: coding, product detail decisions, and experiment setup and analysis. I had to learn to let go and encourage them to set up experiments on their own and run them even if I was in meetings. I trained them in how to think about product decisions, and that decisions can be reversible, especially in experiments, so that they have the freedom to make mistakes. This encouraged them to not wait for me or my PM to tell them exactly what to do or precisely what experiment to run. In part, I had to grow comfortable allowing some of these earlier experiments to fail because they were set up improperly. On their side, I had to instill confidence in them that they would not be punished in any way for setting up an experiment wrong or making a suboptimal product decision. I told them that the most important task is learning, and failure is a totally fine way to do that. Frequent, gentle, quick-turnaround feedback was key. Once they grew comfortable with this, then practiced and got my feedback, they made fewer mistakes and were able to run twice as many experiments by the next quarter. Other teams where a PM was a blocking part of the process moved more slowly and had fewer simultaneous projects going on. Although the engineers were junior, they quickly gained some of the skills of senior engineers to project manage their own tasks, make some product decisions, and analyze the results of their own experiments. This freed my time up to take on more reports, report results, and think about all of their careers more.

Lessons learned

I created a safe space for failure, and allowed my team to move a little bit slower toward our OKRs in the first quarter while they were practicing doing things entirely on their own, in order to gain a massive impact in efficiency and career development later.