The Staff Engineer Path

The Big Picture

What would you say you do here?

A staff engineer needs to take decisions that have a lot of impact in the company, I need to know a lot of technologies and their trade-offs. When doing it right means going slower, teams that are eager to ship may skip testing, cut corners, or rubber-stamp code reviews. Teams need senior people who have honed their skills, who have seen what succeeds and what dails, and who will take responsibility for creating software that works.

No matter what the standards say, if the most senior engineers don’t write tests, you will never convince everyone else to do it.

As you increase in seniority the impact that you will have should be greater and greater.

Your reviews of code or designs should be instructive for your colleagues and should make your codebase or architecture better.

The role is to make sure the organization has a good technical direction. Do the things the good way or just writing down somewhere as a technical debt.

Get very clear what the scope is and do always 10% more of what is asked.

Senior people do a lot of things that are not in their job description, but what the project needs to be successulf.

Execution

Finite Time

Put nonmeetings in the calendar too. Having focus work scheduled in the calendar.

If I start this work, what am I not doing instead?

Having a dashboard of yourself that includes:

• Energy: understand what kind of work are expensive for you, and waht kinds will leave you with some smartbrain at the end of the days. We can do deep work just with a high energy level.
• Credibility: if you move entirely away from low-level technical problems, other engineers might distrust your technical judgement because they think of you as too disconnected.
• Quality of life: if you enjoy the kind of work you are doing and the people you are working with, that will be a boost to your quality of life every day.
• Skills: if you take on projects that teach you nothing, you won’t keep up with the rate of decrease. there are three main ways to increase the skill bar:
  • the first is by deliberately setting out to learn something through a book, a class or hack on a toy project
  • the second way is by working closely with someone who is really skilled.
  • the third is learning by doing.
• Social capital: if I help people I will increase my social capital.

It’s easier to choose a project if you have clear the long-term goal.

How many things are you already doing?

Notice when you are doing busywork because you are tired, and find a way to rest instead!

Leading big projects

The number one tool for success is writhing things down.

Create mental map that helps you navigate the project.

Here is how I start, no matter the size of the project: I create a document, just for me, that is going to act as an external part of my brain for the duration of the project. It is going to be full of uncertainty and rumors, leads to follow, reminders, bullet points, to-dos and lists.

BUILDING CONTEXT

Understand the goals, constraints, and history of the project; and being clear about how it ties back to business goals.

• Why are you doing this project?
• What do your customers need?
• How will you measure your success?

Respect what came before

CODING

Be an exemplar, but not a bottleneck.

Pairing shares knowledge and builds other people’s skills. Pairing also means you can dip in for the key part of a change, then leave your colleague to complete the work.

If you are reviewing code and changes, be aware of how your comments are received. Even if you think you are relatable and friendly, it can be intimidating for early-career engineers when a staff engineer comments on their work. You want the rest of the team to think of you as a resource to learn from, not as someone who criticizes every decision and makes them feel inadequate.

A staff engineer is an exemplar in another, more implicit way: whatever you do will set expectations for the team. For that reason it’s important to produce good work.

Leveling Up

You are a role model now

This is a blessing and the curse of a staff engineer: people will assume you know what you are talking about, so you’d better know what you are talking about! Your work will be a little less checked and your ideas considered more credible. Rather than guiding you, people will look to you for guidance.

You shape the company every day just by how you behave.

BE COMPETENT

Competence includes building (and keeping) knowledge and skills, being self-aware, and having high standards.

You can’t be a technical leader without the technical part. A big part of the value proposition of hiring you is your knowledge: you have seen some things.

Technical skills come from study and practice, they aren’t inherent. No one is born a skilled weaver; no one is born a skilled computer engineer.

Experience comes through time, exposure and study.

Never, ever accept a managerial role until you are already solidly senior as an engineer.

Being competent and knowledgeable doesn’t mean you have to know the most about every topic. Sometimes, when you come into a new domain, you will know the least, and that’s ok.

Competence is built on knowledge and experience, but you also need to be able to apply thos abilities!

Every time you admit you don’t know everything and let people see you learning, you show your junior engineers that it’s normal to continuosly learn.

Your standards will serve as a model for how other people work. Know what high-quality work looks like and aim for that standard in everything you do, not just the parts you enjoy most.

Write the clearest documentation you can. Be the first person to know if your software breaks.

Be reliable, and part of reliability is also finishing what you start. You accepted responsibility for the work, so take it to the finish line.

BE RESPONSIBLE

You are the someone in someone should do something.

• Take ownership
• taking charge
• Create calm

When something goes wrong, you don’t shrug and decide the work is impossible. You navigate the problem and you are accountable for the result.

Drive meetings: make sure there is an agenda, collect items to discuss at the start of the meeting, or set the example of sending around the agenda in advance.

It’s not just technology! there is a broader context: a business that’s trying to achieve something. The software is the means to those ends, not an end in itself.

What’s next

Have a skill table!

Javascript - 5

CSS - 3

You can’t be an expert in everything. That’s ok: strong teams are built from people who each have a subset of the necessary skills. But if there are skills you need to get you to your goal, or gaps in your abilities that make you feel insecure, assume they are just unknown, not unkowable. You haven’t put ability points there yet.

If you want a sustainable career in tech, your are going to need to keep learning your whole life… make sure that you:

• Know yourself and what makes you happy.
• Spend your time mostly in alignment with that

Practicing skills you find difficult may turn them into strengths and reduce how much energy they cost, or they may never stop being a slog.

Decide what the skills is worth to you.

If you have skills, but nobody knows about them, you won’t get invited to use them. Let people see you solving problems, asking insightful questions, or showing up with a clear strategy when there is chaos, and they are more likely to think of you when an opportunity arises. You will meet interesting people too: they are more likely to reach out because they see you are working on something that’s relevant to both of you.

Build good software. Build a good software career. Build a good software industry.