DEV Community: Omri Lavi

Growing as a Technical Leader: Lessons from the Book Staff Engineer

Omri Lavi — Sat, 01 Feb 2025 09:07:36 +0000

Growing as an Individual Contributor (IC) is a rewarding journey, but it’s not always clear how to make meaningful progress. I’ve faced these challenges myself—balancing learning, making an impact, and figuring out how to advance my career. Reading Staff Engineer by Will Larson was a transformative experience. While some concepts felt familiar, the book’s structured approach provided clarity and actionable insights that illuminated a clear path forward.

This article captures the key lessons I learned from the book, focusing on technical leadership, areas for improvement, and practical growth tips. My goal is to provide value for readers while solidifying my understanding of the book’s teachings as a reference for future growth. I hope this dual perspective helps you reflect on your journey, identify your strengths and areas to improve, and discover tools to navigate the IC path with confidence. For deeper insights, I highly recommend reading the book and exploring the resources at staffeng.com.

The Four Archetypes of Staff Engineers

One of the most fascinating insights from Staff Engineer is the concept of archetypes that define how Staff+ Engineers operate. These archetypes provide a framework for understanding the diverse ways individuals can make an impact:

The Tech Lead: Breaks down tasks, aligns the team, and delegates effectively to maintain momentum.
The Architect: Specializes in a technical domain, ensuring scalable, maintainable solutions that align with business goals.
The Problem Solver: Tackles complex challenges, resolves issues, and hands off solutions to the owning team.
The Right Hand: Bridges leadership and engineering, translating business needs into technical initiatives.

Comparing the Four Archetypes

Archetype	Focus Area	Key Responsibilities	Example Scenario
The Tech Lead	Team execution & alignment	Scoping tasks, aligning the team, and delegating effectively	Coordinating a major feature rollout across multiple developers
The Architect	System & technical vision	Designing scalable solutions and ensuring technical consistency	Defining an API strategy that scales across teams
The Problem Solver	Complex challenges	Troubleshooting critical issues and handing off solutions	Fixing a database bottleneck impacting performance
The Right Hand	Leadership & strategy	Aligning business and engineering priorities	Communicating a strategic shift to the engineering team

Staff Engineers adapt to different roles as needed, making their impact dynamic and situational. While I don’t hold the title, I’ve taken in the past the Tech Lead and Problem Solver roles—aligning teams or tackling challenges when necessary. The ability to flex between these archetypes is a key trait of high-performing engineers. Those who recognize when to shift their approach can maximize their influence and help their teams succeed at every stage of a project or company growth.

Key Areas of Focus for Staff Engineers

One of the main takeaways from Staff Engineer is the importance of focusing your efforts where they matter most. Staff+ Engineers prioritize their work by avoiding common pitfalls and targeting impactful areas.

Avoiding the Pitfalls

Not all tasks are equally valuable, and some can drain your energy without meaningful results. Larson identifies three common traps:

Snacking: Low-effort, low-priority tasks that feel good to check off but don’t contribute to meaningful growth. Occasional filler tasks are fine—but don’t let them dominate your focus.
“Preening”: This is a subset of snacking—tasks with high visibility but little impact. These can be tempting if you’re trying to stand out but often end up as distractions. I once spent longer than I’ll admit micro-optimizing a feature, excited by the idea of achieving a 70% performance boost. While it felt like a big win, in absolute numbers, it only saved a few milliseconds and had little real-world impact.
Chasing Ghosts: Pursuing outdated priorities or visions from others without aligning them to current goals.

While avoiding these common traps is essential, it’s just as important to proactively focus on high-impact work.

Focusing on Impact

To make the most of your efforts, focus on areas where you can truly make a difference:

Addressing the Gaps: Identify overlooked areas that need attention and step up to fill them.
Supporting Growth: Create lasting value by improving processes like onboarding new team members.
Editing and Guiding: Ensure ongoing work is on track and of high quality. Acting as an “editor” can amplify the team’s impact.
Closing the Loop: Help complete stalled or lingering tasks to bring clarity and forward momentum.
Doing What Only You Can Do: Focus on tasks where your unique skills and expertise are critical. Delegate work when it makes sense, allowing you to concentrate on where you add the most value.

