1 files changed, 16 insertions, 16 deletions

diff --git a/notes/staff-engineer.md b/notes/staff-engineer.md
index 39c262cb..221d4e93 100644
--- a/notes/staff-engineer.md
+++ b/notes/staff-engineer.md
@@ -36,54 +36,54 @@ These are my personal takeaways after reading "Staff Engineer" by Will Larson. N
 
 ## The Four Archetypes of a Staff Engineer
 
-Larson breaks down the role of a Staff Engineer into four main archetypes, which can help frame how you approach the role:
+Larson defines four archetypes. You'll probably recognize yourself in one (or a mix):
 
-* Tech Lead: Focuses on the technical direction of a team, ensuring high-quality execution, architecture, and aligning the team around shared goals.
-* Solver: Gets pulled into complex, high-impact problems that often involve many teams or systems, operating as a fixer or troubleshooter.
-* Architect: Works on the long-term technical vision for an organization, setting standards and designing systems that will scale and last over time.
-* Right Hand: Functions as a trusted technical advisor to leadership, providing input on strategy, long-term decisions, and navigating organizational politics.
+* Tech Lead: You own the technical direction of a team. Architecture, quality, keeping everyone aligned.
+* Solver: You get thrown at the hard cross-team problems. Basically a firefighter for gnarly stuff.
+* Architect: Long-term technical vision. Standards, system design, things that need to last.
+* Right Hand: Trusted technical advisor to leadership. Strategy, org politics, the stuff nobody else wants to touch.
 
 ## Influence and Impact over Authority
 
-As a Staff Engineer, influence is often more important than formal authority. You’ll rarely have direct control over teams or projects but will need to drive outcomes by influencing peers, other teams, and leadership. It’s about understanding how to persuade, align, and mentor others to achieve technical outcomes.
+You won't have direct authority over most people or teams you work with. Influence is the actual tool here. You have to persuade, align, sometimes just nudge people in the right direction. No one reports to you, but you still need to drive outcomes.
 
 ## Breadth and Depth of Knowledge
 
-Staff Engineers often need to maintain a breadth of knowledge across various areas while maintaining depth in a few. This can mean keeping a high-level understanding of several domains (e.g., infrastructure, security, product development) but being able to dive deep when needed in certain core areas.
+You need to know a bit about a lot of things (infra, security, product, etc.) but still be able to go deep in a few areas. The tricky part is keeping that breadth current without spreading yourself too thin.
 
 ## Mentorship and Sponsorship
 
-An important part of a Staff Engineer’s role is mentoring others, not just in technical matters but in career development as well. Sponsorship goes a step beyond mentorship, where you actively advocate for others, create opportunities for them, and push them toward growth.
+Mentoring is obvious -- help people grow technically and career-wise. But sponsorship is the one that surprised me: actively advocating for people, creating opportunities for them, pushing them forward. It's not just answering questions, it's putting your reputation behind someone.
 
 ## Managing Up and Across
 
-Success as a Staff Engineer often depends on managing up (influencing leadership and setting expectations) and managing across (working effectively with peers and other teams). This is often tied to communication skills, the ability to advocate for technical needs, and fostering alignment across departments or organizations.
+You have to manage up (set expectations with leadership, advocate for technical needs) and across (work with peer teams, build alignment). Basically a lot of communication and relationship building. Easy to underestimate this one.
 
 ## Strategic Thinking
 
-While Senior Engineers may focus on execution, Staff Engineers are expected to think strategically, making decisions that will affect the company or product months or years down the line. This means balancing short-term execution needs with long-term architectural decisions, which may require challenging short-term pressures.
+Senior engineers focus on execution. Staff engineers need to think about what happens months or years from now. That means sometimes pushing back on short-term pressures in favor of longer-term architectural decisions. Not always a popular move.
 
 ## Emotional Intelligence
 
-The higher you go in engineering roles, the more soft skills, particularly emotional intelligence (EQ), come into play. Building relationships, resolving conflicts, and understanding the broader emotional dynamics of the team and organization become key parts of your role.
+The higher you go, the more soft skills matter. Building relationships, resolving conflicts, reading the room. I think this catches a lot of engineers off guard -- you can't just be the smartest person technically anymore.
 
 ## Navigating Ambiguity
 
-Staff Engineers are often placed in situations with high ambiguity—whether in defining the problem space, coming up with a solution, or aligning stakeholders. The ability to operate effectively in these unclear areas is critical to success.
+A lot of the problems you deal with are poorly defined. Nobody knows exactly what the problem is, let alone the solution. You have to be comfortable operating in that fog and still making progress.
 
 ## Visible and Invisible Work
 
-Much of the work done by Staff Engineers is invisible. Solving complex problems, creating alignment, or influencing decisions doesn’t always result in tangible code, but it can have a massive impact. Larson emphasizes that part of the role is being comfortable with this type of invisible contribution.
+A huge chunk of Staff Engineer work is invisible. Aligning teams, influencing decisions, resolving conflicts -- none of that shows up as commits. Larson says you need to get comfortable with that, which I think is genuinely hard for engineers who are used to shipping things.
 
 ## Scaling Yourself
 
-At the Staff Engineer level, you must scale your impact beyond direct contribution. This can involve improving documentation, developing repeatable processes, mentoring others, or automating parts of the workflow. The idea is to enable teams and individuals to be more effective, even when you’re not directly involved.
+You can't do everything yourself anymore. Write things down, build repeatable processes, mentor others, automate what you can. The goal is to make teams more effective even when you're not in the room.
 
 ## Career Progression and Title Inflation
 
-Larson touches on how different companies have varying definitions of "Staff Engineer," and titles don’t always correlate directly with responsibility or skill. He emphasizes the importance of focusing more on the work you're doing and the impact you're having, rather than the title itself.
+"Staff Engineer" means wildly different things at different companies. Titles don't always match actual responsibility or skill. Focus on the work and impact, not the title.
 
-These additional points reflect more of the strategic, interpersonal, and leadership aspects that go beyond the technical expertise expected at this level. The role of a Staff Engineer is often about balancing high-level strategy with technical execution, while influencing teams and projects in a sustainable, long-term way.
+Some of the above is less about technical chops and more about the strategic and interpersonal side of things. Anyway, here are some more concrete takeaways:
 
 ## Not a faster Senior Engineer