What are the Recurring Expectations for Achieving Staff-Plus Level Across Tech Companies, and Where do Senior Engineers Most Often Fall Short?
These are the 3 things I found that, if you do consistency, will make you golden as a Staff-Plus Engineer at pretty much any company. These are also the 3 most common expectations I have seen across the board for Staff Engineers. And by coincidence or not, these are also the 3 things I've seeing struggling Senior Engineers completely neglecting or being completely unaware of.

Here is my answer based on my last 8 years of experience on the Management track both as an EM and as a Director.

1️⃣ Blast radius:

There is this idea that you need to have a wide impact. As a staff, the impact should go beyond a single group or beyond a single project. There is, on the other side, this idea that you should be technically excellent. You should go deep, and you're the person that knows the most about the topic.
(Side-note: @alexewerlof wrote a fantastic article on this called "Beyond Staff Engineer")

I actually believe the mistake a lot of people make is that they go so deep on the technical expertise that they forget the organizational surface expectation, or what I call the blast radius of impact of what they are doing. In my view, yes, technical depth is important. We're going to see on part two of my talk, on the behaviors on why that's important. But, where I see a lot of people dropping the ball is on the blast radius, in terms of impacting the broad organization.
The reason why I chose blast radius, and not only like high impact, is because there are different shapes of blast radius. You can have an impact on something that's deep, something that almost changes how a product line works. Or, you can create a new platform, a new library or something that is going to make everybody else more productive, all the engineers are going to know who you are or the tool, the innovation you made. Blast radius is the thing that you have to keep in mind in this expectation for staff-plus. If you are working on a project that's only affecting a single repo, and not everybody is or will be knowing about that thing soon, is usually a red flag.

On High-Blast Radius, I honestly don't care how technical you are; I care about the blast radius impact of what you work on. It can be a blast radius that is super wide and affects the whole company, or it can be super deep in one area that almost revolutionizes how the product or the product line operates and has profound implications on that particular business area. On both angles, that impacted the company as a whole if you were able to fundamentally change how things were done in a product or product line; although your impact can be considered contained in that area, it impacted the revenue or the cost structure or the customer experience of the whole company. So keep that in mind; even small but deep blast radii are high-blast radii if you look from business eyes into that.

...continue...

🧵


2⃣ Multi-Scale Planning:

Multi-scale planning was an idea I first encountered in David Allen's "Getting Things Done," where it's described as the horizons of focus. I later came across a similar concept, the horizons of perspective, in the fantastic "Building a Second Brain" course by @fortelabs.
Many people talk about the importance of Big-Picture Thinking, emphasizing that staff engineers should focus on the next two to three years. I agree with that.
However, the thing that I see a lot of people dropping the ball is on understanding how those things come into play. A super common shortcoming: understanding how these long-term visions translate into actionable steps.
As you move up on the ladder, you go from knowing what you will do in the next few hours to knowing what to do in the next few days. Of course, as you get to Principal and Director Level, you're expected to be almost 1 year ahead and to be removing risks, or planning the roadmap for the things in the next year or so. That's fair. I think the problem that I see a lot of people missing is that they don't understand how to cascade things from the day to the week to the quarter in how the organization dynamic actually works.
Highly effective staff engineers excel in multi-scale planning, even though this skill is often not explicitly outlined in career ladders. These engineers understand how to anticipate project needs, such as foreseeing the necessity for additional resources or preparing pitches for the CEO. They adeptly navigate different time horizons, ensuring that visionary ideas are grounded in reality and aligned with organizational structures.

They know how to play the different time horizons and to bring things back and forth. They are not only thinking about the next few years and having very visionary ideas, but it's also how you bring that in reality and how they will play with the organizational structure to make that a reality.
One common mistake among senior engineers is over-reliance on short-term solutions, like intense two-week projects. This approach can lead to burnout and is unsustainable. Instead, the focus should be on sustainable planning, balancing immediate tasks with long-term goals, and integrating these plans within the organization's framework to achieve lasting success.

