5 Things I Stopped Doing as a Lead

I led a small engineering team for two years. We shipped on time, the code was clean, and the standups were short. By every metric I cared about, the team looked fine. Then three of my best engineers quit within a month. None of them had a single conversation with me before they handed in their notice.

The exit interviews told me what I should have seen earlier. They were not burned out by the work. They were burned out by the way I gave it to them.

I spent the next six months rebuilding how I delegated. I read four books on engineering management. I ran a one-on-one feedback survey every Friday for twelve weeks. I shipped a working team again, and the difference was not subtle.

Here are the five delegation habits I had to kill. If you are a tech lead and any of these feel familiar, the exit interview pattern will too.

1. I stopped assigning tasks. I started handing over problems.

This sounds like a tiny wording change. It was the biggest one.

For years, I would say things like “build the rate limiter” or “fix the slow query in the orders table.” The task was clear, the scope was clear, and I could verify the result in a code review. It felt efficient.

The problem: the person doing the work never owned the why. They owned the deliverable. When the requirements shifted three weeks in (they always do), they had to come back to me for every decision. I became the bottleneck for context I already had in my head.

I switched to “our checkout latency is 2.3 seconds and the business wants it under 800ms. Here is the dashboard, here is the budget, here is the deadline. The implementation is yours.” The first time I tried this, the engineer picked a different approach than I would have. I almost jumped in. I let it ship. It was 12% faster than my plan would have been, and the engineer told me later it was the first time she had felt like she was doing engineering, not typing.

The rule I now follow: if I can write the implementation plan in the task description, the task is too small to delegate as-is. Hand over the problem, not the steps.

2. I stopped doing the easy work and saving them the hard work.

This is the one I am most embarrassed about, in retrospect.

I used to take the gnarly, ambiguous tasks for myself. “I will handle the on-call rotation, the database migration, the architecture decision.” I left the team with the work that had clear specs and obvious progress: write the API endpoint, fix the linting errors, update the test fixtures.

It felt generous. It was actually hoarding. The hard work is where engineers learn. The easy work is where they get bored.

I had a conversation with a senior engineer who had been on the team for eighteen months. She told me, gently, that she had not grown in a year. She had shipped plenty. She had learned nothing. The reason was that the work that taught her anything was landing on my desk, and the work that was left was the work I already knew how to do.

I flipped the policy. I now take the work that nobody else wants to learn from (the cross-team meeting, the vendor evaluation, the on-call triage that is mostly paging people) and give my engineers the architecture calls, the production incidents, the customer escalation work. It is messier. They sometimes get it wrong. They get better faster.

3. I stopped reviewing every line. I started reviewing the decisions.

Code review was where my worst habit lived.

I had a reputation for “thorough” reviews. My comments were specific. I caught real bugs. I also rewrote people’s code, line by line, in the name of consistency. It was the kind of review that makes engineers stop trusting their own judgment. They would submit a PR and wait to be told what was wrong with it.

I switched to reviewing the decisions and the interfaces, not the implementation. “Why did you pick a debounce here instead of a throttle?” “What happens if this service is down for 30 seconds?” “Walk me through the failure mode at 100x current load.” Those questions are about engineering judgment, not about whether to use a map or a for loop.

The result was a bit of chaos at first. Some PRs landed with code I would have written differently. A couple had bugs that a line-by-line review would have caught. But the engineers started owning the code, and the review meetings turned into design conversations instead of proofreading sessions.

4. I stopped giving feedback once a quarter. I started giving it on Tuesday.

Quarterly reviews are a trap. I know this is a popular opinion. I ran them for two years anyway because they are what every management book recommends.

The problem: feedback in a quarterly review is always about something that happened two months ago. The engineer cannot remember the specific context. They hear “your estimation was off” but they no longer remember which ticket, which conversation, which assumption was wrong. The feedback lands as a judgment, not a course correction.

I moved most feedback into the natural moment. A one-on-one on Tuesday. A five-minute conversation after a standup. A Slack message the same day: “the way you handled that customer escalation yesterday was the kind of senior move I want to see more of.” Specific, immediate, and tied to a moment the engineer can still remember.

Quarterly reviews are still on the calendar. They are now mostly about career direction, not performance. Performance feedback lives in the work, on Tuesday.

5. I stopped hiding my own failures.

The last habit I had to kill was the one I did not even realize I had.

I used to talk about my engineering work in the past tense, like a finished product. “Here is how the system is designed.” “Here is what we built.” I almost never talked about what I had gotten wrong, what I had been unsure about, what I had changed my mind on.

A junior engineer told me, after one of my “here is the architecture” talks, that it sounded like I had it all figured out from day one. She said it made her feel like she was the only one in the room who was confused. She was not the only one. I just had not said so out loud.

I now start every architecture review with the part I am still uncertain about. “I do not know if this is the right call. Here is what I am worried about. Tell me where I am wrong.” The first time I did this, three engineers who had been quiet for months brought up real concerns I had missed. The architecture got better, and the team started talking like collaborators instead of contractors.

The pattern I missed

When I look at these five habits, they all have the same shape. They are all ways I had quietly taken ownership of the team’s work and left the team with the appearance of ownership. The tasks were clear. The PRs got reviewed. The standups ran on time. From the outside, the team was operating.

From the inside, the team was waiting for instructions. The exit interviews did not say “the work was too hard.” They said “I never felt like the work was mine.” That is the failure I had to learn to see, and it is the failure I now watch for in other leads I mentor.

If you are a lead and your team is shipping on time but you are the one with the most context on every decision, the work is not delegated. It is allocated. The difference matters more than any framework I have read.

Delegation is not a thing I learned once. It is a habit I keep catching myself getting wrong. The day I stop catching it is probably the day I should step out of the role.