Are Corporate Software Engineering Jobs Performative?

The Tension Between Technical Output and Corporate Bureaucracy

Corporate software engineering often creates a perceived gap between actual technical contribution and the "performative" actions required to navigate a large organization. While some engineers view the proliferation of meetings, 1:1s, and bureaucratic processes as a waste of time, others argue that these elements are essential for maintaining stability and coordination at scale.

The Case for "Performative" Work

Many engineers argue that in large corporations, especially within FAANG-scale companies, a significant portion of the workforce engages in work that serves the organization's internal needs rather than the product's goals. This phenomenon is characterized by:

  • The Pareto Distribution of Effort: Multiple contributors noted that a small minority of "all-stars" often carry the majority of the technical load, while others engage in "social loafing" or perform actions solely to gain visibility.
  • Incentive Misalignment: When companies rely on flawed metrics—such as lines of code (LOC), PR counts, or time spent in the office—employees often "play the game" to satisfy these KPIs rather than focusing on high-impact work.
  • The Rise of the "Purpose Factory": Some argue that large organizations eventually become "purpose factories," where the primary product is providing employees with a sense of importance and justification for their roles, regardless of their actual output.
  • Bureaucratic Capture: Referencing "Pournelle's Iron Law of Bureaucracy," some contributors suggest that those dedicated to the organization itself eventually gain control over those dedicated to the organization's goals, leading to a culture of rule-following over result-delivery.

The Defense of Organizational "Slack"

Conversely, a strong counter-argument exists that what appears to be "performative" is actually necessary infrastructure for a massive enterprise.

  • The Necessity of Coordination: Supporters of corporate structure argue that 1:1s and management overhead are not useless but are critical for listening to developers, managing underperformers, and coordinating complex dependencies that a small team could ignore.
  • Organizational Slack: Some argue that "slack" in a system is a feature, not a bug. Having extra capacity prevents the organization from grinding to a halt when a key person leaves or takes a vacation.
  • The Cost of Scale: As a product matures, the need for rapid feature development decreases, and the work shifts toward "knob-turning," optimization, and risk mitigation. This shift can make the work feel less impactful to an engineer used to greenfield development.
  • ROI of Specialized Talent: Even seemingly "useless" roles (e.g., kernel developers at a social media company) can provide immense ROI if they can fix a single critical performance bottleneck that affects millions of users.

Synthesis of Perspectives

The debate highlights a fundamental disagreement on how to measure value in software engineering. One side views value as the direct delivery of working code; the other views value as the sustainability and predictability of the organization.

"The narrative about someone is way more powerful than facts. Their whole job is to play politics and pushing a narrative to other managers/ICs during 1:1s."

"If you treat an organization as a machine of interlocking parts... you may be overly surprised that people aren't adding value. If you try to understand large businesses as a kind of welfare system to keep the middle class satiated, then the behavior of your boss and coworkers makes sense."

Ultimately, the consensus suggests that while inefficiency is rampant in large corporations, it is often a byproduct of growth. The "performative" nature of the work is frequently a response to the incentive structures created by management to maintain control over thousands of employees.

Sources