One of the crazy things about being an engineering manager or senior/staff/principal engineer is the breadth of skills required to be effective at your job.

One minute you are leading a standup call, then next leading a Sev 2 incident across a couple teams, the next having a 1:1 career coaching conversation, then next writing out some missing docs for yo…

Read more

How many times have you felt defeated or frustrated after they’ve repeatedly failed to get buy-in for important work or ideas you have to improve the product/systems?

Yeah, me too.

At times it can feel like all your leadership team does is shoot down ideas, or say they’ll try to get to them next quarter.

In today’s article, you’ll learn how to break though the roadblocks the “we’ll do it next quarter”s and endless back and forth with decision makers. Including:

• Why great ideas often fail to get buy-in

• The language barrier between tech and business

• Building compelling technical proposals

• How to get buy-in from decision makers

I’ll end with a real-life story from my experience of how I got buy-in for a new library/vendor in the midst of our startup being acquired that helped us successfully land a new multi-million dollar client under an insane deadline.

Let’s dive in 👇🏼

Why great ideas fail to get buy-in

The top reasons I’ve seen good ideas or projects fail to get prioritized are:

• Lack of buy-in from decision makers

• Failure to connect the ask to a business need

The first two are related. Often you can’t get buy-in from decision makers because you are failing to connect your ask to a business need.

I’ve heard so many engineers have a similar conversation:

Engineer: There is some tech debt in x/y/z area, we really need to address it, the code is super messy and the cyclomatic complexity is very high.

PM/EM/Director: Ok, thanks for bringing it up. We’ve got this important project or set of tickets we’ve got to land right now, but let’s try to carve out some cleanup time in Q4 for that.

6-18 months later a big incident happens…

Director: This is insane, how did we not know about this land mine in our system?

Engineer: I told everyone several times, but no one listened.

Director: oh wait… is this related to that tech debt issue you mentioned last year? You didn’t tell me things had gotten worse since then. I would have prioritized this if I had known the impact this could have had on our systems / customers.

Engineer: No one ever listens to me until its too late.

This type of thing or similar happens all too often, and its a lose, lose for everyone involved. The engineer is constantly frustrated that no one listens to them, and then things blow up, and the director feels like they can’t trust the engineer to watch out for their business and systems.

The language barrier between tech and business

The above exchange is a clear example of a language breakdown between tech and business. The more senior you want to be as an IC or engineering leader, the more important it is to your success and your team’s success to bridge gaps between business, product, and engineering.

Without it, you’ll never earn the trust, buy-in, or opportunities from decision makers you need to take on large projects, new ideas, or complex re-architectures that are key to your future career, and your team’s success.

Business leaders care about their products, their customers, and their bottom line. Most engineers care about their code, their systems, and likely their products and customers, but in a less direct way.

The best engineers I’ve worked with learn how to bridge the gap between their goals and perspectives and the businesses goals in order to be successful.

But Caleb, that’s not my job!! I shouldn’t have to tell my leaders why technical debt is important to tackle. They should know that. I told them, why don’t they believe me?

Gosh, I feel you, and I’ve been there so many times myself. Now that I’ve been a technical lead for a couple yrs, and more recently an engineering manager, my perspective has changed a bit.

Connect your ideas and needs to business needs

Here’s what I’ve come to realize:

Those who work hard to understand the business, the product, customers needs and pain points, and even financial incentives of the business and learn how to connect that to their work are leaders.

These engineers are the ones who get promoted into leadership roles whether they ask for it or not. They are the ones that get the big projects and opportunities that end up giving them even more in the future.

Taking that extra time to bridge the gap, pays off for you and your team – even if it’s not technically your job.

Find out what your leadership cares about, and meet them there with compelling ideas that will crush their goals, and help you and your team in the process.

Building compelling technical proposals

Alright, let’s look at our earlier example, but with our new perspective:

Engineer: There is some tech debt in X and Y areas. I’ve talked with few team members, and even though Y has a lot of messy code, it’s annoying but manageable, it’s not a great investment to spend time there.

Where I think we really need to focus is this scaling issue I’ve started to piece together after we’ve gotten several new alerts popping off over the last couple weeks. They were dismissed as unrelated, but I pulled together this dashboard showing they are not anomolies, and our two biggest customers are affected weekly. What’s worse, with our three new customers landing the problem will get 2-3x worse likely leading to a large production issue.

EM: Wow, thanks for bringing that up – we’ve gotta have someone start looking into that. What would it take to fix this issue?

Engineer: I’ve talked to a couple other staff engineers and drafted a rough plan. I’d estimate with 2 engineers spending 3-4 weeks, we’d be in good shape. I’d recommend we land this high priority feature we’ve been working on, and then pivot into this new priority issue. Here’s my draft tech spec – I’d need another couple days to finish up and break out tickets, but I can have it ready for our next sprint if you agree we need to jump on this.

EM to Director: We’ve got to switch priorities in our next sprint. We’ve identified a large production bottleneck affecting our two largest customers, that would also block successful onboarding for new our customers if we didn’t tackle it. The team has a plan and will be ready before they land, but we’ll need to delay launching that other feature we had planned for a few weeks.

Director: Wow, thanks for highlighting before we had a huge outage. Done and done, please get to work! I’ll communicate with our brands and support team, and reshuffle our next quarter a bit. Who did you say found this again?

6-18 months later… new brands successfully land, new scaling records are hit

EM: I want to chat about you pursuing a staff role. The way you consistently looked out for our future needs and anticipated the needs of our systems and business is so valuable. Leadership is constantly raving about you…

That example is not too far off from reality for many engineers who now find themselves as staff, principal, or even engineering directors.

It’s not necessarily the best coders who have the most impact. It’s engineers who can drive important cross-team efforts connected to large business or product impact, and say no to the endless other things vying for their attention.

This is only going to be more true as ai continues to take on more of the raw day to day coding work.

How I learned this with 3 months to prove it works

We'd just been acquired when a multi-million dollar client needed enterprise RBAC features in 3 months. Features that would normally take 12-18 months to build.

We had basic user roles. They needed enterprise-grade permissions, user groups, and document sharing.

The client was about to sign, but needed all the features in 3 months. So like all good startups, we jumped in headfirst and said yes 😅.

I was the lead on the project, and quickly realized building all of those features in-house would take at least 12-18 months.

I found an amazing paid library that could get us there in time, but it had red flags: newer startup, no SOC 2 certification, and new tech to our org. Meanwhile, our new parent company's security team was pushing their own internal tool that wouldn't actually work for our needs.

I built a stakeholder proposal covering everything our leadership team would need to make the decision: why internal tools wouldn't work, vendor pricing and scaling, SOC 2 timeline, customer references, and exactly how much revenue this would unlock.

I walked into the meeting, presented the high level overview – plus handed in a 35 page doc of all my research if they wanted more details.

I patiently worked through all their questions and objections, and 20 mins later walked out with a signed contract and a new vendor/library in our hands!

Later my EM reached out and said I really impressed our VP. The VP said I made it so easy for them to make a decision they could be confident in. I had done all the hard work, it was just up to them to make a call either way.

Hitting the 3 month timeline was still insane, and we didn’t launch without any hiccups – but we did succeed in the end. Shoutout to some amazing all star engineers on my team who did most of the engineering work to pull it off.

It was a massive win for me, for our team, our business, and our products.

I really believe that project was a key part of the puzzle that led to my promotion from engineer to manager, and really unlocked a new level of thinking, cross-team collaboration and execution that continues to be a big part of my success in this field.

The Compelling Technical Proposal Checklist

Use this checklist to ensure your success as you prepare for stakeholder meetings when pitching large efforts you want to get prioritized:

Read more

As Senior+ engineers, coding is only about 30% (if we are lucky) of how we spend our time.

With ai handling more and more of the raw coding part of our job – what’s left for…

Read more

Breaking the Staff Engineer Ceiling Series

Are you wanting to break through to Staff+ Engineer levels but tired of vague career ladders and unclear expectations?

In parts 1 & 2 of this series, we explored what Staff Engineers do and how they operate. Today, (Director of Engineering at NuBank) goes deep into what transformed his career and helped dozens o…

Read more

About the author

Today we are joined by . He is a CTO, course instructor at Maven, and author of the newsletter with over 100,000+ subscribers!

Throughout his 12-year career in engineering, Gregor has gone all the way from Software Engineer, to Senior Engineer, to Team Lead, to Head of Engineering, to VP of Engineering to CTO.

I’m excited for him to share…

Read more

In the first part of our discussion, we explored the core expectations — the “what” of staff-engineering. What defines the Staff-Plus level, common expectations across companies, and the key gaps that often cause Senior Engineers to get stuck.

If you missed part 1, you’ll want to check it out here: https://levelupsoftwareengineering.substack.com/p/breaking-the-staff-engineer-ceiling

