Staff+ Role

Why do we need engineers who can see the big picture?

• Individual teams tend to optimize for their own interests
• Decisions that seem to belong to one team have consequences that extend beyond their boundaries
• Teams need decision influencers who can take an outsider view and consider the goals of multiple teams
• Why can’t this be managers or the CTO?
  • Good people managers don’t have time to stay up to date with technical developments
• Teams should ideally interlock like a jigsaw puzzle
• Staff engineers are cautious of technical debt and are wary of any poor decisions for future maintainers of those systems
• More seasoned engineers provide architectural best practices and creates the kind of tooling that makes everyone faster and safer
• Staff+ engineers are role models for building quality software

Staff engineers often take on ambiguous, messy and difficult problems in order to make them manageable by someone else

• You’re not a manager, but you are a leader
• You’re in a “technical” role
• You aim to be autonomous
• You set technical direction
• You communicate often and well

There is no standard model for how Staff+ engineers report into the rest of the engineering organization.

Your reporting chain will likely affect your scope.

Your job is to make your organization successful.

Your time is finite. Be deliberate about choosing a primary focus that’s important and that isn’t wasting your skills.

The Shadow Org Chart

The unwritten structures through which power and influence flow.

• “Connectors” & “old timers”

Technical Vision & Strategy

Practice the skills of intentionally looking for a bigger picture and seeing what’s happening.

A technical vision describes the future as you’d like it to be once the objectives have been achieved and the biggest problems are solved.

Resources:

• Fundamentals of Software Architecture by Mark Richards and Neal Ford
• Chapter 4 of Making Things Happen by Scott Berkun
• How to Set the Technical Direction for Your Team by James Hood
• Writing our 3-Year Technical Vision by Daniel Micol

A technical strategy is a plan of action. It’s how you intend on achieving your goals, navigating past the obstacles you’ll meet along the way.

Resources:

• Good Strategy / Bad Strategy by Richard Rumelt
• Technical Strategy Power Chords by Patrick Shields
• Getting to Commitment: Tackling Broad Technical Problems in Large Organizations by Mattie Toia
• A Survey of Engineering Strategies by Will Larson
• Technology Strategy Patterns by Eben Hewitt
• Rands Leadership Slack
  • #technical-strategy
  • #books-good-strategy-bad-strategy

You Have Finite Time

How busy do you like to be?

• Energy
• Credibility
• Quality of life
• Skills
• Social capital

Staff+ engineers will be largely responsible for choosing their own work. You are responsible for choosing work that aligns with your life and career needs as well as advancing your company’s goals.

Your social capital and peer credibility are “bank accounts” that you can pay into and spend from.

Free up your resources by giving other people opportunities to grow.

Focus means sometimes saying no.

It’s normal to feel overwhelmed by a huge project. The project is difficult. That’s why it needs someone like you on it.

Leading a project means deliberately driving it, not just letting things happen.

Write things down. Be clear and opinionated. Wrong gets corrected, vague sticks around.

As a project lead you are responsible for understanding why your project has stopped and getting it started again.

You Are A Role Model Now

What does it mean to do a good job?

• Be competent
  • Know things
  • Build experience
  • Build domain knowledge
  • Stay up to date
  • Show that you’re learning (especially to junior engineers)
• Be self-aware
  • Admit what you know
  • Admit what you don’t know
  • Understand your own context
• Have high standards
  • Seek out constructive criticism
  • Own your mistakes
  • Be reliable
• Be responsible
  • Take ownership
  • Make decisions
  • Ask “obvious” questions
  • Don’t delegate through neglect
• Take charge
  • Step up in an emergency
  • Ask for more information when everyone is confused
  • Drive meetings
  • If you see something, say something
• Create calm
  • Defuse, don’t amplify
  • Avoid blame
  • Be consistent
• Remember the goal
  • Remember there’s a business
  • Adapt to the situation
  • Be aware that there’s a budget
  • Spend resources mindfully
• Remember there’s a user
• Remember there’s a team
• Look ahead
  • Telegraph what’s coming
  • Tidy up
  • Keep your tools sharp
  • Create institutional memory
• Expect failure
• Keep it simple
• Build to decommission

The metric for success is whether other people want to work with you.

Scaling your good influence:

• Individual
• Group
• Catalyst

Forms of influence:

• Advice
• Teaching
• Guardrails
• Opportunities

Scaling your teaching to a group

You can scale your teaching by creating materials for a class. Putting together a class takes a ton of effort. There’s a high up-front cost for the first time you teach it, but you’ll amortize that cost every time you teach it again.

The post The Staff Engineer’s Path appeared first on Michael Barany.

About 10 years ago or so I was working at a small tech startup. We had a new “rockstar” engineer join my team, we’ll call him “Steve”. As I sent him my Pull Requests he would occasionally add a comment like “consider …”. One time it was “consider adding a test for this new functionality”. I thought to myself for a minute and then proceeded to write a test, pushed it up and then sent it over to Steve once more for another review. It was definitely satisfying to get that approval from him.

I soon realized there was some magic in the word “consider”. I mean of course as a senior software engineer I knew that unit tests were part of the job, but since testing culture had not been ingrained into my flow I didn’t feel the desire to write a test. I could have easily brushed off the comment or have ignored it and gotten a “rubber stamp approval” from another engineer, but there was something to that word “consider” that really convinced me to comply with the suggestion.

Since then I have been adding this word to almost every Pull Request comment I have made. I’ve even used the word “consider” almost passive aggressively at times. Like “Consider linting this file” or “Consider not using this pattern. Consider using the better pattern over here”.

The other advantage to using this magical word is that it builds up influence with your colleagues. This can be especially useful as you are starting a new job.

So consider using the word “consider” when giving feedback to your colleagues. Whether that’s a review of code, architecture or design documents.

The post For Your Consideration appeared first on Michael Barany.