Focusing on high-impact work is crucial, but to drive real change as a Staff+ Engineer, you also need to guide your team in the right direction. This is where strategy and vision come into play.

Strategy and Vision: The Path and the Way Forward

Two essential tools for effective leadership as a Staff+ Engineer are vision and strategy. These aren’t just buzzwords—they’re the compass and the roadmap for navigating uncertainty and driving progress.

Vision: The Long-Term Destination

Vision is about defining where you want to be in the future, typically one to two years down the line. A strong vision provides clarity and alignment, especially during times of uncertainty. It answers the big questions: What are we building? Why does it matter? When a team rallies around a shared vision, they can move forward with confidence, even when the path isn’t perfectly clear.

Strategy: The Map for Getting There

Strategy, on the other hand, is about the how. It’s most useful when the same discussions start to repeat themselves—when you’ve talked about a problem three or four times but haven’t made progress. A well-crafted strategy cuts through this noise, providing direction and enabling teams to move forward decisively.

The magic happens when vision and strategy work together. Vision sets the destination, and strategy outlines the steps to get there. With both in place, teams can not only move faster but also stay on track, even when challenges arise.

Contributions to Quality: Building the Foundations for Success

One of the most impactful ways a Staff+ Engineer can elevate their team and organization is by championing quality. This doesn’t just mean writing better code; it involves fostering a culture and infrastructure that prioritizes excellence. Here are some key areas where Staff+ Engineers contribute to quality:

1. Focus on Hot Spots

Identify the areas demanding attention—whether it’s a buggy module, a slow process, or a recurring pain point. By addressing these high-priority “hot spots,” you can drive immediate, noticeable improvement.

2. Define and Train for Best Practices

Great quality starts with shared understanding. Staff+ Engineers are often responsible for defining best practices and ensuring they’re communicated effectively. However, avoid overwhelming the team: focus on introducing one best practice at a time to minimize friction and maximize adoption.

3. Be Involved in Leverage Points

Certain decisions have an outsized impact on long-term quality. These include interfaces, state management, and data models. Staff+ Engineers ensure these critical “leverage points” are designed thoughtfully, as they’re hard to change once established.

4. Measure Quality

You can’t improve what you don’t measure. By introducing and tracking quantifiable metrics, such as code coverage, performance benchmarks, or bug resolution times, you create visibility into quality and its trends.

5. Use Vectors for Progress

Progress isn’t just about moving forward—it’s about moving in the right direction. Vectors ensure that everyone involved is aligned and working toward the same goals, preventing wasted effort.

6. Leverage Quality Teams or Programs

Sometimes, quality improvements require systemic changes. Dedicated quality teams or programs can drive these initiatives, ensuring a cohesive approach to raising standards across the board.

Checklist for Solving Quality-Related Pain Points

This checklist is a combination of insights from Staff Engineer and my own experiences in tackling quality-related challenges.

✅ Identify key pain points: Talk with people, empathize with their struggles.

✅ Understand the root cause: Determine where the struggle originates and why it happens.

✅ Research best practices: Look for industry standards and solutions that fit your company's unique needs.

✅ Establish clear metrics: Define measurable success criteria to align all stakeholders on progress.

✅ Communicate the process: Ensure all stakeholders understand the impact and why change is necessary.

✅ Train and support teams: Guide teams through the improvements, and recruit "champions" to help drive adoption.

✅ Celebrate milestones: Acknowledge progress, especially when overcoming challenges!

Ensuring high-quality engineering practices is crucial, but technical excellence alone isn’t enough. To truly lead and make an impact, a Staff+ Engineer must also master the interpersonal side of leadership—building trust, fostering collaboration, and guiding teams effectively.

Soft Skills for Success: The Hidden Superpower

Technical expertise is vital for a Staff+ Engineer, but soft skills often make the difference between good and great leadership. These skills help you align with others, build trust, and create a positive impact beyond just code.

1. Stay Aligned with Authority

One critical soft skill is ensuring alignment with your manager or leadership team. Avoid surprises by keeping them informed and providing context for your decisions. This transparency builds trust and ensures smoother collaboration.

2. Know When to Follow

Not every issue requires you to take charge. When deciding whether to lead or follow, ask yourself: Will this still matter in six months? If not, let someone else take the reins while you focus on higher-impact priorities.