Ten Principles for Growth as an Engineer by Dan Heller:

“These are the most important lessons that I wish I had learned ears earlier than I did; I sure wish someone had sent it to me when I was 22.”

1. Reason about business value: Reason like a CEO. Understand the value of your work to your company, and take responsibility for reasoning about quality, feature richness, and speed. Your job isn't just to write code; your job is to make good decisions and help your company succeed, and that requires understanding what really matters.

2. Unblock yourself: Learn to never, ever accept being blocked; find a way by persuasion, escalation, or technical creativity. Again, your job isn't just to write the code and wait for everything else to fall into place; your job is to figure out how to create value with your efforts.

3. Take initiative: The most common misconception in software is that there are grown-ups out there who are on top of things. Own your team's and company's mission. Don't wait to be told; think about what needs doing and do it or advocate for it. Managers depend on the creativity and intelligence of their engineers, not figuring it all out themselves.

4. Improve your writing: Crisp technical writing eases collaboration and greatly improves your ability to persuade, inform, and teach. Remember who your audience is and what they know, write clearly and concisely, and almost al-wavs include a tl;dr above the fold

5. Own your project management: Understand the dependency graph for your project, ensure key pieces have owners, write good summaries of plans and status, and proactively inform stakcholders of plans and progress. Practice running meetings! All this enables you to take on much bigger projects and is great preparation for leadership.
6. Own your education: Pursue mastery of your craft. Your career should be a journey of constant growth, but no one else will ensure that you grow. Find a way to make learning part of your daily life (even 5 minutes/ day); get on mailing lists, find papers and books that are worth reading, and read the manual cover to cover for technologies you work with. Consistency is key; build habits that will keep you growing throughout your career.

7. Master your tools: Mastery of editor, debugger, compiler, IDE, database, network tools, and Unix commands is incredibly empowering and likely the best way to increase your development speed. When you encounter a new technology or command, go deeper than you think you have to; you'll learn tricks that will serve you well again and again.

8. Communicate proactively: Regular, well-organized communication builds confidence and goodwill in collabor-ators; knowledge-sharing creates an atmosphere of learning and camaraderie. Share knowledge, and set a regular cadence of informing stakeholders on project goals, progress, and obstacles. Give talks and speak up judiciously in meetings.

9.Find opportunities to collaborate: Good collaboration both increases your leverage and improves your visibility in your organization. Advancing your craft as an engineer requires you to have an impact beyond the code you write, and advancing your career requires, to a certain degree, building a personal brand at your company Cross-functional projects and professional, respectful collaboration are critical to both.

professional and reliable: Think of yourself as a professional, and act like one. Come to meetings on time and prepared, then pay attention. Deliver what you say you will, and communicate proactively when things go wrong (they will). Keep your cool, and express objections respectfully. Show your colleagues respect and appreciation. Minimize your complaining; bring the people around you up, not down. Everyone appreciates a true professional; more importantly, it's the right way to behave.

I've read 500+ books and accumulated 55.000+ notes & highlights over the last ten years. 99% of those books were non-fiction & mostly around Software Engineering.

Below are The 22 Technical Books that Impacted my Career the most ➕ their highest-density chapters & pages.

🧵



1️⃣ The Software Craftsman: Professionalism, Pragmatism, Pride by @sandromancuso.

Why do we need Technical Engineering Managers?

Below is a list of Lesser-Known Reasons why we need More Technical Engineering Managers:

1- Prevent team members from underperforming due to a lack of opportunities! How? 👇

🧵 Failing to identify if the task/feature/problem at hand is complex enough to require a Senior or a Staff Eng (or if a Junior Eng can do it) leads to teams overloaded by overqualified engineers that frequently step on each other feet.

I have interviewed 300+ Senior Engineers, Tech Leads & Engineering Managers over the last 10 years of my career.

