Post

@gojkoadzic

@danvacanti

@unclebobmartin

@paulocaroli

@whereistanya

@adamtornhill

@pretotyping

@klauswuestefeld

@unclebobmartin

@henriquebastos

@simonbrown

@ryanvalles

@gojkoadzic

@glv

@jbrains

@shanselman

@jezhumble

@sandromancuso

@fgeorge52

@HealthyGamerGG

@thiagoghisi

More from @thiagoghisi

Thiago Ghisi

@thiagoghisi

Jul 14, 2024

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.

3⃣Ownership & Autonomy level:

Then the third expectation that, again, is not clear on the ladder, but I feel is where a lot of people get it wrong is the idea of implementer, solvers, and finders.
(Side-note: @rkoutnik's canonical article called "Implementers, Solvers, and Finders")

At the start of one's career, you are an Implementer, tasked with executing specific instructions and replicating given solutions, examples or patterns. Someone will give you a TASK and the HOW.
As you advance to a senior level, you become a Solver, where you are provided with problems that you need to figure out independently. Someone gives you a problem, and you go and you figure out. There is not clear HOW.
However, many people stop at being solvers. There is even the archetype that's called Solver that I think actually creates more damage than it helps IMO
The next critical level is the Finder. This role is about not only solving problems but also anticipating and identifying future priorities and challenges for the organization. It is someone that is not only solving problems and different shapes of problems, but is someone that's thinking ahead of time, and is finding the next priorities, the next things that the organization needs to focus.
If you visualize this on a career ladder, you start as an Implementer, progress to a Solver, and then advance to a Finder.

In reality, you never entirely stop being a solver or implementer. As said, a common mistake is that some professionals never transition to the Finder role, remaining perpetually in Solver mode. Conversely, others may focus solely on finding problems without contributing to their resolution, merely pointing out potential obstacles or risks. They're just going finding mode, and they throw over like: "There is this problem here, we're going to get blocked here." And they don't help any further.

In reality, the very effective staff engineers and the behavior that they do, is pretty much this. They're able to go back and forth on the different horizons of time, but also in different modes.

Effective staff engineers excel by seamlessly shifting between these roles and time horizons. They can move back and forth between implementing, solving, and finding as needed. If there is no one to delegate tasks to, they take on the solver role. When implementation is necessary, they step in to execute tasks. Mastery in these dynamics ensures their effectiveness and value within the organization.

Read 4 tweets

Thiago Ghisi

@thiagoghisi

Nov 26, 2023

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.

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.

Read 6 tweets

Thiago Ghisi

@thiagoghisi

Apr 27, 2023

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.

2️⃣ Working Effectively with Legacy Code by @mfeathers.

Read 26 tweets

Thiago Ghisi

@thiagoghisi

Feb 26, 2023

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.

2- Proactively manages low performers!

Frequently review/inspect the quality & cadence/throughput/size of ongoing pull requests (and other contributions) for each team member and give specific & concrete feedback on what they need to do to reach their expected performance level.

Read 11 tweets

Thiago Ghisi

@thiagoghisi

Feb 14, 2023

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…

The same way that if a chef overfeeds a customer with too much food in a course, they are not going to be ready to eat the next one, you also don't want to overfeed the interviewer with too much information at any point.

Always assume that if they want more, they will ask for it

Read 14 tweets

Thiago Ghisi

@thiagoghisi

Feb 3, 2023

@qcoding

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?

I'm pretty sure the first question that comes to mind is Why?

Why should I pair?

Why would TWO engineers share the SAME machine and work on the SAME problem for hours or sometimes for multiple days?

Well, pairing brings many benefits.

Here are a few we want to highlight:

Read 39 tweets

Share this page!

Enter URL or ID to Unroll

Thiago Ghisi

Try unrolling a thread yourself!

More from @thiagoghisi

Thiago Ghisi

Thiago Ghisi

Thiago Ghisi

Thiago Ghisi

Thiago Ghisi

Thiago Ghisi

Did Thread Reader help you today?

Don't want to be a Premium member but still want to support us?

Send Email!