Overview

Career growth is the foundation of an organization’s culture. In the same way that we strive to build a product that enables the growth of a company, we should aim to design a career ladder that facilitates the growth of our people through well-defined expectations.

This document strives to understand and define some of the expectations of the individuals, namely “seniors”, leading, sponsoring and mentoring those around them. Seniority is a shift in mindset from focusing on just yourself, to focusing on your position as a leader in a much larger entity.

Seniority is not absolute, but rather, relative and a function of time, the organization of prior employment and point in time at that organization.

Why not just years of experience? Why is “point in time” at a specific organization important? If you work somewhere that is already established for 15 years, you may still be learning the same lessons as someone with 2 years of experience and a lot of responsibility at a smaller, faster-growing organization. Second, Twitter in 2007 is a lot different than Twitter in 2017 (even the company is trying to solve different external problems that may or may not impact your contributions to your current employer).

These points are how I define senior and personally evaluate myself and my growth as a software engineer and ultimately as a person who is just a small part of a much larger community.

I also strongly believe that seniority is only partially about purely technical things and more about how one navigates various situations with the goal being what is best for their team, larger organization or ultimately, the company or community. Also, many of the points themselves — maybe not all of the examples — are generally applicable in contexts outside of Software Engineering.

The approach of defining senior first and then defining levels below and above is inspired by the following Twitter thread from Liz Fong-Jones, who summarized points made in this talk at The Lead Developer New York 2019.

This document should tell a story and elicit someone or people you know personally from past experience — a peer, mentor, advisor, etc. This document is not a replacement for a matrix. Instead, it complements a career ladder matrix.

TL;DR

Does

  1. Evangelize others before themselves
  2. Open, rather than closes conversations or discussions
  3. Lift the skills and expertise of those around them
  4. Regularly identify unknown, unknowns
  5. Intensely focus on finishing
  6. Actively seek out constructive criticism and feedback from peers of all levels
  7. Habitually give constructive, often actionable, feedback
  8. Admit and own failure, early
  9. Lead with action
  10. Focus on simplicity
  11. Frequently evaluate the alignment of one’s and the team’s work
  12. Effectively balance external and internal work
  13. Possess knowledge in their domain and the wider impacts
  14. Know where to look (or who to ask) when questions arise; isn’t afraid to ask questions
  15. Understand industry idioms and/or best practices (and aware of when not to use them)
  16. Estimate accurately, consistently
  17. Effectively communicate across business domains and internal teams

Does Not

  1. Say “No”, but instead says what we need to do to get to “Yes”
  2. Possess a “hero” mentality
  3. Consistently work alone or in a silo (i.e., actively avoids silos)
  4. Accept the excuse of “didn’t have time” to establish confidence in my changes
  5. Solve solved problems

Does

1. Evangelize others before themselves

  • e.g., When given the opportunity to shine the light on either themselves or someone else, consistently chooses someone other than themselves. Seniors should absolutely still evangelize their own work, but it should come after praising the work of others or the team.

2. Open, rather than close, conversations or discussions5

  • e.g., This could be in the form of a review comment. Instead of saying, “do this…”, they say, “What are your thoughts on doing it [this way]…?”

3. Lift the skills and expertise of those around them1 such that together they are better than working singularly

  • e.g., When this individual doesn’t work with you, you do the bare minimum to complete a task, but when they do work with you, they challenge you to go above and beyond.

4. Regularly identify unknown, unknowns

  • e.g., In a pull request, instead of just reviewing what the code author has written, thinking outside of the defined space and posing questions/concerns that were probably not considered.

5. Intensely focus on finishing

  • e.g., Doesn’t start a number of things, hand them off and never see them finished.

6. Actively seek out constructive criticism and feedback from peers of all levels4

  • e.g., Doesn’t say, “give me feedback”, instead, creates an environment that makes it natural for others to provide feedback by posing questions for the others to consider. For example, “what do you think about using [this approach] instead?”

7. Habitually give constructive, often actionable, feedback — not just in code reviews

  • e.g., Instead of saying, “I don’t like the name of this function”, saying, “instead of naming this function doThings, name it doABC because there is a standard that this project follows”.
  • e.g., very, very rarely, if ever, gives “LGTM”

8. Admit and own failure, early

  • e.g., Instead of waiting until a large project has completely failed, this individual owns failure as soon as they recognize it.

9. Lead with action

  • e.g., “Model, Document, Share”. Doesn’t lobby for change. Instead conducts many small experiments, iterating each time, then shares with a small group, before sharing to a larger group6.
  • Can also quickly pick up on effective ways to make change given the environment.