3. Avoid Being Wrong

When someone seeks your advice, resist the urge to jump straight to an answer. Instead, ask three clarifying questions to gather context and better understand their perspective. This not only improves your response but also demonstrates respect for the person asking.

4. Create Space for Others

Leadership isn’t just about your voice; it’s about amplifying others’ contributions. Here are some ways to create space for your team:

Engage the Quiet Voices: Ask quieter team members for their thoughts during discussions, ensuring everyone has a chance to contribute. I’ve worked with an amazing developer who rarely spoke up in meetings, not because he lacked insight, but because he didn’t feel comfortable jumping into discussions uninvited. I learned that by directly asking for his opinion, he shared valuable perspectives that might have otherwise gone unheard.
Take Notes: By being the one to document meetings, you allow others to focus on active participation.
Make Decisions Visible: Share decisions publicly, like in a Slack channel, to encourage feedback and foster transparency.
Sponsor Others: Assign meaningful tasks to teammates, helping them grow and succeed while creating shared ownership.

5. Build a Strong Peer Network

Your network is your lifeline. Larson emphasizes the importance of three types of connections:

Internal: Peers within your organization who provide support and collaboration.
External: Professionals outside your company who offer fresh perspectives and insights.
Executive: Leaders and decision-makers who help bridge the gap between technical and business goals.

Remembering to build “in, out, and up” networks ensures you’re connected at all levels, both within and outside your organization.

Mastering these soft skills lays the foundation for technical leadership, but progressing to a Staff+ role requires more than just interpersonal growth. It demands a clear strategy, intentional career moves, and a focus on high-impact initiatives.

Climbing to Staff+: The Path to Growth and Impact

Reaching a Staff+ Engineer position requires intentional effort, a clear plan, and a willingness to tackle significant challenges. Staff Engineer outlines several key strategies for navigating this journey:

1. Create a Promotion Packet

Work with your manager to define what success looks like. Ask yourself: If I were promoted in 1-2 years, what accomplishments would justify it? Once you have this clarity, focus your efforts on these areas to ensure measurable progress.

2. Find a Trusted Sponsor

A sponsor is more than a mentor—they actively advocate for you in key spaces. Identify someone who understands your potential and is willing to support your growth by creating opportunities and vouching for your contributions.

3. Be “In the Room”

Being in the room matters because that’s where key discussions and decisions happen. To get there, you need to provide something valuable to the people already in the room—something they don’t already have or know. This could be a unique insight, a fresh perspective, or specialized expertise. Importantly, having a sponsor in the room who knows you and understands your goals can make a big difference. They can help open the door and ensure your voice is heard.

4. Make Your Work Visible

Contribute meaningfully and ensure your impact is recognized. This doesn’t mean overshadowing others but rather documenting and sharing your contributions in a way that highlights your value.

5. Take on a Staff+ Project

High-impact projects can showcase your ability to lead and deliver, but it’s important to note that not every organization requires these for promotion. While it’s always good to look for meaningful challenges that help you grow, don’t chase projects purely for the sake of promotion. Focus instead on initiatives that align with your goals and provide real value to your team or organization.

Lifelong Learning and Staying Energized

One of the most inspiring lessons from Staff Engineer is that learning never stops. The best engineers are those who continuously seek out opportunities to grow, both technically and personally. Here are some takeaways that stood out to me:

1. Learn from Your Network

Staff Engineer highlights the value of building a strong network of people you respect and learn from, while also giving back. Relationships thrive on mutual support, sharing knowledge, and collaboration. For me, this means turning to mentors, past managers, or experts for guidance while contributing to their growth in return. A strong network fosters continuous learning and fresh perspectives.

2. Focus on Solving Meaningful Problems

Many engineers find motivation and fulfillment by tackling serious, unaddressed challenges. Instead of spreading yourself thin across smaller tasks, commit to solving the problems that truly matter. This not only amplifies your impact but also deepens your expertise.

3. Learn What Energizes You

One of the most resonant lessons from Staff Engineer is the emphasis on focusing on what excites you. Many of the interviewed Staff+ engineers in the book echoed this sentiment, each in their own way. Pursuing topics you’re genuinely curious about leads to deeper understanding and sustainable growth, while trying to learn everything often causes burnout.

