leonardsouza

Funny what we had to endure before the age of the touchscreen. The buttons were always so mushy, too. I do miss the tactile feel, though.

If Cthulhu approves then my work here is done ;)

Well, we do employ "true" managers (if by true you mean "people" managers), too. There are two types of managers in our org: people managers and technical managers. Tech Leads are the interface between product and engineering. Engineering Managers are the interface between Engineers and Webflow/life/career/support/advocacy. Tech leads do have to possess some people skills, too, but their technical expertise makes them key for playing that role and for setting expectations. That said, they can improve their people managements skills as well, which gives them a glimpse into if they might enjoy moving into Engineering Management.

> How do you deal with the fact that most developers do not like management?

The role is completely optional. It's a "hat" that our engineers pass around when someone wants to improve in that area or wants to create momentum in something they believe in. Once a project is over, the Lead can simply take the hat off if they do so choose. It's our job to make the role so enticing that they _want_ to pursue it. That's tricky, but that's why we write these kinds of guides. :)

> Have you ever had a Tech Lead who didn't want to actually manage other devs, but just liked having extra authority and access to stakeholders?

We've normalized the Engineering, Tech Lead, and Engineering Manager hierarchy. Each have specific roles and responsibilities, but they are all considered the same level, and have relatively the same access to stakeholders and possess the same authority in their respective domains. We want someone to take on the Tech Lead role because _they_ want to, not because it's a power grab.

> What do you do, then?

If that were to happen, however, we'd likely encourage the behaviors we wished to see by also demonstrating those behaviors ourselves. We try and remove the "power" incentive from the equation, and instead reward the role for being a force multiplier. This is a trick I picked up from some of the amazing managers at NoRedInk. (thanks Josh Leven!)

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)

Hey @bargl-

I'm the author of that article and I couldn't agree with your summary more.

"The basic premise is how do you as a manager give your team 10x time to actually work, focus on work, and enjoy life."

Thanks for sharing that!

(Also, apologies for the click-baity, terrible title, lol. I tried to make light of it in the article.)

Hey, yladiz!

I'm the tech lead on IX2. Are you using Safari by chance? The part after WORLD WIDE WEB is a known issue and we are working on it, but it works smoothly in Chrome (if you could give it a try). We are also looking at how we can best cull off-screen animations to minimize CPU usage. Thank you for the great feedback!

Best, Leonard

Nice!