Now, let's shift our focus to the how: the behaviors that enable top performing engineers to make transformational leaps in their careers and help them scale their impact and influence in a sustainable way.

About the author

Thiago Ghisi is the Director of Engineering for the Mobile Platform team at Nubank. He has nearly 20 years of experience in the software industry, having worked at companies like Apple, ThoughtWorks, and Amex. He also hosts a podcast called "Engineering Advice You Didn't Ask For" and writes extensively about Career Growth & Leadership on both the IC & the Management track on LinkedIn & Twitter.

Alright, let’s dive in 👇🏼

Why is “behavior” so important for staff+ engineers?

When we talk about behavior, we're referring to the consistent actions and patterns that define how you approach your work and interact with others.

Behavior is not just about your technical prowess; it's about how you influence, lead, and drive outcomes within your organization. It's not just about what you know or your potential; it's about what you've actually done and how you consistently operate following that structure.

Ever wonder why companies place so much emphasis on behavioral interviews? Questions like "Tell me about a time you resolved a conflict with a peer" or  "Describe a situation where you influenced organizational change" or "Can you give an example of an innovative solution you developed?" aren't just fillers—they're windows into how you've navigated real-world challenges - your patterns of behaviors!

What you've accomplished before is often the strongest indicator of what you'll achieve in the future. These questions aim to understand not just what you are capable of, but what you have actually done. As the saying goes, "Past behavior is the best predictor of future performance."

When it comes to promotions, especially at the Staff-Plus level, companies typically promote based on demonstrated behaviors and achievements, not just potential.

To be promotable, you need to already be operating at the next level, showcasing the behaviors expected of that role - very similar to what you do in an interview for a different company. Promotions are often lagging indicators, recognizing that you're already performing at the higher level.

An amazing reference here is the book the effective hiring manager by Mark Horstman (co-founder of Manager Tools). It not only teaches you how to design effective behavior interview questions, but also shows you many examples of effective answers for multiple levels and job titles. Strongly recommend!

What strategies & behaviors do top-performing engineers apply to achieve promotions to staff-level & beyond?

Over the past eight years, I've participated in numerous promotion committees and performance calibrations in companies with Staff-Plus levels. This experience has allowed me to observe firsthand what works and what doesn’t.

Throughout this process, I've collected a lot of data on the behaviors and achievements that have enabled engineers to make transformational leaps in their careers (basically being promoted or rated as a top performer). 

From this data, we can see both positive behaviors that propel engineers forward and negative behaviors that hold them back. I believe they can help and guide those of us aspiring to be Staff-Plus Engineers.

To better understand these patterns, I've broken down the Staff-Plus promotions into three key transformational leaps:

1. Leap 1: From Senior/Lead to Staff

2. Leap 2: From Staff to Senior Staff

3. Leap 3: To Principal & Beyond

Let's dive into each of these leaps to explore the behaviors that make a difference.

Leap 1: From Senior/Lead to Staff

The first significant leap is moving from a Senior or Lead Engineer role to a Staff Engineer. This transition is about expanding your impact beyond your immediate team and taking on greater ownership.

Based on observations and data collected over the years, the key behaviors that enable this transition are:

1. Strategic Decision-Making

Being strategic isn't just about using the latest technologies or solving complex technical problems—it's about driving technical impact that aligns with the company's business priorities and goals. This means understanding the bigger picture and making decisions that propel the business forward. Many engineers mistakenly focus on technical solutions without considering whether they align with the company's direction. To stand out, ensure that your technical decisions support and enhance business objectives.

2. Effective Mentorship and Leadership

To scale your impact, you can't do everything yourself. As you grow, your role evolves from being solely an implementer to also being a leader and mentor.

This doesn't mean you stop coding or solving problems; instead, you guide others to do so effectively. You go from being a solver to creating other solvers in your organization.

Mentorship allows you to amplify your influence by empowering others to contribute meaningfully. Leading projects and ideas, and helping others grow, are critical behaviors that signal you're operating at a Staff level.

The canonical and most impactful read for me on this is Tanya Reilly's article: Having impact in engineering by supporting other people's ideas

3. Influencing Beyond Your Team

Staff Engineers have a broader sphere of influence than others.

You're not just collaborating with your immediate engineering peers; you're working cross-functionally with product managers, designers, customer support, and other stakeholders.

High-impact projects often require coordination across multiple functions, and being able to "speak multiple languages"—understanding and addressing the concerns of different stakeholders—is vital. This cross-functional collaboration is essential for delivering products and solutions that succeed not just technically but also in the market.

This is when you get to demonstrate your ability to influence strategically in decisions, mentoring and leading beyond one team. You show fluency distributing your time, determining where the organization needs you the most and navigating cross-functionally beyond engineering.

Leap 2: From Staff to Senior Staff

The transition from Staff to Senior Staff Engineer involves further broadening your scope of influence and taking on more complex challenges.

At this level, the key behaviors include:

1. End-to-End Leadership in Critical Initiatives

It's not just about strategic decision-making anymore; it's about leading critical initiatives that have significant impact on the organization. This means taking ownership of complex projects that are pivotal to the company's success and seeing them through from conception to completion.

2. Mentoring Across Multiple Teams

Your mentorship now extends beyond your immediate team. You're mentoring engineers across multiple teams, fostering growth, sponsoring people and projects and building capabilities throughout the organization. Your influence is broad and scalable, and you're instrumental in developing the next generation of technical leaders.

3. Operational Excellence and Sustained Impact

Consistency is key at this level. You're not just delivering one successful project; you're ensuring that teams consistently perform at a high level over time. Operational excellence involves establishing processes, practices, and cultures that enable sustained success of the entire company. You're contributing to the stability and reliability of systems and teams across the organization.

This is when you demonstrate you can go from building software yourself to building organizations that build software. You are directly involved leading each and every day.

Leap 3: To Principal & Beyond 🚀

The leap to Principal Engineer and beyond involves operating at the highest levels of technical leadership, often influencing entire business units or the company as a whole.

The behaviors that characterize this leap include:

1. Full Domain Ownership

As a Principal Engineer, You're not just influencing a team or a project; you're shaping the direction of significant portions of the company. Your knowledge and influence span across products. In a company like Google, that would be across YouTube, Google Cloud, Ads, or Search. This broad ownership requires a holistic understanding of the business and technical landscape.

2. Driving Innovation 

At this level, deep technical knowledge becomes a significant asset. You're leveraging your expertise to drive innovation, develop platforms, or create processes that have a transformative impact on the company. You're connecting the dots across different areas, introducing technologies or methodologies that propel the company toward ambitious goals.

3. Adaptive Mentorship

You are not only mentoring other engineers, you are mentoring other functions & levels. You are mentoring managers and directors. You are onboarding other Directors and Staff-Plus engineers. You are mentoring mentors to scale mentorship in the company. You are working with HR to select the Key Talents at the company level. You are part of the promotion committees. You have an input on the performance cycle. You shape the incentive structure of the organization.

At this stage, you're collaborating closely with executives, aligning technical strategies with business objectives. You're contributing to high-level decision-making and helping to steer the company in the right direction.

In many ways, as a principal engineer, you're operating at an executive level, bridging the gap between technology and business leadership.

What Are The Patterns Of Behavior Of Top Performing Engineers Across Levels?

Across all levels, certain behaviors consistently distinguish top performers who successfully advance through the Staff-Plus ranks. These are:

1. Strategic Influence & Ownership

Top performers drive technical and strategic decisions aligned with business goals. They anticipate future challenges and opportunities, positioning the organization to be proactive rather than reactive. This strategic mindset sets them apart.

Top performers don't just execute tasks; they understand the "why" behind them and ensure their work contributes to the company's success.

2. Leadership & Mentorship

Scaling your impact necessitates learning to delegate and develop others.

Effective leaders mentor their colleagues, helping them grow and enabling the team to achieve success more collectively. This isn't limited to one-on-one mentorship; it involves leading by example, guiding teams through projects, and fostering an environment where others can learn by observing and participating.

Leadership and mentorship are critical behaviors for anyone aspiring to advance to Staff levels and beyond. Top performers recognize that their success is tied to the success of their teams.

3. Technical Excellence & Innovation

While deep technical expertise is important, what's more impactful is how you use that expertise to drive innovation.

This means not just being technically proficient but also leveraging your skills to create meaningful change, introduce new ideas, and push the boundaries of what's possible within your organization.

Top performers stay abreast of industry trends, continuously learning and pushing the boundaries of what's possible. Their technical leadership inspires others and elevates the entire organization.

Common pitfalls that prevent talented engineers from progressing in their careers

Just as certain behaviors propel you forward, others can hold you back. Based on my experience and observations of promotion cases that were declined or where engineers received poor performance ratings, the following patterns emerged:

1. Lack of Strategic Vision:

Engineers who fail to align their work with the company's strategic goals often find themselves stuck.

You might be working on technically impressive projects, but if they're not aligned with the company's priorities, they can become distractions rather than assets.

