At Uber, we have Product Managers, who define priorities, strategy, and the "what" to build. Engineering managers and engineers decide on the "how" and manage

At Uber, we have Product Managers, who define priorities, strategy, and the "what" to build. Engineering managers and engineers decide on the "how" and manage their projects. Some EMs run the projects themselves, some PMs do the same. I've found that delegating this responsiblity - and setting up clear expectations - really helps engineers on my team grow, stay motivated and become leaders. Engineers who lead projects also often get promoted faster than those who don't and just become much better rounded than those who have the mentality of "That's not my job. Why should I manage any project?" We have Technical Project Managers - TPMs - who manage massive projects. Think 5-10 teams, 50+ engineers, 3+ locations/timezones. The type of projects that take more than an hour per day to keep in sync with. The ratio of TPMs is around 1:50 for engineers. This is similar to all highly autonomous tech companies work - Google, Facebook, PAULS (Pinterest, Airbnb, Uber, Lyft, Slack) as far as I know. For small projects that engineers can manage just as good, why add an extra layer? Also, often project management decisions and arcitecture decisions are often connected (clean architecture, clean boundaries means less cross-team project management). Engineers managing the projects means a push for cleaner architecture. Having full-time project managers might mean working across messy architectures, project managers picking up the additional work that unclear boundaries mean. So for every 100 engineers at fast-moving companies like Facebook, Google, Uber, you'd have about 10 EMs, 10PMs and 2 TPMs. That's it!