> This is what the AI boom is really about, removing more power from labor. Its why all the AI hype largely markets itself in this way "how AI can replace or minimize X role" as opposed to "This is how you can use AI to empower your workforce in the majority of discourse I've seen around it.

Arguably, AI is largely marketed that way because that's what corporate buyers care about, the same way every productivity improving invention has been marketed to corporate buyers even if a major actual effect is increasing the value of each labor hour and driving wages up. (Which is largely isomorphic to reducing the number X role needed in the production of Y units of a good or service.)

Its also sold as a labor productivity increase to independent creators. And the two things are, after all, different sides of the same coin.

When I was in the policymaking world and was considering grad school/academia, an underlying theme in my research was that the principal-agent problem is a reflection of misaligned incentives which leads a stag-hunt dynamic to become a Nash Equilibrium.

Long story short, incentives matter, and understanding how to align your initiatives with the incentives of veto players helps build coalitions that you need to get initiatives out the door. That said, these initiatives also need to be executed successfully, becuase organizational dynamics are inherently multi-agent games.

Essentially, I made sure to understand how to speak (ie. Understand the incentive structures) of multiple stakeholders (eg. How to convince Mgmt and IC Engineers, PMs, salespeople, customer success, and customers) and also how to execute successfully on initiatives (ie. How to successfully launch products, lead a round, land customers, or manage an M&A event).

This meant both building domain knowledge about each of the stakeholders fields as well as building domain knowledge in a handful of fields I knew I could specialize in.

Basically, understanding incentive structures and being able to show how your interests and goals align with those incentives is critical.

For example, back when I was an IC level engineer, if I wanted to get tech debt prioritized, I made sure to:

1. Show that it was tied to active issues to customers that matter - eg. fixing a bug for a customer who spends $20k a year at a company generating $100M a year in revenue is a misallocation of resources for EMs and PMs

2. Show that it is tied to speeding up feature delivery: it converts a conversation around "maintenance" into a conversation around adding new capabilities that are assumed to generate revenue, thus aligning Sales, PM, and Leadership

A lot of people on HN neurotically and reflexively don't care to understand how organizations work or how to make a case. A number of them assume that just because it's a technical problem it should actually matter to the top line of a business. In most cases, it does not if you cannot make a case for it. A number of them also don't care to leave a bad organization if they are in one (I have worked in 2 in my career, and made sure to leave).

I have no MBA, I just have an undergrad CS degree (and a secondary in Government). Even though my current day job doesn't demand it, I can still code, but I also taught myself how to do basic FP&A, marketing, user experience research, and other functions. If you want to survive and thrive in the tech industry, nowadays you will need to build industry specific domain experience, technology specific domain experience, and basic product management, sales, and user experience chops.