I've seen engineers who spent months optimizing a system that had little impact on the business, while critical projects languished. Their lack of strategic alignment was a significant barrier to advancement.

2. Inability to Delegate & Scale Impact:

If you're unable to delegate tasks and scale your impact through others, you'll struggle to expand your influence beyond your immediate work.

Staff Engineers are expected to work across multiple teams and initiatives. Holding onto tasks and not empowering others limits your ability to take on larger responsibilities.

Developing leadership skills and learning to trust and rely on others is essential for advancing to higher levels.

I once worked with an engineer who was brilliant technically but struggled to let go of details. He micromanaged projects, which frustrated his team and limited his ability to take on larger responsibilities.

3. Poor Stakeholder Management & Communication:

If you're unable to collaborate with product managers, designers, support teams, or other departments, it will hinder your ability to deliver high-impact projects. Managing dependencies, negotiating priorities, and articulating technical challenges in terms that resonate with different audiences are critical skills. Without them, advancing to Staff levels and beyond becomes significantly more challenging.

I've observed engineers with excellent technical skills but who couldn't effectively communicate with non-technical stakeholders. This disconnect often led to misunderstandings, stalled projects and their managers being constantly overwhelmed having to oversee projects that the Staff should have been able to manage on their own.

Action Items:

To wrap up this section, here are some actionable steps to help you apply these insights:

1. Role Models Over Checklists

Rather than focusing on ticking off items on a career ladder checklist, find role models who embody the qualities you aspire to. Observe how they operate, handle challenges, and influence others.

Early in my career, I was fortunate to work with a Principal Engineer who became a mentor. Watching how he navigated complex situations, I learned invaluable lessons that no checklist could provide.

Instead of relying solely on career ladder checklists, seek out role models within your organization. Identify individuals who exemplify the behaviors and skills you aspire to develop. Ask yourself:

• Who are the top individuals who have inspired my professional growth?

• What specific skills or qualities do they possess that I need to develop?

Observing and learning from real-life examples can be far more powerful than trying to tick off items on a generic list. Focus on emulating the behaviors that have led others to success in your specific context.

2. Key Limiting Behaviors & Skills

Everyone has at least one behavior that may be holding them back. Seek feedback from peers, managers, and mentors to identify areas for improvement. Focus on developing these skills to remove barriers to your growth.

If you read What got you here, Won't get you there, you will know the key insight of the book:

Everyone has at least one behavior that holds them back more than anything else they do. Identifying and addressing these limiting factors can have a significant impact on your career progression.

Reflect on the blocking patterns discussed earlier:

• Do you lack strategic alignment in your work?

• Are you struggling to delegate and scale your impact?

• Is stakeholder management or communication a challenge for you?

Prioritize improving in these areas before focusing on developing new skills. Removing these blockers can accelerate your advancement more effectively than adding additional competencies.

3. Inside-Out Growth Perspective

While it's valuable to learn from external sources, focus on understanding the expectations and success patterns within your own organization. Conduct informational interviews with those who have been promoted to understand what it takes to succeed in your specific context.

Every company has its unique culture and expectations. Rather than importing ideas from books or external sources, focus on understanding what success looks like within your organization. It won’t be the same for every team or company where you go.

Conduct informational interviews with colleagues who have recently been promoted or who are operating at the level you aspire to reach. Ask them:

• What does a typical day look like for you?

• How do you manage your time and responsibilities?

• What were the key factors that contributed to your promotion?

• Who was the most critical sponsor for your promotion?

• If there was one, what was the "Staff Project" (more on part III) that got you promoted?

By gaining insights specific to your company's context, you'll be better equipped to align your behaviors and efforts with what is recognized and rewarded internally.

Again, not every company or team values and rewards the same thing. And what a team or company needs and values will change over time.

Advancing to a Staff-Plus Engineer requires more than just technical expertise. It demands a combination of strategic thinking, leadership, mentorship, and effective communication.

By understanding and embodying the behaviors that drive success, and avoiding common pitfalls, you can navigate the transformational leaps in your career and scale your impact within your organization again and again! 🚀

Well that’s all for this week.

Thanks so much Thiago for diving deep and sharing your insights on staff-plus expectations. I personally learned a lot! 🙌🏼

What stood out to you from today’s deep-dive? Did anything ring true from your experience? Did anything surprise you? We’d love to hear from you in the comments!

As always, you don’t have to wait until the next newsletter to hear from me. You can catch me daily on LinkedIn where I talk about everything software engineering, startups, and growing in your engineering soft skills.

– Caleb 🚀🚀🚀

Not every company you work for will need and value the same things.

Seems like a no-brainer right? Well here’s what surprised me: Your company and team won’t always value the same things. Things will change.

Learning how to grow, adapt, and thrive in the new structures, values, or processes will help you standout and be considered first for new opportunities.

Sticking with how you’ve always done things won’t always work. It will leave you frustrated, and likely feeling stuck and passed up on for opportunities.

My story: from startup to acquisition to scale-up

Things have changed for me a lot over the last 3-4 yrs – while being on the same team the whole time.

4 yrs back, we were a high-growth startup. We were 3-4xing our revenue every year, and we 3x’d our headcount one year.

The name of the game was innovation, building new products, and moving fast.

We were moving so fast things were being sold into contracts that hadn’t been built yet. Several times I found out a client was onboarding in 3 months, and needed a new product or feature that would’ve normally taken me 6-12 months to build.

Part of our magic was figuring out how to deliver value in the quickest time possible.

One example is an email campaigns tool we built.

Initially our design team had some amazing designs, but after reviewing them, I realized it would take us at least 6 months to build the custom drag-n-drop email editor they had dreamed up.

I realized this might be an instance of over spending on things that are not a unique part of our value proposition, and would really hurt our time to market.

I took a look at all the pre-built plugins and editors out there and found one that checked all the boxes for our goals. However, It was several thousand dollars a month.

When I told my boss, he said: “2-3 grand a month, but I don’t need my dev team working on it for 6 months and maintaining it forever? That’s cheap. Let’s do it.”

What first started as a 6 month project, I was able to deliver in 6 wks because our priorities were time to market, and meeting our customer’s needs quickly.

I learned how to thrive in this startup environment. Move fast, break shit, fix shit was our motto. And for a long time this worked and helped us win! 🚀

Enter the change event

Here’s where things get interesting and where people either rocket-ship their growth or start to feel frustrated and stuck.

Let’s call it: a change event.

Something changes that requires new ways of working or new areas of focus.

For me the change event was a company acquisition. For you it might be teams merging, new team members joining/leaving, acquiring a new massive client, etc.

Whatever that big change is, it can often surprise us with how much changes and we can start to feel like we are losing our touch.

If we go back to my personal example, we were acquired, and for a while things continued on as normal. The company that acquired us was happy to keep us innovating and building amazing products quickly and eat up new market share.

However, after a while the cracks started to show.

Our new parent company was known for reliability, stability, and solid products.

In this new world, our clients aren’t necessarily looking for mega speed and innovation. Move fast and break shit doesn’t fly the same with large enterprise clients. They want to know their system will be up without issues, and they can come into work without worrying about a bug or outage.

But how to you go from move fast and break shit to stable, reliable, scalable while still delivering new value to customers? That’s not a switch you can flip overnight.

A lot of it has required new processes, new thinking, new ways of building, etc. All the while not just disappearing for 2 yrs while rebuilding everything.

At it’s worst this “transition” has felt like hitting the breaks in the middle of the race. It’s jarring, unexpected, and leaves a bunch of grumpy / confused drivers.

At it’s best it’s feel inspiring and like we can finally clean up all the old tools and dust that’s accumulated in the workshop for the last few years.

Why does this matter to me?

Ok Caleb, that’s cool – but how does that apply to me? I’m not being acquired…

Totally hear you, but from what I’ve seen our industry has and is going through massive changes. We are beyond the “hire at all costs and throw money at engineers to retain them” phase of tech.

So many of us have lived through various big “change events” the last couple yrs.

Ai going mainstream, big tech layoffs, new company unicorns, flatter org structures, etc.

In this environment it’s easy to be confused, to wish for the good old days, or just want to throw in the towel and move on.

Read more

When it comes to staff engineering, the old management saying, "What Got You Here Won't Get You There," couldn't be more accurate.

This article is part 1 of a series on staff-plus engineering. In this series, you will learn:

1. What defines the Staff-Plus level, common expectations across companies, and the key gaps that often cause Senior Engineers to get stuck.

2. Critical behaviors that distinguish high-performing Staff-Plus Engineers from their peers that help them scale their impact and influence in a sustainable way.

3. "The Staff-Plus Flywheel" – Practical strategies for scaling personal impact through mentorship, sponsorship, and strategic involvement in projects.

This series is really a peak behind the curtain of what it takes to really be get promoted, and be impactful at the staff-plus level.

Today we’ll be jumping deep into part 1.

