> He talks about both why the third group is less successful and how people within that group can potentially improve their situation within the current system.

Are you able to provide a cliff note or two about why they are less successful and how to improve their situations?

Why are line level engineers less successful? In short, the Gervais Principle[1]:

"Sociopaths, in their own best interests, knowingly promote over-performing losers into middle-management, groom under-performing losers into sociopaths, and leave the average bare-minimum-effort losers to fend for themselves."

What to do about it? These things:

* recognize that as software professionals we own the means of production

* learn the business side of software

* form partnerships with other developers such that the distinctions between worker and owner, suit and techie, no longer exists

* shift focus away from developing software according to a spec, and towards being a provider of overall business efficiency (often achieved through software).

Note that this is focused primarily towards developers working in the IT cost-centers of (generally non-technology) businesses.

[1] https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...

Note that engineers who do this become Sociopaths (in the MacLeod sense) - suddenly they are running a business, hiring employees, and taking every advantage they can, because if they don't, they're Clueless. The rest of the Ribbonfarm essay series expounded on this a bit more thoroughly - many of those Sociopaths are actually Losers until the right opportunity presents itself.

There isn't actually a way out, on a systemic level. On a personal level, though, you should be very honest with yourself about which of the three categories you want to be, and go after it. People who refuse to accept the trade-offs or deny that there is one are by definition Clueless.

> Note that engineers who do this become Sociopaths (in the MacLeod sense)

Which is actually what Dietrich is advocating, with a careful caveat: these developer partnerships only hire other Sociopaths (or Opportunists, as Dietrich calls them) insofar as it is possible, and generally avoid growing large enough to need a gooey Clueless middle.

The MacLeod system describes organizations of all sizes, but only reaches its full flowering in large enterprises.

I haven't read Developer Hegemony, but the book Managing the Professional Services Firm by David Maister is all about the structures present in other professional services work, e.g. law, accounting, engineering, etc., even car mechanics! :-) A ton of it is shared with software, so if you are a freelancer or trying to start a dev shop, it is great reading.