These are all fantastic points and are in the forefront of our minds as we support our Tech Leads in their difficult charter. I'll do my best to explain how we (at Webflow) mitigate such situations and why we find them symptoms of larger issues in our organization. First off, this requires a top-down commitment from leadership and clear expectations on their behalf. It requires us to provide our leads with the tools they need to succeed, hence the guide and the support systems it outlines. We have Engineering Managers at the helm who check in with each lead often and help them juggle their responsibilities. We also make our Product Managers aware of the Tech Lead's role and responsibilities and ask that they speak up if they see these struggles forming.
> The type of "management" they do then becomes more defensive/territorial than directing/guiding.
We do our best to limit defensive/territorial attitudes and have an open debate/decision protocol to iron out disagreements as they arise in a healthy and supportive manner. We encourage such heated, albeit respectful, discussions -- these are bound to happen when you hire talented, passionate folks -- while reinforcing team consensus and a need to work together (no winners/losers). Again, the more our leads see leadership behave in such a way, the more they are empowered to behave likewise.
> always end up doing the business critical or challenging pieces themselves
I admit this is tricky. Success here comes down to practice, which is something a lead learns over time. We have a couple ways to handle this. First, we have our rework/defer/abandon model, which provides some breathing room for deadlines and gives our leads a moment to pause and collect themselves, and gives them time to reconsider how best to delegate/mentor. And second, as most leads tend to be perfectionists and can easily fall into the trap of micromanaging, we discourage "prescriptive" advice in code reviews, such as "doing the work for the reviewee," and encourage outlining outcomes (with some supportive materials) so their team members can tackle the problem autonomously.
With all the above said, really it all boils down to the example leadership sets and how they go about supporting their tech leads. I hope that helps!
(fyi, I'm the article's author)
> The type of "management" they do then becomes more defensive/territorial than directing/guiding.
We do our best to limit defensive/territorial attitudes and have an open debate/decision protocol to iron out disagreements as they arise in a healthy and supportive manner. We encourage such heated, albeit respectful, discussions -- these are bound to happen when you hire talented, passionate folks -- while reinforcing team consensus and a need to work together (no winners/losers). Again, the more our leads see leadership behave in such a way, the more they are empowered to behave likewise.
> always end up doing the business critical or challenging pieces themselves
I admit this is tricky. Success here comes down to practice, which is something a lead learns over time. We have a couple ways to handle this. First, we have our rework/defer/abandon model, which provides some breathing room for deadlines and gives our leads a moment to pause and collect themselves, and gives them time to reconsider how best to delegate/mentor. And second, as most leads tend to be perfectionists and can easily fall into the trap of micromanaging, we discourage "prescriptive" advice in code reviews, such as "doing the work for the reviewee," and encourage outlining outcomes (with some supportive materials) so their team members can tackle the problem autonomously.
With all the above said, really it all boils down to the example leadership sets and how they go about supporting their tech leads. I hope that helps!
(fyi, I'm the article's author)