About the author

Thiago Ghisi is the Director of Engineering for the Mobile Platform team at Nubank. He has nearly 20 years of experience in the software industry, having worked at companies like Apple, ThoughtWorks, and Amex. He also hosts a podcast called "Engineering Advice You Didn't Ask For" and writes extensively about Career Growth & Leadership on both the IC & the Management track on LinkedIn & Twitter.

Thiago has helped over 30 people get promoted, including 10 engineers to staff-plus levels through coaching and mentoring. He’s also done more than 350 interviews as a hiring manager and seen first hand how top performers get hired, onboarded, and become a top-performer. He’s also spent hundreds of hours on promotion committees and performance calibrations.

It‘s clear he knows his stuff.

What does it mean to be a Staff-Plus Engineer?

These are the top questions I hear often as an engineering director.

• What does it mean to be a staff-plus engineer?

• What are the expectations to get to Staff Level?

• What do Staffs do for their practical day to day work?

• What is a good Staff Engineer? What is a bad Staff Engineer?

• How do I get there? I heard about all the different archetypes..."

The first thing that we really need to understand is not necessarily what's directly written on a companies ladder, but, actually, what is around it and the expectations everyone has in their head when they see someone that has a Staff title.

In order to understand that disconnect, I need to go back in time. 

History of engineering career ladders

If we go back 10 to 15 years ago, most companies had a career ladder where you grow from junior to senior, and then you were effectively stuck, unless you became a manager.

That was a pattern that we saw for decades before we finally got the creation of the dual-track career ladder. This new dual-track ladder is a win-win for everybody.

Senior ICs that were unable to grow after a certain level now had a path, and motivation to keep sharpening their skills and their craft.

For companies it was also a win, as it gave them a powerful retention and performance calibration tool. Now “super star seniors” that were impacting more areas, projects and teams across the company could be fairly compensated for their impact and scope, instead of getting frustrated and leaving the company.

The creation of this actually revolutionized not only the IC track, but also the management track: it provided more clarity in terms of progression, scope of responsibility and the equivalence of impact across the tracks.

With that history understood, in my experience, what clearly defines what a staff is:

• Someone that's not sitting on a single project or on a single team.

• Someone that's overseeing an area that's bigger than a particular project or team.

• Someone that is working directly or indirectly on and with multiple projects/teams at the same time, usually reporting to a leader that has a broad scope. 

The main thing that matters in most companies to get and to stay at the staff-level is not how deep you know a piece of technology or a layer of the stack, it is your SCOPE of impact and influence on the organizational surface.

I'm not saying that your technical, architectural and decades of intuition in software engineering aren't relevant, they are. But, they aren't what really moves the needle.

Yes, in some core platform teams you might have a handful of staff engineers working on really hard problems that have super broad implications company-wide as part of a single team such as databases, networking, security, provisioning… but those cases are super rare.

Even in the cases a Staff-Plus is part of a single team, their day to day involves a lot of work and coordination to impact and influence many teams across the organization.

In order to be effective, they still need to be managing and influencing stakeholders, talking to the customers, planning ahead what they are going to prioritize to build and why over the next year, etc…

To this point, Staff, Senior Staff & Principal Engineers often report to someone that is at least one level higher than them in the org chart. Staffs tend to report to Senior Engineering Managers, Senior Staff tend to report to Directors and Principal Engineers tend to report to either Senior Director or VPs.

Staff engineers are part of the engineering leadership team and have cross-team responsibilities beyond their direct scope. They are responsible for building bridges and paving paths between the tech teams and the business, even if they are a true expert on a single topic. 

There is only one problem with that definition…

Variations of titles/expectations across Companies:

What is the main problem with my definition above? Title, Levels and Expectations vary a lot across companies as you can see below.

Titles are almost always meaningless. The same title could be a completely different level and have completely different expectations in different companies.

This is especially true in periods of hyper growth in the industry (as we have seen recently from 2020 to 2022) when “Title Inflation” tends to happen a lot more, especially when moving from a big/mid-size company to a small/startup.

Here is an example, using the fantastic website levels.fyi. See how a Staff Engineer (IC7) at Nubank, the company I worked for, maps to Principal at Microsoft and even to Senior in other companies.

Levels FYI tries to help answer the question “what level would I transfer into if I were switching companies?” They use leveling rubrics, and map similar scopes and responsibilities based on the information across hundreds/thousands of companies.

What are the core expectations for achieving & maintaining the staff-plus level?

Let’s get into the main focus of this article.

There are the 3 things I found again and again that if you do consistency will make a top Staff-Plus Engineer at pretty much any company.

Interestingly, these are also the 3 things I've seen struggling Senior Engineers completely neglecting or being unaware of. 

Do them well, and it's going to be almost unavoidable to be promoted to Staff-Plus level at some point. 

Staff-plus expectations across all companies:

1. Blast Radius

2. Multi-Scale Planning

3. Ownership Level

1/ Blast radius: Scope & Shape of Impact

There’s this idea that you need to have a wide impact. As a staff engineer, your 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.  

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 – eg. the blast radius of impact of what they are doing.

In my view, yes, technical depth is important. But I see a lot of people dropping the ball on blast radius by not impacting the broader organization.

The reason why I chose blast radius, and not only high impact, is because there are different shapes of blast radius.

You can have an impact on something that's deep, 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 first expectation for staff-plus. Again, it’s usually a red flag if you are only working on projects that only involves a single team or repo, and never expanding beyond that.

Image from ’s fantastic article called "Beyond Staff Engineer"

For having a 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 operates and has profound implications on that particular business area.

On both angles, you impacted the company as a whole if you were able to fundamentally change how things were done in a product or product line; or improve the revenue or cost structure or the customer experience of the broader company.

Look for ways to make a high-blast radius impact from a business perspective.

2/ Multi-Scale Planning: Ability to Influence

Many people talk about the importance of Big-Picture Thinking, emphasizing that staff engineers should focus on the next two to three quarters. I agree with that.

Where I see a lot of people dropping the ball on is understanding how those long term plans and visions come into play. How do they 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 weeks to eventually the next few years. 

For example, at the Principal and Director Level, you're expected to be a year or more ahead planning the roadmap, removing risks, etc.

At every level I see a lot of people who don't understand how to cascade things from the day to the week to the quarter in how the organization dynamic actually works.

The graphic below outlines how we go from Offsites → OKRs → Planning Meetings → Monthly OKR reviews → Weekly Team Syncs → Daily Work & Meetings.

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 Tiago Forte (@fortelabs). 

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 are not only thinking about the next few years of visionary ideas, but also how they will work with/within the organizational structure to make those ideas a reality.

A common mistake made by seniors

One common mistake among senior engineers is over-reliance on short-term solutions. That often looks like an intense two-week projects to solve some of the biggest organizational problems single-handedly. 

This approach is unsustainable, and can lead to burnout.

Instead, most of the time, our focus as staff-plus engineering leaders 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 / Deliver Results

The third key staff-plus expectation is Ownership. Ownership is another organizational expectation that, again, is not usually clear on a career ladder or matrix.

Where I see a lot of people get this wrong comes back to the idea of implementers, solvers, and finders.

The canonical article called "Implementers, Solvers, and Finders" outlined the differences between these types. Here’s an excerpt:

Do you find that most of your time is simply closing tickets, and your team rarely considers your input? Your title is Solution Implementer.

Are you given general problems and left to your own devices on how they’re fixed? When brainstorming, is your input considered by your teammates? You’re working as a Problem Solver.

Are you given near-total autonomy in choosing what you work on? Can you tell your boss “That’s an interesting idea but my time would be better spent elsewhere” (and not get fired on the spot)? You’re a Problem Finder.

At the start of one's career, you are an Implementer, tasked with executing specific instructions and replicating given solutions, examples or patterns. You are given a TASK and "the HOW" to do it.

As you advance to a senior level, you become a Solver. Someone gives you a problem, and you go and you figure out how to solve it. There is not clear HOW. 

The next critical level is the Finder. Not only do you solve problems but also anticipate and identify future priorities and challenges for the organization.

This is someone that is not only solving different shapes of problems, but is someone that's thinking ahead of time, and is finding the next priorities, the next things, the next set of problems that the organization needs to focus on.

Common ownership mistakes

A common mistake I see is that some professionals stop at being Solvers. They never transition into the Finder role, perpetually remaining a solver.

The other common mistake I see is that some Finders become untethered to the reality of actually resolving problems. They move into 100% finding problems mode, throwing them over the fence to others: "There is this problem here… We're going to get blocked here. etc." And they don't help any further. That is not true Finder.

In reality, you never entirely stop being a Solver or Implementer.

The most effective Staff Engineers are not only able to go back and forth on the different horizons of time, but also roles and levels of ownership. 

They 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 on tasks.

Mastery in these dynamics ensures your effectiveness and value within an organization.

Driver: The missing ownership level