Reflecting on this, I realized I’ve fallen into the trap of feeling obligated to master countless topics, many of which weren’t critical. The knowledge I value most came from exploring areas that truly interested me. This approach keeps me energized and motivated. For more on avoiding burnout, check out this article I wrote a few years back.

Conclusion: Building Your Own Path

Staff Engineer by Will Larson isn’t just a guide for becoming a better engineer—it’s a roadmap for aligning your career with your values and aspirations. From understanding the archetypes of leadership to mastering the art of strategy and vision, the lessons in this book offer something for every IC striving to grow and make an impact.

Reflecting on my journey, I’ve realized the importance of focusing on what truly matters—whether it’s solving meaningful problems, building strong relationships, or prioritizing learning that energizes me. These insights have not only clarified where I stand but also highlighted the areas where I can grow further.

If you’re an IC aiming to grow your career, I encourage you to explore these ideas, reflect on where they resonate with you, and create your own actionable path forward. Which of these lessons stood out to you the most? Let’s discuss in the comments! For more insights, check out StaffEng.com.

Developing Self Compassion: An Answer to the Constant Burnout

Omri Lavi — Fri, 16 Jul 2021 12:17:14 +0000

In the last few years, I developed an efficient routine to improve my abilities as a developer. I contributed to open source, read a lot, wrote blog posts and was active in social networks. Yet, I had a constant feeling that it's not enough - that I'm not good enough. I thought I had to keep working hard, otherwise I'll go downhill.

At some point I realized I was very stressed, and that I was concerned all the time, and that I couldn't rest properly. I couldn't accept positive feedbacks and found reasons why they are wrong. Generally speaking, I was very hard with myself. At some point I became aware of this situation and decided to make a process to change it. Now, a few months later, I feel much better with myself. I wanted to share my process, so that it will help others out there in similar situations.

Feel like you're working hard and it's still not enough? Are you unhappy with your job even though it's pretty good? Are you generally stressed about your value as a developer? This post is for you. Take a few minutes to read through - you'll get a new perspective.

My Previous Routine

In the past, I had a strict daily routine. It aggregated to the following weekly agenda:

Reading a tech book - 1.5 hrs/week
Side projects, open source or writing - 10 hrs/week
Reading and keeping up to date - 3 hrs/week

Usually, if I had spare time, I spent it on side projects or reading. I didn't rest.

I learned a lot and created a lot of content. I was confident my work "pays off".

Stressful free-time activities. (Image by Tim Gouw)

When Cracks Start to Show

With time, I noticed some things about myself:

I was always stressed.
I couldn't rest properly.
I was very sensitive to issues at work, and they influenced my mood.
Even though I got positive feedbacks, I wasn't able to accept them. I found reasons why the feedbacks were wrong, and gave myself negative counter-feedbacks.
I had "tunnel vision" when encountering issues. I couldn't see the "big picture". I was too busy being concerned how I'll be perceived.
I constantly swung between finding flaws in myself and in the environment (the company, the process, my coworkers).
I thought about work day and night. I enjoy thinking about technical challenges, but this was a different experience. It troubled me where I was wrong, and what will my coworkers/supervisor say.
I had a very strong imposter syndrome. I felt less professional than my surroundings and was afraid people will find out about it.

For a long time I thought that this is the price for having a good job, and that I have to accept it. I thought that if I'll learn and do more, I'll feel better with myself, since I'll be "more professional". I remember telling myself "you can learn more, instead of resting in the evening - spend the time by reading some more". So I pushed it a little more.

The Awakening

In 2020 Covid came along, and a personal disaster happened about at the same time. I started thinking about how I spend my time and what I sacrifice. I realized that the routine I'm having was taking its toll. It led me to some serious thinking about my goals and their prices.

I talked about this a lot with my wife, who is — luckily — a personal consultant. This led me to a decision to make a change. I adjusted my goals, determined to be happier.

Now, these are some big words. What does being happy even mean? Don't worry, this post won't get a spiritual twist 😜

"Happiness" a profoundly personal definition and will differ for each individual. For me, I wanted to have a balance between:

A challenging and rewarding day job.
Time to spend with my family and friends.
The ability to maintain my hobbies.

Or in other words: retaining a good job, without allowing it consuming all my energy, all the time.

