Let’s have no managers, instead of managers with no engineering experience

> Or maybe we need to start recognizing that engineering management is a thing that has value, requires training, and is distinct from being an engineer with a strong personality.

I'd say that's the real "just ignore the cycle of failure in the industry and keep writing the same stale think pieces" approach. We've had decades of talking about how vital good management is and how better training for management is a great idea, and to what avail?

> It's telling to me that rather than elevate the role you're more inclined to destroy it.

What it should tell you is that in my experience, steps in the direction of destroying the role have resulted in better outcomes, whereas steps in the direction of elevating the role haven't.

> I've described, with the most pessimistic lens, 2 layers of management to the top of your company, with a focus on team collaboration. Having managers with strong engineering experience and technical sympathy decreases the depth of your organization, it doesn't increase it.

I was thinking about technically-vertical rather than organizationally-vertical. Cases where the implementation of a single customer-facing feature - the response to a single customer request - is handled by components that are the responsibilities of several different teams with their own management. That's how you'd end up needing to coordinate roadmaps between different teams, and I see that as indicating poor structuring of responsibilities, usually a result of a team taking exclusive control of an area that should be shared, which is usually a management phenomenon. You want to be in a position where whichever team needs a piece of functionality for a given feature that's their responsibility can simply implement it, whichever layer of the technical stack it resides in - where the only responsibilities that could belong to other teams are product-feature level responsibilities, not technical-area responsibilities.

> But as an example of planning, imagine a platform team runs a flight of APIs. There are multiple clients to these APIs all shipping products. Each has their own feature needs. If those teams collaborate on dependencies and optimize around what they need, everyone gets what they need faster. Not coordinating or planning provides a random outcome in a space dominated by sub-optimal outcomes.

It's an appealing thought, but it just doesn't match my experience of how it works out in practice. The best outcome is often one that isn't imagined - is barely imaginable - until it emerges from the technical constraints (a la http://wiki.c2.com/?WhatIsAnAdvancer ). Letting API feature implementation happen just in time under the person who has a direct use case for that feature raises both the ceiling and the floor on the implementation quality: they're working under the best conditions for inspired insight to happen, and the fact that they're using the feature means their implementation will at least work and fulfil at least one use case, and then the second user of the feature can expand it to suit their use case while keeping the existing use case working (people say that you'll get stuck in a local optimum that fits the first use case but can't possibly be adapted to the second, but I just haven't seen that happen in practice; code that was written for a single use case inherently tends to be simple and malleable). The absolute worst case is that the API ends up with two parallel but different implementations of the same feature to fit two different use cases, which is non-ideal but not actually all that bad in the grand scheme of things.

Whereas planning and coordinating via management as I've seen it practiced just goes wrong too badly, too often. You agree on an approach that everyone who comes to actually use the API agrees is wrong, but no-one wants to revisit the decisionmaking process. Or one manager brings a particular API under their control to expand their own importance, and prioritizes their own needs - or worse, deprioritizes work on it because they're not actually using that API for anything important but won't allow others to improve it. Or it emerges that what was initially assumed to be a single common feature actually has use cases that are so different that they should be implemented separately, but any team that proposed to fork off their own variant would be assumed to be empire-building (or, equally and oppositely, would be given insufficient support in their work), so everyone keeps muddling through with an awkward compromise.

> This entire discussion is predicated on the notion that your managers are technical professionals facilitating this. It's weird how many people refuse to accept the idea that people can exist

I don't think good technical architects/technical planners exist - I've just never encountered anyone who was able to produce better results by making technical decisions ahead of time (across a wide variety of management styles and techniques) than leaving them to implementation. Even if they did exist, I haven't ever seen an organization that was able to systematically identify, recruit, or train that skillset, and I do think they've been trying quite hard in various ways.

> while in the same forum glorifying hybrid roles like startup CTOs in the same forum who are obligated to do a lot of management functions AND be the basis of a strong technical department

I don't think I've ever been one of those people, but for what it's worth: most startups fail, and that those that succeed often do so by doing things that don't scale; in any case a startup CTO is rarely doing all the activities you listed earlier. Often startups simply don't do conventional line management at all, which works until it suddenly doesn't. Often startups don't have multiple distinct technical teams, which makes the whole notion of coordinating roadmaps between them moot.

Thank you very much for sharing. I can see quite a few very valuable suggestions here. I'll try incorporating that in my way.

Author seems to lose the distinction between project managers and engineering managers. The tricky thing is that some engineering managers do perform project management functions, but that will make for one overworked manager. In mainstream FAANG-type companies what you will see is:

Project management - manage scheduling, deadlines, track progress, day-to-day or low-level interteam collaboration, resolve blocking issues. They'll usually use a bug tracking system and ensure that it's state reflects reality. They may also need to build out or modify various processes such as new releases or deployments, work with QA on a validation process, or when should code be considered good-to-merge into the repo. (Has there been code review done, CI testing, validation, etc).

Engineering management - HR functions (promotion, performance management), assignment of tasks or larger projects, working with project management on realistic schedule, working with product / business on requirements, interfacing with other teams on high-level matters, strategic work related to the team, and most importantly work that no one ever wants to or has any time to do. (This includes technical work.)

IMO you can have a small org without these two functions if everyone is a has extensive experience/willingness to managing themselves, but if it grows past that things will break very quickly. Modern large organizations deal with unfathomable levels of non-technical complexity.

I have been saying this for years, but most consulting companies insist on managers who have no clue what they are talking about.

We're no google but I have lead the software department on techical decisions and scaling for the past 3 years as the company/startup tripled in growth. We are a tiny power rangers sized team, I probably just have angst in my comment as there is one particular employee who was recently hired before me stepping on that goes left when I "and everyone else on the team" says go right.