A staff-plus engineer it is not only someone that implements, solves or finds new and existing problems, but someone that is able to drive key projects to conclusion.

A driver is someone that knows when to step in and dive deep, vs just watching from the outside. It is someone that is there as a safety net for the organization making sure the priorities are still being reflected or slightly adapted as reality sets in.

A driver is the person that might prioritize that incomplete database migration while slow rolling a big project because they know that once the migration is complete everything will be easier.

As a driver, you aren’t doing project management quite in the same way an engineering manager is doing, but you're almost an executive that is trying to make sure all the important things are getting done.

Action Items:

If you feel stuck in your career, or just overwhelmed with all the theories around how to move to the Staff-Plus level, these action items are for you.

Let’s dive into some really practical ideas for Blast Radius, Multi-Scale Influence, and Ownership that should help you unlock that staff-plus level in your career. 🚀

Also – stay tuned for part 2 next week where we are going to be discussing critical behaviors that distinguish high-performing Staff-Plus Engineers from their peers that help them scale their impact and influence in a sustainable way

You won’t want to miss it!

1. High Blast Radius Impact

Here are some questions to ask yourself:

1. Are you working on projects that are actually going to move the needle and create a huge blast radius of impact across the org, or you're working on "feels-good snack-tasks"?

2. What was the last initiative you worked on that extended beyond your team or your codebase? What was your most impactful deliverable in terms of blast radius?

Side-note: Will Larson has a fantastic article on this topic called Work on What Matters where he talks about among many things avoiding snacks, and stop preening & chasing ghosts.

Snack tasks may offer quick wins and a sense of accomplishment, but they often lack significant, long-term impact. To make a meaningful contribution, you need to intentionally steer toward projects that cascade across the org, affecting not just your immediate team, but other parts of the business.

Now, reflect on your recent projects.

• What was the last initiative you worked on that extended beyond your team or your codebase?

• What was your most impactful deliverable in terms of blast radius?

These are the kinds of endeavors that have a deep or broad impact on the business or product. They might take longer to materialize, but when they do, their effects are far-reaching. This level of impact often requires stepping back, thoroughly evaluating the scope, and resisting the urge to jump straight into solving smaller, less impactful problems.

Continually ask yourself whether your current work aligns with high blast radius outcomes.

While smaller tasks are sometimes necessary to keep things moving, your long-term focus should be on finding and executing on projects with substantial influence. Look for gaps in your current approach where you might be prioritizing easy wins over transformative results, and adjust accordingly to ensure you're contributing at the highest possible level.

2. Multi-Scale Planning Influence

Here are some questions you should be asking yourself:

• Can I work ahead of time to add things to the annual roadmap, influence stakeholders, or negotiate dependencies?

• How am I influencing my department with my vision?

• Can you work ahead of time, like planning dependencies, helping to shape the roadmap for the year?

• Can you work a quarter or like a half (6 months) ahead of time? When have you done that?

• How are you influencing the department and your group beyond your squad with your vision? 

To operate effectively at a staff-plus level, it's essential to build your ability to influence long-term planning and vision. This requires working ahead of time, anticipating dependencies and helping to shape the annual roadmap.

This requires more than just executing tasks; it means aligning your projects with the organization’s broader goals, influencing stakeholders, and negotiating across teams.

If you can successfully work a quarter or more in advance, shaping not only your team’s focus but also contributing to the overall strategic direction, you’re functioning as a high-impact engineer.

To do this, you need to influence both your department and stakeholders with your vision. Ask yourself, how often do you proactively add items to the roadmap or ensure your dependencies are addressed in other teams' backlogs?

It’s not just about technical solutions but about aligning initiatives with business priorities and helping guide the future direction of the organization. This ability to see the bigger picture and bring others on board with your ideas is what sets a staff engineer apart.

As a staff engineer, you need to understand how the next year's priorities for your company don't come out of the blue out of the CEO's mind on Dec 31th. They are extremely predictable if you are paying attention to the right rituals and to the right people. 

Learn how company-wide priorities are set and how they cascade from leadership down to your team.

Your ability to influence this process can greatly impact the organization’s direction. Whether it's advocating for a re-architecture or pitching a new technology, the skill of shaping discussions and building alignment around your vision is critical. 

If you are not doing it yet, start to use your one-on-ones, write proposals, and continuously influence peers and leadership to ensure your vision is part of the roadmap for the coming year and beyond.

3. Ownership & Autonomy Levels

Here are a few helpful questions to think through:

• What is the percentage of my time I'm working as an Implementer vs. Solver vs. Finder vs. Driver?

• Is this the ideal allocation for my next level? If not, how can I get closer to that?

You need to be careful with that ratio. Because if you are 100% as an Implementer, or 100% as a Solver, you're not going to get through staff-plus impact and influence. 

Staff engineers need to spend more time as finders and drivers—proactively identifying issues, risks, and opportunities that others may not see.

Really stop and ask yourself: What percentage of your time is allocated to each of these roles? Be honest, if you're spending most of your time as an implementer or solver, it's unlikely you’re reaching the level of impact necessary for staff-plus.

Consider whether your current role-ratio allocation is aligned with the expectations of the next level. At higher levels, you need to take ownership of finding and driving initiatives that shape the roadmap, influence cross-functional teams, and unlock new opportunities for the organization. 

Sometimes, short-term priorities require a heavy focus on implementation, but over the long term, the ideal balance shifts toward finder and driver activities should be there.

To move closer to that next level, you must deliberately shift your focus with an intentional calendar to cultivate the skills necessary to take on more ownership and autonomy.

Focus on building the skills and behaviors associated with higher levels of ownership and influence. Regularly ask yourself: What is the highest-leverage thing I can do this week or month to maximize my impact across the organization? 

The key to achieving staff-plus is mastering the balance between solving problems and proactively driving initiatives, all while developing the autonomy to shape the future of the organization.

Well that’s all for this week.

Thanks so much Thiago for diving deep and sharing your insights on staff-plus expectations. I personally learned a lot! 🙌🏼

As always, you don’t have to wait until next week to hear from me. You can catch me daily on LinkedIn where I talk about everything software engineering, startups, and growing in your engineering soft skills.

– Caleb

In last week’s article I shared: How I grew from Senior Engineer to Tech Lead. It’s my story of breaking beyond senior engineer, and what life is like as a tech lead. Highly recommend reading if you missed it and are interested in going beyond senior!

I know a lot of us engineers hit senior engineer or tech lead and then wonder what’s next for our career. Should we go into management to get paid more and learn some leadership skills?

Maybe like me you’ve heard that you are good with people and projects, so you would be a good manager.

But what would it look like? What would it take to get there?

I’ve asked those questions so many times over the last 3 yrs or so.

Today I wanted to share my journey from Tech Lead → Manager and why I chose to go that route instead of towards Staff Engineer.

Again, if you missed last week’s article, check it out here: How I grew from Senior Engineer to Tech Lead

Let’s dive in 👇🏼

Why move to Engineering Management instead of Staff Engineer?

Great question. I’ve asked myself that very question many times.

A staff engineer once told me: “Caleb, you are such a great engineer, don’t waste all that skill on being a people leader.”

For me it’s engineering is more than just coding.

Early on in my career I had a really toxic boss who made things difficult for everyone on the team. It felt like I had to fight them to do my best work.

They forced poor technical decisions on the team, disappeared for weeks when we needed input, and constantly gossiped about other team members behind their back.

Later on I joined a startup, and had the opportunity to be managed by an incredible engineering leader. She was smart, empathetic, supportive, and pushed me to be better. She completely transformed my view of management.

I started to see that good managers don‘t just “schedule meetings”, do 1 on 1’s, and plan out projects. She showed me that good managers:

• listen well

• value honesty

• empower all equally

• are open to change and improvements

Good managers also:

• encourage the team to bring their whole self to work

• are force-multipliers that help their team level up and thrive

• are concerned with their ICs success even outside of the company

• care about people as humans, not as machines that make products

Having this kind of partner, cheerleader, and support was life-changing for me.

She challenged me to take on difficult challenges, to own my growth and go hard after new possibilities. It hasn’t been easy, but having that support and incredible management helped me break beyond senior and level up in new ways I didn’t know were possible.

It made me want to be that for others.

That’s why I’ve jumped head-first into this management track.

My goal is to be that authentic, supportive, transparent, force-multiplying leader for others.

I have a very long way to go still, but I’m excited to be on this learning journey.

How I went from Tech Lead → Engineering Manager

My last manager was awesome, but they were severely overworked and managing 20+ engineers across 4 teams at once. 😅

I started looking for things to take off their plate that would save them time, and give me the opportunity to help in a leadership role.

Some of the things I helped take on were:

• Sprint planning

• Mentoring new engineers

• Quarterly OKRs and Planning

• Meeting with external partners and clients

• Running projects and managing up on status / outcomes

