[7znwjshsus]

I think it works quite well when they focus on architechture, mentoring, product planning, estimation, cross team communication, code review, devops and small feature/config requests. On slow days they can fix those nasty bugs that have been in the backlog for a while, or on tight deadlines they can help in the parts lagging behind in the important project. But yes I can see how this could be considered "bad" IC, but all that gruntwork is work that doesn't need to distract and slow down your team now.

It's amazing to work with a good team lead like that since you can focus 90% of your working time on getting top priority things done.

What I've seen from the opposite approach is that ICs have a lot of pressure to estimate, plan, document, communicate etc because the managers are too detached from the day to day work. Almost no actual work is getting done because of all the interruptions and endless technical bikeshedding because nobody has either the authority or understanding to call the shots. The ICs compensate for this by working overtime for free.

[solatic]

> I think it works quite well when they focus on architechture, mentoring, product planning, estimation, cross team communication, code review, devops and small feature/config requests. On slow days they can fix those nasty bugs that have been in the backlog for a while, or on tight deadlines they can help in the parts lagging behind in the important project. But yes I can see how this could be considered "bad" IC, but all that gruntwork is work that doesn't need to distract and slow down your team now.

What you're describing is a good manager, period. You can't slot an MBA with no engineering experience into a TL position, to serve as some kind of bureaucrat. When the team's stuck in the weeds, a good leader rolls up their sleeves and helps. It just goes to show what a sorry state the industry is in, that we no longer think of that as intrinsically a leadership skill.