10. Focus on simplicity

  • e.g., Is constantly evaluating systems to see what is actually necessary and what could be removed.

11. Frequently evaluate the alignment of one’s and the team’s work with the wider organization/company/community, correcting when necessary

  • e.g., Catches themselves quickly in situations where scope is creeping too much and reevaluates rather than continuing with the current trajectory.

12. Effectively balance external and internal work

  • e.g., Knows when it is (and is not) appropriate to work in internal engineering goals along with Product work.
  • e.g., Does what is best for the company at that point in time. Sometimes doing things that don’t scale.

13. Possess knowledge in their domain and the wider impacts

  • e.g., If 100ms of latency were to be added how could that affect consumers? Do queues get backed up?

14. Know where to look (or who to ask) when questions arise

  • e.g., If they know there is an issue in a service owned by another team, this person may go quickly look at the code and then ask follow-up questions rather than just going directly to someone and asking a question.

15. Understand industry idioms and/or best practices

  • e.g., Go Proverb: “The bigger the interface, the weaker the abstraction7”

16. Estimate accurately, consistently4

  • e.g., Not just the effort to get it “done”, but considers other internal, Engineering goals and how they could potentially be integrated into the completion of a task

17. Effectively communicate across business domains and internal teams

  • Note: Ultimately, engineering is here to support the company. We are all trying to achieve the exact same goal! If we work with other teams and we understand their interest and they understand ours, we will all be better off.

Does Not

1. Say “No”, but instead says what we need to do to get to “Yes”

  • Note: this idea was taken from the Arrested Devops Podcast episode featuring Silvia Botros
  • e.g., Instead of telling Marketing, “no, we cannot support that type of promotion”, we dig in and see what we need to do to support it and then work with Product or Delivery to see what needs shifted around.

2. Possess a “hero” mentality6

  • e.g., Instead of always being the one to pick up the high-priority tasks, giving others the chance i.e., sharing highly visible or priority work.

3. Consistently work alone or in a silo (i.e., actively avoids siloing)

  • e.g., Instead of designing, implementing and maintaining something in silo for “job security”, actively tries to bring others into projects that they are working on.

4. Accept the excuse of “didn’t have time” to establish confidence in my changes

  • Note: “Didn’t have time” is indication of a poor ability to properly estimate
  • Establishing confidence in their code through automated tests — not necessarily 100% confident/coverage all of the time; understands diminishing returns. There are diminishing returns in certain instances or times when it isn’t “worth” adding another test.

5. Solve solved problems

  • e.g., “I bet there is already a tool that does that.”

Appendix

Document Goals

  • Start a conversation about how collectively we can define “senior”.
  • Set expectations for/of individuals who want to be/already are defined as “senior”.
  • Help define the type of person who I want to work with.
  • Meant to complement an engineering matrix document.

Document Not Goals

  • Define a career ladder.
  • Define an exhaustive list of traits that seniors possess.

Threats to Validity

The points made here are purely my own and reflect my views, not those of anyone else. I recognize my lack of experience and because of that there will be unknown, unknowns.

This document is a living document i.e., my definition of senior is not concrete; this is how I define senior at this point in time in my career.

Other Thoughts

What distinguishes senior from less than (<) senior?

  • < senior is focused on well-defined tasks
  • < senior is primarily focused on just the tasks assigned to them
  • < senior is primarily focused on writing “good” (e.g., readable, performant) and testable code
  • < senior focuses on known, knowns and sometimes known unknowns, but rarely thinks about unknown, knowns and especially not unknown, unknowns

What distinguishes senior from greater than (>) senior?

  • I think seniors still have to have tasks with clear end goals, where > senior finds and fixes problems that people didn’t know existed (unknown, knowns).
  • Senior Engineer II: “Given a nebulous project, a Senior Engineer II will appropriately scope it, find a solution, implement and launch that solution.1”
  • e.g., > senior given a widely-scoped, cross-team task, can propose a solution. Senior would be working on designing individual pieces of the task.
  • Staff Engineer: defining the vision of Engineering4.
  • > Senior leads multiple teams (technical insight, vision, etc.) versus Senior is focused on doing the same things for one team.

References

  1. On Being A Senior Engineer - John Allspaw
  2. progression.fyi
  3. Career Ladder (Rent The Runway) - Camille Fournier
  4. Software Development/Leadership Ladder (Rent The Runway) - Camille Fournier
  5. (Amazon) The Hard Things About Hard Things - Ben Horowitz
  6. (Amazon) An Elegant Puzzle: Systems of Engineering Management - Will Larson
  7. Go Proverbs - Rob Pike