---
id: ins_all-problems-become-people-problems
operator: Silvia Botros
operator_role: Senior Principal Engineer, Twilio
source_url: https://leaddev.com/hiring/reality-being-principal-engineer
source_type: essay
source_title: The reality of being a Principal Engineer
source_date: 2020-08-10
captured_date: 2026-05-01
domain: [leadership, engineering]
lifecycle: [process-cadence, hiring-team-design]
maturity: foundational
artifact_class: framework
score: { originality: 3, specificity: 3, evidence: 4, transferability: 5, source: 5 }
tier: B
related: [ins_principal-ic-is-force-multiplier, ins_glue-work-is-staff-leadership]
raw_ref: raw/essays/silvia-botros--principal-engineer-reality--2020-08.md
---

# Above a certain level, every problem is a people problem

## Claim
The classic "manager vs. IC" fork is a false choice. Once an engineer reaches principal level, all problems are solved through people, convincing the technical team why a business problem should be solved one way over another, finding the right message for each audience. There are no purely technical problems at that altitude.

## Mechanism
Technical problems at the principal scope are systems problems, and systems are made of teams. The hard part is not finding the right architecture; it is getting twelve engineers, three product managers, and a VP to converge on it. That is influence work. Code-level competence becomes the table stake; the actual job is moving humans. ICs who treat the role as "manager problems are not my problem" fail at it.

## Conditions
Holds when:
- The IC has reached genuine principal-level scope (cross-team architecture, multi-quarter bets).
- The org rewards influence work as part of the IC ladder.

Fails when:
- The "principal" title is a senior-senior label without cross-org scope, then technical problems still dominate.
- The IC keeps avoiding people work and stays within their immediate codebase, the title is misapplied.

## Evidence
> "Once you reach a certain level, all problems are solved by people. There is no such thing as a purely technical problem. In fact, this is the level where one wishes more problems were code-based because we can make code do a lot of things, but making people do things is harder and influencing people to do what we want is harder still."

· Silvia Botros, LeadDev, 2020-08-10

## Signals
- The principal spends meaningful time building written artifacts (RFCs, architecture docs) that persuade.
- Conflict-resolution and stakeholder alignment are explicit on the principal's review.
- "Brilliant jerk" pattern is treated as a competency gap, not eccentricity.

## Counter-evidence
Some ICs choose to stay at "senior" precisely because they want technical work. The Botros frame is descriptive of principal+ scope, not prescriptive that every senior must embrace people work. The fork is real if the IC chooses not to climb, the claim only governs at the principal step.

## Cross-references
- `ins_principal-ic-is-force-multiplier`, the Botros companion claim about the role's shape.
- `ins_glue-work-is-staff-leadership`, Tanya Reilly's framing of why this work is the leadership.