After 3-6 months of this, I had a conversation with my manager about looking to grow into a manager, and mentioned that I’d love to lead one of their current teams.

It was out of the promotion cycle, but because of the business need and my desire + proving myself in various responsibilities, it happened!

It was a win, win for all parties involved.

I got to move towards my goals. And the company gets a manager that’s already earned the trust of the business - and has all the context of the projects, tech, business and ICs on the team. ✅

A hell yes for all involved!

How can I replicate what you did?

If you are looking to grow into a leadership role, here’s several things that worked for me + others I’ve talked with:

1. Find something you can take off your managers / tech lead / staff’s plate

2. Ask if you can own it so they can focus on higher priorities and give you a chance to grow and stretch your leadership skills. 

3. Do those things amazingly well. 💪

4. Keep them updated to build trust and confidence that you are owning it well. 🤝

5. Continue to grow your responsibilities and thinking as you take on more and more ownership and leadership in various areas

6. Bring up promotion with your manager and show all the areas you’ve been taking on ownership and impact above your current level

7. Work on any feedback they share and continue to repeat “The Magic Loop.”

You’ll need to be patient as a promotion into a leadership position – EM or Staff – will take a while and need business funding + justification.

What have you learned from your first 9 months as a manager?

As a new manager I feel like I started over… and I’m learning that’s completely normal!

People management is much different than even technical management as a Tech Lead. I knew that in theory from reading and coaching sessions, but I’m now experiencing the reality of that in my day to day work. 

Here are 7 of my biggest learnings so far:

1/ Forming and Storming is Normal.

Anytime you introduce a team change – adding a new team member, a new manager, or doubling the team size + a new manager (as in my situation) – you are going to form, storm, and norm before you are a high-performing team.

During this season, you need to lean into growing together as a team. Figure out what works well for the new team. Learn what new processes are needed because of the new dynamics or tasks you are working on.

Change. Passionate disagreements. Joys. Going in Circles.

All normal when a team changes.

Don’t be like me and be surprised by this. Things might just get crazier before they get better.

2/ People are your new job. People are not tech.

As a recovering people-pleaser, passionate disagreements and difficult conversations are uncomfortable to me. My tendency is to want to pull away and hope they go away.

What I’ve learned through experience is that ignoring them will just make things worse.

The only way to improve is through.

You can’t avoid hard conversations. They are literally your job. Lean into them. Listen with the intent to understand. Build trust with your team.

I won’t be able to make everyone happy – that’s not my job.

But I can help us work towards a healthy culture of learning, growth, and failing or succeeding together. It’s all about healthy teaming now.

3/ Mentorship is huge. 

One of the most helpful things to me these last 6+ months have been other EMs and engineering leaders I’ve been able to chat with and learn from.

There've been so many times where I felt crazy, or wasn’t sure if what I was doing was a good direction. 

They’ve been able to remind me things like:

• My job is not to get people to like me

• Strong disagreements can actually be healthy

• I’m building a team and a system, not a Caleb does everything checklist

• Change takes longer with teaming, review progress every 3 months, not every 3 days

I know many of these in theory, but when someone can come alongside and remind me, or point to a situation I did well or could improve in, my eyes are opened and I level up again.

I’ve also started learning a lot from reading engineering newsletters by leaders. Here are a few of my current favorites:

• and – co-write the newsletter

• – writes the newsletter

• – writes

• – writes ’s newsletter

• – writes the newsletter

• Level Up by Ethan Evans (not to be confused with Level Up Software Engineering 🚀– which I write 😅)

• – writes the newsletter

• – writes newsletter

• – writes the newsletter

Before they were all just theory. Now that I’m in the role, I devour them weekly and seek to apply what I’m learning.

Learning + doing + more learning + more doing = Leveling Up 🚀

4/ Public praise goes a long way for your team.

Thanks for reading today’s paid article edition 🔒! Every paid article has a free section that is valuable enough for some, and deep-dive content for those really looking to level up 🚀.

If you are a paid subscriber, enjoy the rest of this deep-dive where we talk about planning work, mental health, how to stay technical with less / no coding time, and event more resources for learning! 👇🏼

Read more

Should we go into management to get paid more? Or should we continue down the IC track, and find a company that will pay / promote us to a staff level?

I’ve asked those questions so many times over the last 3 yrs or so, and now I’m actually doing it 😅

I’ll be sharing my journey from Senior → Tech Lead → and eventually Engineering Management. I hope it’s a help to you and inspires you to continue on towards your goals. 🚀

This week we’ll dive into Senior Engineer to Tech Lead.

In last week’s article I shared 15 ways to Supercharge your Career Growth, I’ve learned after 10 yrs of working as an SWE. Highly recommend reading if you missed it!

Let’s dive in 👇🏼

From Senior → Tech Lead

Several years back, I was performing well as a Senior SWE and I remember sitting down with my manager and asking: “What skills do I need to develop to grow into a tech lead?”

I knew the tech lead role would be a good hybrid between a Staff Engineer, and an Engineering Manager but I wasn’t quite sure which path I wanted to take yet.

My manager shared that I had some work to do before becoming a tech lead, and wanted to see me also hit my Senior 2 promotion that year.

Here is a list of things I worked on towards both goals:

• Helping with onboarding

• Building out missing documentation

• Crushing all the projects assigned to me

• Being the go to person for answering product technical questions

• Giving strong and useful code/technical-spec reviews across my products

• Continuing to earn the respect of peers, PMs, EMs, and strategic staff+ level ICs

It took 7 months of incredibly hard work, but I made both the transition to technical lead as well as Senior 2 promotion that year with an exceeds rating (let’s gooo 🚀).

Life as a Tech Lead

Being a tech lead was one of the most interesting, fulfilling, and challenging things I’ve done in my career. It was similar to the work as a senior, and yet so different.

I often thought it would just be more coding, more mentoring…

But it turned out to be a whole different level of thinking and ownership than I had taken on so far.

Being a new Tech Lead was really the first time I recognized that my main value to the team was not in writing the most code I possibly could. 

They no longer needed a hero-dev cranking out code 24/7… they needed a force-multiplier that could help everyone level up.

Some of the ways I did this included:

• Outlining areas of our infra that needed scaling / refactoring

• Guiding architectural designs through technical spec reviews

• Ensuring code quality though thoughtful and timely code reviews

• Working to onboard new engineers and help them get up to speed

• Helping EMs/PMs estimate effort in roadmapping and planning meetings

• Collaborating with staff engineers on architecture / tech debt improvements

• Being the go to person for answering technical questions in our product area

• Helping plan, design, review, and manage many different projects all at the same time

Responsibilities and focus of a tech lead

Whew that was a lot. So what really are the main responsibilities and focus for a tech lead?

If you want to be a successful tech lead, there are 4 main areas you’ll need to be proficient in. They include leveling up in several key areas including processes, communication and thinking.

You are part leader, part engineer, and part architect all in one!

A lot of these may be referred to as “soft skills”. I wish there was a better term for them, because some of them are harder to be good at than the “hard skills” we all usually focus on. 😅

1/ Technical mentorship: Emerge as force multiplier for your team

It’s no longer just about you. A lot of what you will do as a tech lead will be ensuring and supporting and guiding your team towards technical excellence.

Some examples include:

• Guide architectural designs through technical spec reviews

• Ensure code quality though through and timely code reviews

• Work to onboard new engineers and help them get up to speed

Slowly but surely something has become clear to me.

The more senior we become, the more important it is that we multiply our efforts and help others level up through mentoring. 

If I improve my coding abilities by 10%, the team gets minimally better. If I lean into being a force-multiplier and help 3-5 others level up, the whole team just got massively more productive and effective. My impact is compounded. 🚀🚀🚀

2/ Be a technical owner of your systems

As a tech lead you’ll be collaborating very closely with PMs, EMs, and other staff+ engineers. You’ll work together to own and ensure the success of your team and of your projects and systems.

Some things you’ll be involved in include:

• Collaborating with staff engineers on architecture / tech debt improvements

• Understanding how staffing and work assignment happens and be a contributor in sprint planning with your EM and PM

• Becoming the go to person for answering technical questions in your product area

• Helping estimate effort in roadmapping and planning meetings

One of the main differences for me as a tech lead was worrying less about the smaller details of code review / architecture like function names, API routes, etc, and being more focused on the architecture and design of our systems.

Here are some common questions I would think through:

• How did everything fit together in our system?

• Did we have good documentation for our core services?

• Do we have good coding patterns and strategies in place across our team?

• Are the architecture designs for new features maintainable and scalable?

I worked closely with staff engineers to ensure we were building reliable systems that were maintainable, well-designed that would meet our users needs. More on this below…

3/ Push for systems engineering quality

Read more

We all know a few engineers that just seem to “know everything.”

Whether it’s troubleshooting a slow query, tuning your alerts/monitors, mentoring a new junior on the team, spinning up a new microservice, adding a new frontend component, leading a complex project – they can do it all.

