Why is it important to talk about what can be expected from senior engineers?

• Align expectations within the team: what does it mean to be "senior"?
• Set career goals for everyone: what do I need to learn to become "senior"?
• Influence behaviors: what's ok & what's not ok?

Side note: what about "junior" engineers?

It makes sense to have a specific job title for "senior": not only does it validate somebody's career progression, it also serves as a clear signal that the person has extra responsibilities.

That being said, I don't think we should have a job title "junior engineers" as the entry level title for software engineering. People might resent their lack of experience being constantly reminded to everyone by having "junior" in their title. This might be purely about communication, but I find that "we need an experienced engineer for this job" more positive than "we can't have a junior hold this role".

The technical and the management career track

Most companies distinguish between the technical and the management track:

• Technical
  • Engineer
  • Senior Engineer
  • Staff Engineer
  • Principal Engineer
  • Fellow
• Management:
  • Manager
  • Senior Manager
  • Director
  • VP of Engineering
  • CTO

In such a two-track system, becoming a manager is not a promotion. It is a completely different role, so it should be considered a lateral move.

In this presentation we will focus on the technical track.

How can we define a senior engineers?

There are multiple ways to define a senior:

• Autonomy: senior engineers can work with very little supervision, and can provide direction to less experienced members of their team.
• Skills: some see senior engineers at the intersection of technical capability (rigor, discipline, propensity to ship, etc.), leadership (owner's mindset, communication, persuasion, purpose...) and connectedness (mentorship, courage, honesty, community...).

Those are useful but I find it easier to think about impact level. At what level do we feel this person's impact the most?

• Engineer: task, user story
• Senior Engineer: team and its projects
• Staff Engineer: org or company
• Fellow: industry

To get a feel for what a fellow can achieve and the kind of enormous impact they can have, here's Google Fellow Jeff Dean's shortened résumé:

• v1 of Google's ad system
• 5 versions of Google's core search systems
• MapReduce
• BigTable
• GoogleTranslate
• TensorFlow

Jeff Dean's such a legend that folks have been compiling this hilarious list of Jeff Dean facts.

For now, we'll have this definition:

Senior engineer: person whose impact is felt throughout the team from a technical and organisational standpoint

Some companies expect engineers to become seniors within 5-7 years. If they don't reach that level in this timeframe, they are politely asked to find an opportunity for growth elsewhere. Also, some companies consider this level a "career goal", i.e. it is acceptable to stay at this level your whole career if you want.

What to expect from seniors?

In the shortest form:

• Senior engineers ship business value
• Senior engineers lift people up

Peter's principle states that people get promoted to their level of incompetence. In most places, you are promoted when you are doing great at your current level, which logically implies that you'll end up being promoted one time too many.

To avoid that, it is usually better to promote once you are effectively performing at the next level. So, even though below we say "senior engineers do X" and "senior engineers don't do Z", that does not mean you should not try to do that if you're not senior yet. Quite the contrary.

✅ Shipping pattern: rock-solid engineering.

It all starts with strong technical chops, and a ton of respect for software engineering as a craft. Senior engs invest in continuous learning and self introspection. They should make the right technical decision most of the time, based on either data or (hard-earned) intuition.

When building, they should take into account functional and non-functional requirements. In the image above, while the specs might have stated the maximum weight the bridge should be able to sustain, it might not have specified the obvious, i.e. that the two end should meet. The same happens in technical projects: product managers often focus on features, but that does not mean that the feature should be unstable, or slow, or incorrect. It is your role as a senior engineer to anticipate.

✅ Shipping pattern: sharing product and project ideas

A senior engineer finds unique ways to leverage technology to bring business value. For instance, they will deploy an off-the-shelf solution so that the marketing team can self-serve sending promotional emails.

They see their role as a partnership with product management - not as executing whatever the PMs have cooked up for them to work on. They will constructively criticize designs, product roadmaps etc.

This applies to product and platform senior engineers: just because you're working on infra does not mean you don't have an impact on product, quite the contrary: how can you help other product engineers ship product features faster and at a higher level of quality?

✅ Shipping pattern: leading projects

In startups, it often feels like everything has to be reinvented, including how we deliver projects. It often leads to reinventing the wheel, process-wise, and disguising common sense concepts under preposterous terms.

Yet the concept of project (delivering something of value before a specific date) is really at the core of what engineers work on, and senior engineers should take the lead on them, owning their success.

It starts with understanding their raison d'être and being relentless on aligning the team with the project's objectives. Identifying blockers, risk and dependencies (usually the three of them are the same...). Splitting a large effort into subprojects and subtasks and finding owners for them. Not being afraid of giving estimates (if you ever work on a project without a deadline - that means nobody cares about it) and communicating proactively about delays.

✅ Shipping pattern: act like a CEO

"Extreme ownership" speaks for itself. Senior engineers don't wait to be told. They have control over their team's destiny.

✅ Shipping pattern: be the unblocker

An undervalued skill in engineering (and companies in general): courage. Courage with perseverance work great together!

Learn to never, ever accept being blocked; find a way by persuasion, escalation, or technical creativity. (Dan Heller, Ten Principles for Growth as an Engineer)

❌ Shipping antipattern: being dogmatic

Not understanding the ETTO principle (Efficiency/Thoroughness Trade-Off) leads senior engineers to be blocked by over-engineering. Technical debt is not a bad thing if it's maintained (the sad thing about technical debt is that it's often confused with recklessness). Also: YAGNI (you ain't gonna need it).

This is also about perception: a strong senior engineer knows that technical decisions need to be communicated crisply, showing the tradeoffs that have been weighed. The section "ideas considered but dropped" of an RFC is usually the most useful.

❌ Shipping antipattern: thinking only about code

Senior engineers understand that code is not the only thing that needs to happen for a project to be successful.

❌ Shipping antipattern: expecting PMs to do your job

Product managers do not lose sleep over tech debt. Senior engineers understand that maintaining the technical quality of their platform is their responsibility. They keep the business team up to date with their upcoming plans for reducing technical debt, fixing up technical risks, etc.

❌ Shipping antipattern: all talking, no coding

At the end of the day, senior engineers are still expected to ship code, because that's what it takes to deliver most products. Just because it is important to communicate well does not mean that they should stop coding, lest they lose their technical edge.

✅ Lifting pattern: mentor

If you want to move forward as a team, you'll have to teach others (just like you've been taught). Senior engineers share their learnings, they share their reading ideas, they share their feedback in code reviews, they share their process in documentation and pair programming.