I started a process to achieve my new goals.

Becoming Aware

Monkey observing itself in the mirror. It's time for reflections. (Image by Andre Mouton)

My process took part in two seemingly orthogonal parts. The first one is simple: I reduced the "extra" time I spend (side projects, reading, etc.) to an acceptable minimum. I still spend time, but considerably less. But, this isn't enough by itself. I can't "switch off" the part of my brain which constantly judged and said "it's not enough".

This was the second part, which required some more work. I observed at my thoughts and feelings about not being good enough. I noticed the following:

I thought I needed to know everything. I was afraid of encountering the unknown since it felt like a test. Each time someone else knew something I did not, I felt very bad. "I should have known this" was a common thought. On hindsight, I tried avoiding the unknown by trying to learn as much as possible.
I was very concerned with how I'm perceived. This made me feel occasionally under test (even when I wasn't). When struggling with a technical issue, the soon-to-come feedback troubled me more than the issue itself.
I had unrealistic ideals. I know a few very successful individuals, and I take them as role-models. Yet, unconsciously I thought I can have all the positive aspects from my idols (writing blogs, contributing to open-source...), without having any of the negative aspects (the sacrifices).
I understood that my ideals made me very judgmental about myself and my surroundings. When things didn't go as I imagined I became upset. It could have been something in the workflow, or a coworker that didn't see things as I do . The gap between my ideals and the reality made me believe (sometimes) I don't fit.
Almost all my feedbacks were positive. This part is important - my feelings about not being good enough were not based on any external feedback. Objectively, I was doing ok.

After learning about my thoughts and feelings, I started making cognitive changes.

Changing the Narrative

To achieve my goals, I needed to cognitively change the way I think. This may sound abstract, and it's easy to be cynical about it. However, it is feasible with a lot of hard work.

I accepted I CAN'T have it all. I'm no superman. I adjusted my ideals and "lowered the bar".
I remind myself where I'm doing OK. I don't have to be overwhelmingly great, being OK is good enough. I allowed myself listening to external positive feedbacks.
I decided to gain meaning from myself, and not my surroundings. If negative feedbacks show up, they shouldn't affect my self-esteem. Having areas that need improvements don't make me a bad developer.
I accepted I can't know everything. Learning is great. But, naturally, it is not possible to know everything. It is GUARANTEED I will bump into things I don't know, and someone else will. No one can escape this scenario. This led me to an important understanding. Professionalism is measured not only by what you know, but how you learn what you don't know.
I accepted that people have different values than me. Sometimes I have opinions of how things "should be", that weren't in line with my coworkers' opinions. In times where I couldn't convince my colleagues, I felt very bad. Instead, I now allow myself letting go of some of my ideas. "Chasing" them and trying to make them happen at all cost was frustrating.
I accepted my judgmental nature. When a judgmental though came to my mind, I noticed it, and labeled it as such. I doubted it instead of accepting it as is. Eventually, I could separate cases where things are truly "bad" or rather they just don't match my ideal (which is my problem). I moved from a passive point of view ("This is bad" or "I am bad") to an active point of view ("Should this be improved? Can I improve it? What can I do?").
I decided to spend less time "learning" and "pushing myself forward". Instead, I spent some time with non-work things. I learned to juggle. I improved my chess skills. I exercise more. I even play more PC games (an extreme luxury in the past).

Now, I know what you're thinking. "Huh, that's a one way street for becoming a mediocre developer, or worse". Is it so?

Slowing Down ≠ Stopping

Naturally, this change may slow my career progress. However, the pros beat the cons. I don't feel stressed, and I'm more energetic. Non-work activities were more enjoyable. I'm more concentrated at work, and I solve problems quicker. When incidents come up at work, I'm much more calm and focused. Innovative ideas come to my mind more often, and I have time to implement them. I learn and create because I want to, not because I have to. Once you realize you don't really chase anything - the meaning of speed matters less.

A walking person enjoying the view. It's not a race, you won't "win" by going faster. (Image by Emma Simpson)

Conclusion

Being a developer is very demanding by itself. On top of that, each person in the dev community has something to say about what you should learn, and what you should do. FOMO is inevitable, and it's easy to feel bad (or simply not good enough) with yourself.