But how did they get there? How did they become so trusted? How did they grow their skills in all these different areas?

After 10+ yrs in software engineering, it’s become clear to me some traits / skills these top performers all share.

Work on even just a few of these 15 traits of top performaers to supercharge your growth and really stand out (no matter what level you are at). 🚀

Let’s dive in 👇🏼

1. Develop a bias for action

Amazon lists having a “bias for action” as one of its core leadership principles. They pride themselves on rapid innovation thanks to a culture of moving fast.

Having a bias for action means: if you are asking: “should I do something about this?” – the answer is probably yes. ✅

It doesn’t mean being impulsive.

It means: take calculated risks with the data you have, and failing fast to find the best solution quickly.

2. Never say: “that’s not my job”

There are times in your career where you’ll need to “wear many hats.” Maybe you are on a project with missing requirements and staffing and suddenly you are required to step into the role of:

• designer / devops / security / product / customer service

These are all roles/skills I’ve had to do over my 10 year career – that weren’t officially my job.

Because I was willing to jump in, learn, and help where ever needed, I’ve developed a better understanding of our products and our business from end-to-end.

This ultimately helped me become a more valuable contributor. 🌟

Note: Some companies are just toxic and will constantly ask for more and more from you until you burnout. If you recognize those signs, it’s time to leave.

(Almost) never say: “that’s not my job.”

3. Be trustworthy / reliable

Build your team’s trust by saying what you’ll do, doing it, and then showing you’ve done it.

If you become known for consistently delivering value, you’ll go far in a company.

If you are flaky, inconsistent, and don’t keep people informed on your progress, it will be hard for leaders to trust you.

They may pass you over for difficult projects that are key to your growth in the company.

This doesn’t mean you need to silently suffer to hit a unrealistic deadline.

Do your best, but if you can’t accomplish something on time – say something. Raise a blocker, and come with creative ideas on how to still complete the goal.

Keeping stakeholders informed, even when something is off track builds massive trust with them. They can count on you to reach out without having to constantly check in on where things are at.

4. Own your growth

Whether you are at a small startups without a career ladder or a large FAANG company with everything outlined, it’s important to own your own growth.

No one is going to promote you just because you’ve worked there for another year.

Even if your company has a clear career ladder outlined, it might not align with your life goals, or skillset.

Example: someone suggests you should be a manager since you are the best engineer on the team. Reality: you’d rather continue growing on the IC track.

It’s important to know your strengths and weaknesses, and where you want to go next, and drive towards it. Be proactive in pursuing your own growth path and development as a leader. Don’t depend solely on your company to do that for you.

5. Advocate for change, and lead the charge

Don’t wait for someone else to tell you what to do. Advocate for changes you want to see happen, then lead the charge.

Whether it’s documentation for easier onboarding, new auto-scaling infrastructure, or a more inclusive culture, be the change you want to see!

This is a great way to standout as an engineer, and help your entire team level up at the same time. 🚀

Make sure the changes you advocate for are inclusive and actually helps everyone – vs. just a personal pet peeve or preference. Otherwise people will see right through to your self-centeredness, and won’t rally behind your ideas.

6. Don’t overcomplicate processes

Read more

Like it almost takes 5-10 seconds on first page load on a very fast internet connection… imagine what it is for slower internet connections?

Slow apps frustrate users, and end up losing companies a lot of money and customers over tim…

Read more

I’ve created a Docker Cheat Sheet that will help you remember and master all the most used Docker commands, and write your own Docker files!

We go over:

• What is Docker?

• Why do we need Docker?

• Basic Docker concepts

• Dockerfiles

• How to start and interact with Docker containers

• How to manage multi-container Docker applications

My goal is that this will be something you can bookmark and return to whenever you need a docker refresher, or can’t quite remember a command.

Today’s content will be more technical in nature than usual. If you enjoyed this / found it useful, let me know in the comments, and I’ll do more technical deep-dives in the future!

My goal as always with this newsletter is to help you grow both your soft skills, and your technical skills so you can hit that next level in your career.

Alright, let’s dive in! 👇🏼

First off: What is docker?

Docker allows you to isolate an application with all its dependencies, configuration and code into lightweight and portable boxes called images. It’s like a shipping container.

Based on these docker images, your docker containers can be created and started.

If you are familiar with object oriented programming, you can think of an image as a class, and a container as a class instance.

Why do we need docker?

Docker eliminates the common problem of "it worked on my machine", by providing a contained environment that runs the same everywhere. It gives you the confident of running your app in a virtual machine, without all the overhead.

Docker containers can do something VMs can’t. They can be packaged & shipped directly to production environments to simplify development & deploy pipelines.

It gives you the confidence that the environment you built and tested in locally, will be the same environment the code will run in on production.

Basic Docker Concepts

Here are some basic Docker terms you should we understand before we jump in to using Docker in your apps.

Image

A docker image is a read-only template, or set of instructions used to create a container. Docker images can be built from scratch or based on an existing image.

Container

A container is a lightweight, portable, and self-contained executable package that includes everything needed to run an application. Containers are isolated from each other and from the host system, which makes them an excellent choice for deploying applications in the cloud and other environments.

It will contain all your code, packages, libraries, etc.

Dockerfile

A dockerfile is an instruction file for taking a Docker image and building it into a container. It is used to automate the building of Docker images and ensure that they are consistent and reproducible across different environments.

Network

A docker network is primarily used to communicate between various docker containers and the outside world via the host machine where the Docker daemon is running.

Docker Compose

Docker compose is a tool for defining and running multi-container Docker applications, called services. You use a YAML file to configure the services, that can be created/started/stopped with a single command.

Docker files

Remember: A dockerfile is an instruction file for taking a Docker image and building it into a container. It is used to automate the building of Docker images and ensure that they are consistent and reproducible across different environments.

Dockerfile keywords

Here are some common Dockerfile keywords you should become familiar with:

• FROM: specifies the base image for the Dockerfile.

• RUN: executes a command in a new layer on top of the image and commits the changes.

• ADD/COPY: copies files from the host to the container.

• CMD: specifies the default command to run when starting a container from the image.

• ENTRYPOINT: configures the container to run as an executable.

• ENV: sets environment variables for the container.

• EXPOSE: specifies the network ports that the container listens on at runtime.

• VOLUME: creates a mount point for a volume.

• USER: sets the user for the container.

• WORKDIR: sets the working directory for the container.

Dockerfile example

Now let’s see what docker commands look like in practice.

Here’s a basic docker file for nodejs. The comments throughout the file will walk you through each line/command and what they are doing.

Thanks to Sid Palas for the helpful thread on docker files that this example file is based off.

# Pin node version for stability
# Pull an image from the docker hub repository
FROM node:19.4-alpine

# Set NODE_ENV
ENV NODE_ENV production 

# Specify a working directory
WORKDIR /usr/src/app

# Copy only files required to install dependencies
COPY ./package.json /www

# Install only production dependencies
RUN npm ci --only=production

# Use non-root user
USER node

# Copy source code AFTER installing dependencies
COPY --chown=node:node ./src/ .

# Indicate an expected port
EXPOSE 3000

CMD [ "node", "index.js" ]

Docker Container commands

Remember: A container is a lightweight, portable, and self-contained executable package that includes everything needed to run an application.

Here are some helpful commands I use on a daily basis to interact with docker containers.

Create and start a new container

You can specify the image to use, set environment variables, and map ports between the container and the host system.

docker run [OPTIONS] <image-id-or-name> [COMMAND] [ARG...]

List all running docker containers

You can see details such as the container ID, image used, and port mappings.

docker ps

View logs for a running container

docker logs <container-id-or-name>

Stop a running container:

You can specify the container ID or name to stop.

docker stop <container-name>

Remove a container:

docker rm <container-name>

Execute a command in a running container

Use this to execute a command in a running container, such as rolling back a migration, or copying a file.

docker exec -d <container-name> yarn knex migrate:rollback

Create an interactive shell on a running container

Use this command to exec into a running container which you can then perform commands on/in it.

docker exec -it <container-name> sh

Docker compose

Remember: Docker compose is a tool for defining and running multi-container Docker applications, called services. You use a YAML file to configure the services, that can be created/started/stopped with a single command.

Docker-compose file

Docker compose allows you to manage multi-container Docker applications.

It’s used to define and run multiple containers as a single service.

• First you’ll need to write the Dockerfile(s).

• Next you’ll create a docker-compose.yml file to build images based on the Dockerfile(s)

Here is an example docker-compose.yml file:

Read more

I had one core project I was leading. My main job was to plan the project, and deliver it successfully.

As I grew into a Senior+ engineer, and then Tech Lead, things became a bit more challenging. I had 3-4 projects I was giving technical guidance on. I couldn’t just go heads down on one priority.

I spent 6+ mont…

Read more

I had one core project I was the project lead on. My main job was to plan one project, and deliver it successfully.