Being a good mentor is difficult. Sometimes mentoring means giving people autonomy and letting them make their own mistakes. You can't teach everything and most of the time this is just about setting the right context so that (1) the mistake is not a career-ending one (2) your mentee learns from it quickly. Don't teach only the how: explain the why!

✅ Lifting pattern: lead by example

The only person you can change is yourself, so start with that person. Treat others like how you'd like to be treated. Be rigorous, reliable, and constructive. Be ok with chores.

✅ Lifting pattern: investing in your communication

Just like coding, writing is a skill that takes honing: clarity, concision, inspiring without being cheesy... If you want to scale your impact, there's no better way than learning to write effectively.

This is written in 2021, in a world of lockdown and by-default working from home. Writing skills are key to effective remote work.

✅ Lifting pattern: be humble

A great leader is courageous and humble. You were a junior once. You don't know everything and never will: keep learning, and welcome diverse opinions.

Also: take things with humor. Used intelligently, humor can defuse a tense situation. You can convey very powerful messages with humor and self-deprecation. Everybody makes mistake: own them. People will relate to your experience and learn from it.

❌ Lifting antipattern: deciding by consensus

The more people, the less you can drive by consensus. Appoint a leader and let them make a decision. Sometimes this leader must be you: accept it, make the decision, unblock the team.

Disagree and commit when you're not the decision maker: there is a time for discussion, and there's a time for moving forward with somebody's decision. Identify and escape bikeshedding. Don't expect to be part of every decision.

❌ Lifting antipattern: being a demotivator

A senior should strive to uplift others around them, becoming a multiplier for the team by helping everyone move faster. It is unacceptable for a senior to be a demotivator: when they become cynical, they bring everybody done, and because of their experience and impact, they divide everyone's productivity.

Conclusion: putting things into perspective

I'll always remember what my first boss Thuan Pham (CTO of Uber at the time) said when I made the switch to engineering management:

Sure, we work with cool technology building great products, but those products have a pretty short impact timeframe: 1-3 years maximum. Above all we work with human beings on a team, and our behavior might impact their career and their life.

Putting things into perspective: how do you want to be remembered?

Resources about senior engineers

• Dan Heller, Ten Principles for Growth as an Engineer
• Brandon Hays, The Conjoined Triangles of Senior-Level Development
• John Allspaw, On Being A Senior Engineer
• Gergely Orosz, What is a Senior Software Engineer at Wise and Amazon?
• My repository on Github: charlax/professional-programming: A collection of learning resources for curious software engineers (Career Growth section)