Here are the most actionable tips I learned on how you can do better on Behavioral Interviews as EMs/Staff+ and also some common pitfalls:

🧵🧵🧵 1. The STAR format is like a Three-Course Meal:

• The Situation/Task is the Appetizer,

• Your Actions are the Main Course,

• The Results are the Dessert, the cherry on top.

Don’t overfeed the interviewer at any point, otherwise…

Remote Pair Programming Good Practices: A Thread.

Found the slides of a presentation that @qcoding and I gave to the entire CTO Org at Amex two years ago when we were both there.

Thought it had a lot of great stuff that could still be useful to others.

Why not share?

🧵 Remote pair programming:

Outline:

1. When to do it,
2. When NOT to do it,
3. Practical Tips on how to do it,
4. Recommended tools,
5. Additional references.

But first, let's start with WHY to do it.

0. Why to do it

WHY?

Will Larson (@Lethain) has written two books (An Elegant Puzzle & Staff Engineer) & many articles about Career Growth for Engineering Leaders. I have read all of them!

Below are his Best Pieces of Advice for a Remarkable Forty-Year Career in Tech.

↓↓↓ 1️⃣ Collect People. Not Jobs, Companies, or Frameworks.

Collect People? WTF?

Jobs don't last forever, but your career and the people around you in the industry do.

It's uniquely valuable to start to reflect & collect people you admire and genuinely love to work with.

As a manager, it isn't your job to train people. You’re not a trainer!

This isn't lack of empathy.

We all love to help people.

Yet our time is limited.

Improving your top performer by 10% is worth 10x more than improving your bottom performer by 10%.

It's leverage! Source: @scarletinked as insightful and as precise as always on accomplishing more with less effort.

A Couple Decades of Unlearning — Lessons on the Path to Director:
scarletink.com/couple-decades…

Last week I shared that @xdg's piece on Mentoring Engineers was one of my favorites.

Here is why. Highlights:

Mentors should operate at 3 levels:

1️⃣ Goals - Figuring out what they really want
2️⃣ Situations - Handling the unfamiliar or difficult
3️⃣ Skills - Getting promoted

🧵

https://twitter.com/thiagoghisi/status/1617250051302248449

1️⃣ GOALS: Telling someone what they should want isn’t as powerful as helping them discover it for themself.

Goals are most meaningful when they are deeply understood.

The best goals come from within.

I've read thousands of articles over the last 20 years in Tech.

Agile, Career, Distributed Systems, Engineering Management, Metrics, Programming, Testing, Types...

Below are The 22 Articles that Impacted my Career the most ➕ my main highlights from each one.

🧵🧵🧵 1️⃣ On Software Rewrites: "Things You Should Never Do, Part I" by Joel Spolsky (@spolsky).

→ Link: joelonsoftware.com/2000/04/06/thi…

~2013: It heavily influenced me probably 10 years back and explains a lot about why I’m not a big fan of “Green Field Projects.”

As we begin a new performance cycle, here is something to think about to really grow career-wise: Staff Projects.

Projects that are considered complex and important enough that the person who completes them has proven themselves as a Staff+ engineer.

Here are a few examples: 1) Projects that you’ve worked on that have spun off into their own dedicated teams.

That’s usually a great sign of a Staff Project.

The Seven False Hopes of Software Management (1987).

Each one reaches out with an attractive fallacy that leads nowhere.

As long as you believe them, you’re going to be reluctant to do the hard work necessary to build a healthy & productive culture.

🧵 1️⃣ There is some new trick you've missed that could send productivity soaring.

People like to learn, and to improve. The line that there is some magical innovation out there that you’ve missed is a pure fear tactic, employed by those with a vested interest in selling it.

B.S!

If you've recently been laid off, you’re preparing for interviews, trying to get promoted or just setting career goals for 2023, check this out:

I went from 3k to 16k followers on LinkedIn in 2022 and here are My Top 10 Posts that had 3M+ views & I’m sure will help you👇

🧵 1️⃣ Don't overfeed the interviewer!

My very best advice on Behavioral Interviews & The STAR Method to Engineering Managers & Staff+ Engineers interviewing to the Big Techs.

It even got an awesome share from @Lethain and a comment from @alexxubyte.

Link: lnkd.in/eKQMbkQH

How to Build a Strong Career in Tech.

2019, I gave a talk.

2020, I wrote an article expanding the talk.

2021, I recorded a podcast distilling the article.

2022, I gave an interview talking about growth as an EM.

2023, I'm sharing my favorite ideas about career 👇

🧵🧵🧵 1️⃣ Part I - Definition of Career Success

What do successful careers in tech have in common?

Impact of their ideas on a large number of people directly or indirectly.

Success = Impact & Influence!

🧵 The Engineering Career Progression Function:

https://twitter.com/thiagoghisi/status/1279890984466370567?s=20&t=gKnagZ5FshB_POwkf1L-jg

I've watched 1000+ Conferences Talks over the last 20 years in Tech. I used to watch one every night after dinner for years.

Below are The 22 Talks that Impacted my Career the most ➕ my main highlights from each one.

🧵🧵🧵 1️⃣ Øredev 2011 - Sleeping with the enemy by Gojko Adzic (@gojkoadzic)

→ Link:

"The new mission of QAs should be teach programmers to collaborate, own quality together, automate tests or checks together."

Back in 2011, this was controversial. I 💚 it.

Senior Engineers understand that the highest value of code reviews isn't about ensuring high-quality code.

They know that code review is about teaching & learning how to do better engineering. Senior Engineers understand that a design review (the same applies to RFCs) isn't only about making the best design.

It's about walking through the tradeoffs in the design, asking the right questions, and ensuring that all tech folks involved understand why choices were made.

I've read 500+ books and accumulated 55.000+ notes & highlights over the last ten years. 99% of those books were non-fiction & mostly around Software Engineering.

Below are The 22 Technical Books that Impacted my Career the most ➕ their highest-density chapters & pages.

🧵 1️⃣ The Software Craftsman: Professionalism, Pragmatism, Pride by @sandromancuso.

ICs need to “know their shape”.

Eng. Managers need to know their shape & all their ICs shapes.

Directors need to know their shape, their Managers shapes & their most impactful ICs shapes.

So they can fit their teams together like puzzle pieces.

Otherwise… 🧵 Without a thoughtful approach, Teams will end up unbalanced.

Unbalanced teams will ship unbalanced products at an unbalanced cadence with unbalanced levels of quality, autonomy & ownership.

I read a lot about Engineering Management. Of all writers I found this year, @scarletinked has been by far the most consistently insightful with 100% down-to-earth & actionable tips.

This piece on How to Onboard Yourself in 3 Weeks at a New Job is a clear example of that!

🧵 When moving to a new team, there are a few key elements to learn before you can provide value:

1- The product you're working on,
2- The partners you'll work with, and
3- The systems behind the product.

This paper "Momentum Theory" by Patrick Franklin (a former Eng. Leader of mine) is so good and has so much history that it could easily become a @stevesi's "Hardcore Software" post.

Rule #1: Always attach to existing momentum.
Rule #2: New systems must link to momentum. @stevesi All sources & credits to Patrick (that doesn't have a Twitter account):

linkedin.com/in/patrick-fra…

If I could combine Three Articles that I re-read recently (along with a few visuals) into One Thing that could make your head explode and your self-reflections & career conversations to grow exponentially in effectiveness, I would pick the following three:

🧵🧵🧵 1️⃣ The initial provocation by Will Larson on Career Narratives.

> "I have slowly but increasingly come to believe that there is much more opportunity outside career ladders than within them, and by including those opportunities you'll make and feel more progress."