How involved should I be as a lead engineer?

Question

Recently our app has been having navigation issues. An engineer picked up the ticket to fix these bugs, and I provided the context and starting point. However, they had trouble with it, so I’m checking out their branch and helping them debug. We just want to make sure it’s not broken as it’s a big change. Is this too in the weeds?

I’m not sure if I should be on top of everything - I don’t think it’s possible. Another instance is an engineer working on coroutine migration. Should I be working on it?

Rahul Pandey · Accepted Answer

You should not be involved in everything. The way you decide what to get involved in is through prioritization, and it’s important that the people you work with are aware of your priorities. As you start to delegate more, one important point is to reduce the cost of failure. There should be a way to detect if something is broken and then pull back. If it’s ok for engineers to try something and fail, you don’t need to become so involved. Ideally you want something where you have a number or go/no go criteria to make it obvious to you and your team when something is ready to ship. This is a sign of eng organizational maturity and it’s worth allocating time for that.

How involved should I be as a lead engineer?

Discussion