As I grew into a Senior+ engineer, and then Tech Lead, things became a bit more challenging. I had 3-4 projects I was giving technical guidance on. I couldn’t just go heads down on one priority.

I s…

Read more

In my career, it took me a while to realize that focusing only on coding would only get me so far.

When I hit senior engineer, I thought that cranking more on coding and crus…

Read more

Do you ever end your weeks thinking: “oof! What did I even do this week…?!”

“It’s been a week since my last pull request, and I’ve been trying to knock out that bug for the entire last sprint…” 😫

“I signed up to code – not to sit in endless meetings…”

I’m nodding along as I remember all the times I’ve felt this way.

Why do we feel that way?

As engineers we tend to measure our productivity by how much code we wrote, or how many Jira tickets we moved to done.

But as we move into more senior, staff, tech lead, principal and team lead positions, we start writing less and less code.

Less coding / tickets leaves us feeling like we didn’t get anything done. 🤪

Our workload shifts from mostly coding, to mostly…. meetings?

Are tickets/coding the only value we contribute to our team?

Is that what’s expected of us by our managers? Is that what we expect of ourselves?

I’ve wrestled with these questions a lot as I transitioned into a senior+ engineer, then a tech lead, and now a team lead.

So what’s the solution?

Slowly but surely a new way of looking at it has become clear to me.

Coding isn’t the only way we contribute value.

The more senior we become, the more important it is that we become force-multipliers on our team. 🚀

Before you close the article – thinking Caleb has been paid off by all the managers trying to get their team to sit in endless sprint ceremonies and zoom meetings… 😉

Think about it for a minute…

If I focus really hard this year and improve my coding by 10%, the team gets a little better overall.

If I instead lean into becoming a force-multiplier and help 3-5 others level up, the whole team just got massively more productive and effective.

My influence grows, my efforts are compounded, and my impact grows. 🚀🚀🚀

And these are all massive parts of how the success of a staff engineer are measured.

How to think about productivity

I’ve always tried to reserve 30% of my time for coding. Coding is always an important part of our job – there’s no question about that. It’s just not the only or even the main way we can have impact.

We have to start thinking bigger picture than just ourselves, and not just focus on being the best coder on the team.

As a senior+ engineer and tech lead on my team, my job is to impact and influence in a bigger way than just building a lot of cool shit.

You are uniquely positioned on the team to make an outsized impact based on your experience, systems knowledge, relationships, expertise, etc.

Here are some unique ways I’ve personally leaned in to make an outsized impact on our success as a team.

Force-multiplying ways to increase your impact

1/ Break down knowledge silos

Find areas of missing or outdated documentation and build them out so that others don’t have to rely on your as a single-point-of-failure for knowledge.

Brain dump what you know so you aren’t irreplaceable.

2/ Give through, timely and helpful code reviews

You can have and outsized impact by giving really through, thoughtful, and helpful code reviews for projects your team is working on.

Use your scaling, architecture, design-systems, and testing knowledge to help others write code that will be performant and maintainable for the long run.

3/ Mentor junior engineers in our patterns, and systems

One of the best ways to grow as a team is to help others level up. Mentor eager juniors in your patterns and systems so they can become more effective contributors.

Soon they will be out-coding you!

4/ Tackle bugs or pain points that are plaguing the team

If there’s a bug or local development issue plaguing your team, diving in deep to fix it can really improve the productivity and output of your team.

Focus on areas you can uniquely unblock projects/teams/processes.

5/ Write and review technical specs to ensure good design

There’s nothing worse than a new project launching and it immediately becoming hard to maintain due to bad architecture, scaling issues, or poor data structures.

Writing and reviewing technical specs for new projects is a great way to help level up the quality of products you ship, and have a massive impact with only a few hrs of effort.

6/ Help estimate effort in roadmapping and planning meetings

How many times have you been given a project and told you have 6 wks to build it, when in reality it’s a 3 month project?

Yep – me too. (the worst was a 12 month project, sales had told a client we’d have finished in 3 months)

By partnering with business and engineering leaders, you can help get ahead of “pull numbers out of a hat” and provide more thoughtful estimations for level-of-effort to build a new project or feature.

You’ll develop valuable estimation skills, and learn how the lifecycle of projects / products are built.

…

These six force-multiplying activities have helped me influence and impact people and projects forward on a whole different level than only coding.

For you they may differ based on your skills and your teams unique needs.

But the end result is the same.

If we measure our productivity by value contributed to the team and the business goals – it’s actually improved vs. if we focus on being a solo hero-dev.

How can I measure my non-coding impact?

The reality is: A lot of our force-multiplying impacts are harder to measure. We can’t necessarily just throw everything into sprint tickets to track. This is another thing that leads us to feeling unproductive.

One practice that’s really helped me is keeping a daily + weekly summary journal.

Daily: I write 3-5 bullet points of ways I helped the team move forward.

Weekly: I roll these up into a short summary of wins/learnings.

Monthly: I summarize larger team and project impacts into a separate brag doc of my accomplishments and areas of growth and impact.

I then take that weekly journal and send it to my manager and product partners.

Doing that has had so many wins for me:

1. It highlighted problem spots in processes and projects

2. It started great conversations on where I should focus my time

3. It gave my manager a way to lean in and help mentor me more effectively

4. It helped give me a renewed sense of impact, productivity, and see the more abstract wins I was having

If you’d like a template to start your daily/weekly journal, paid subscribers can grab a template with examples at the bottom of this post. 👇🏼

Conclusion

Days with hrs of back-to-back meetings are still hard. That hasn’t changed.

I think there are real things we could do to reduce some of those – but that’s for another article.

There are still many days I struggle to find enough time to code. But my feeling of getting nothing done is slowly going away.

I’m on a journey re-wiring my brain to realize I’m still contributing huge value even without coding as much.

Days where I don’t code can still be massively successful and impactful if I’ve been a force-multiplier. 🚀

How about you? How do you think about contributing as a senior IC / manager when you aren’t coding as much?

Reply to this email! I’d love to hear from you. 🙋‍♀️🙋‍♂️

Until next week 👇🏼

Catch me daily on LinkedIn where I talk about everything software engineering, startups, and growing in your engineering soft skills.

– Caleb

P.S. The paid newsletter option includes access to my entire archive of posts, templates (like the Weekly Journal Template + Examples in today’s newsletter), and access to our new monthly book club (more details here) 📚.

Subscribe today to get even more resources to help for your engineering journey 🚀

Subscribe now

Read more

This week, I’m interviewing Jean Lee, Founder of Exaltitude, and one of WhatsApp’s first engineers.

If you aren’t familiar, WhatsApp was an incredibly successful startup, and was eventually acquired by Facebook/Meta for $19 billion. Yes, billion dollars. 💰🤯

She has tons of helpful content on her Exaltitude YouTube channel for …

Read more

Have you ever had an experience like I have?

Me: “Can I get that promotion? I completed all my projects on time and it’s been 2 yrs of being in this role…”

Manager: “Hmm… I not quite sure you are ready… plus budget this year is tight. Let’s talk about it next year.” 🙃

Oof. Again, I’ve been there and it’s both confusing and frustrating.

Let’s try something …

Read more

Some of my biggest learning moments have been learning together with other growth-minded engineers/leaders.

I want to give you that opportunity to learn together by joining us for a monthly book club!

The first book we’ll be reading together is: The Software Engineer’s Guidebook by – author of .

It’s one of the best books I’ve read on software engineering, and really feels like the missing guidebook our industry needs.

Here are the details if you’d like to join us!

• Time: 8-9pm EST / 5-6pm PST

• Cadence: 2x / month on Wednesday

• Book: The Software Engineer’s Guidebook

• Chapters discussed per meeting: 4

• Total meetings: 7

• First meeting date: March 20th at 8-9pm EST / 5-6pm PST

• Meetings include: Facilitator top highlights, lean coffee style group discussion, questions and more!

And guess what?! We’ll be having some of my favorite engineers / engineering leaders join in on the fun to help lead weekly discussions and share their learnings.

• Jordan Cutler , senior engineering and author of the High Growth Engineer newsletter

• , staff engineer, and author of the

• , director of engineering, and prolific writer/thinker

This is an amazing opportunity to learn and grow with some amazing engineering leaders in our industry. 🙋‍♀️🙋‍♂️

Here’s how to join us!

1. Join the paid subscriber list

2. Reply “Book club” to this email

3. Grab a copy of the book

4. Read the first 4 chapters of the book before our meeting

5. Join the call on Wed. March 20th at 8PM EST to learn with others and participate in the discussion

   1. (I’ll send a cal invite out to to all my paid subscribers)

If you can’t join the call live, don’t worry, I’ll send out a summary of the discussion via email so you can catch up after the fact.

If you aren’t a paid member yet, grab a subscription and join us! You won’t want to miss this! 🙋‍♀️🙋‍♂️