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!)