I joke sometimes that I rewrite my job description every 6 or 8 months. This is approximately true: it’s roughly the cadence that my role and focus changes. Writing it down is about setting expectations and aligning on what my manager, peers, and other colleagues need from me.

The format is far from fixed, though. Here are a few examples from my current job in 2022.

Early on, I sketched an “engagement model” with three modes:

  • Consult:
    • Work alongside a team to help understand problems, direct energy, guide solutions.
    • Connect teams and individuals dealing with similar problems: enable a “system of theft” of good practice across teams.
  • Embed:
    • Given a specific problem, dig in with the team to help bootstrap initial work, or redirect/turn around struggling work.
    • Focus on disambiguating problems to the point that they are a 10-20% stretch for folks on the team.
    • Back off on details but continue to offer decision support.
  • Coach:
    • Work with individuals (for example, coming out of consult or embed modes), enabling them to effectively own specific problems and grow via them.
    • Focus mostly on senior engineers and team leads, with the goal of enabling them to do the same for less experienced engineers.

The framing of “engagement model” comes mainly from my work in Site Reliability Engineering, and borrows more recently from Team Topologies. I’ve found this resonates with other engineers too. A colleague was struggling with the transition to “more conversation and less code” in working more broadly across teams: thinking through their different scopes and priorities in terms of an engagement model proved useful.

A little later, my colleague Drew and I expanded on the above to share a longer “your staff engineers and you” doc explaining how we intended to support our group. An excerpt:

How you can use us

The staff engineer, team lead, and senior engineer roles are all “scaling” or “multiplicative”: we help everyone around us to be more effective. Differences are mainly in scope, focus, and expected impact.

The amount and type of support a TL wants from a staff engineer depends on the TL’s focus: some are more interested in the management path, others in the technical path. Similarly, senior engineers want different guidance depending on their experience and current projects.

When it comes to technical direction and decisions, each individual’s appetite for accountability and responsibility is different. We want you to take on as much as you are able to, and support you in growing that capacity.

Things we can help with:

  • Batting ideas around;
  • Advice and direct support in navigating cross-team or cross-org issues;
  • Partnership and review on technical approaches, RFCs, roadmaps;
  • Advocacy and signal amplification for your ideas;
  • Coaching and mentoring.

Most recently, I proposed embedding with a specific team in my area. I wrote yet another “job description” for this, outlined as:

Why?

  • For me
  • For the team

How?

  • Timeline
  • Things I expect to do
  • Things I will not do

Other engagements

Success criteria

What you put into a “job description” like this depends a lot on the audience: the first was mainly for my manager and peers; the second for my whole group; the third for a specific team.

In all cases this is about transparency and alignment. “Very senior” engineering roles are frequently confusing, not just for us but for the people we work with. Articulating what we’re trying to achieve and how is both personally and organizationally useful.

Note that Tanya Reilly covers this idea towards the end of chapter 1 of The Staff Engineer’s Path, and offers a lot of useful guidance in figuring out what you do here.