I wanted to share my story, maybe it will help other devs with similar feelings. My main message to you is: Relax, breath. Remember to slow down sometimes. You're doing alright 🤗

On a more personal note (if that's even possible), it was very difficult to me for write on such a personal topic. I'd love to hear your thoughts about this - feel free to approach me at any way (comments, DM, emails - you name it)

Better Error Messages in TypeScript 4.2 - Smarter Type Alias Preservation

Omri Lavi — Sun, 28 Feb 2021 19:05:18 +0000

TypeScript 4.2 was recently released, with many cool new features and improvements. It's really impressive to see how TypeScript improves the developer experience one step at a time.
In this short post we will focus one feature, called Smarter Type Alias Preservation. I can say for myself that I really anticipate this feature. In a nutshell, it improves error messages related to union-types of union-types. I hope that in a few minutes you'll understand better what it means, and why it is useful.

^{Don't get lost when unioning types. (Photo by Emily Blincoe)}

So What's the Problem?

Until TypeScript 4.2, when using a union type which contained at least one union type, the compiler "flattened" the types. In simpler terms - you couldn't tell which types the union-type holds. Consider the following simplified example, where the type of the parameter a is a union of two long types and undefined:

type LongType1 =
'type1' |
'type2' |
//...
'type19';

type LongType2 =
'_type1' |
//...
'_type19';

function myFunc (a: LongType1 | LongType2 | undefined) {
  return a;
}

myFunc('bummer'); // Argument of type '"bummer"' is not assignable to parameter of type '"type1" | "type2" | "type3" | "type4" | "type5" | ... 33 more ... | undefined'.(2345)

It's very difficult to understand this error: Where are these string literals coming from? Which type should I be looking at? What's the rest of the 33 more valid values? This can cause a lot of confusion and frustration.

What's New?

TypeScript 4.2 is going to make your lives easier in this aspect. Smarter Type Alias Preservation makes TypeScript "remember" which union-types are being used while displaying the error messages. Instead of flattening the union-types, their alias will be preserved and shown. See the same code from the previous example, compiled with TypeScript 4.2.

type LongType1 =
'type1' |
'type2' |
//...
'type19';

type LongType2 =
'_type1' |
//...
'_type19';

function myFunc (a: LongType1 | LongType2 | undefined) {
  return a;
}

myFunc('bummer'); //Argument of type '"bummer"' is not assignable to parameter of type 'LongType1 | LongType2 | undefined'.(2345)

As you can see, TypeScript "remembers" that "type1" | "type2" | ... | "type19" is actually LongType1, and that "_type1" | "_type2" | ... | "_type19" is LongType2. TypeScript indeed got smarter with type alias preservation! The error is much more intuitive, so now you can shift your frustration towards something else.

As Daniel Rosenwasser mentioned in the announcement, these improvements were made possible by two pull requests, by Anders Hejlsberg (PR1 , PR2). I will not get into the implementation details here. However, I encourage you to skim through the changes in src/compiler/checker.ts, or the pull requests' descriptions.

Wrap Up

TypeScript 4.2 will bring many exciting new features. One of which is the Smarter Type Alias Preservation, which will make certain type-errors much more informative. I hope that now you have a better grasp of this feature's meaning. Union-types have never been better!

Git Metric - Solving the Pain of Measuring a Project Migration

Omri Lavi — Sun, 14 Feb 2021 16:21:03 +0000

The Pain of Measuring a Project Migration

In the past few years I've had the chance to participate in ongoing project migrations like AngularJS to React, or JavaScript to TypeScript. Such migrations are usually incremental and take time.
In most cases, it's hard to analyze what's the status of the migration:

Are we keeping a certain velocity, or are we slowing down?
Do we obey defined rules, like stop adding AngularJS files when migrating to React?
Which developer contributed the most to the migration?

Enter Git Metric

In an attempt to help with such questions, I've recently published a small utility called Git Metric. I believe it can help tracking the progress of most project migrations.

If you are in the middle of a project migration, Git Metric can be useful for you.
With Git Metric you can quickly analyze git repository's history within minutes. Simply define the metrics you want to track (like specific file extensions, or a certain keywords in specific files) - and get a complete and holistic view of your project. You can find more details here.

I'd love to hear your thoughts about it 😄