Senior to staff engineer curriculum, part 1 of many

This is a multi-part series that I'm running as an experiment at DataDog: I'm hosting a discussion group for Senior Software Engineers who're looking to eventually become Staff Engineers.  This is the curriculum that I'm using.

Links to other parts of the series: 1, 2, 3, 4

This first post is the setup that I use for beginning a new cohort.  A cohort is currently a group of 4-5 engineers, some in person and some remote.  Currently all in the same organization, but that doesn't have to be true.

Introduction and ground rules

Introductions

  • Who everyone is
  • The team they work on
  • A mundane fact (i.e. not an interesting fact)

Goals

  • There’s no formal training for how to go from Senior to Staff.  That’s annoying!  And it’s a problem that I ran into.  Maybe I can help you with this?

    • The roles are fundamentally different.  What got you to Senior won’t get you to Staff.

  • This isn’t about getting you promoted, it’s about learning new skills.  That’s a way more durable career plan!

  • I have a list of skills, we’re going to work through them for the next sessions.

  • I don’t know everything, I want to learn from you


Rules

  • Confidentiality: please don’t share without checking

    • No AI summary

  • Engagement: no vibe coding in the background


Questions

  • Do we want to record this meeting if someone can’t make it?


Structure:

  • [Optional] Review homework from last time

  • Read a thing (either beforehand or now)

  • Discuss

  • Homework

Comments

Post a Comment

Popular posts from this blog

Introduction

 Once upon a time there was a whole series of interesting books about leaning programming languages that followed the same loose format: a series of related practical tips for using them well and avoiding pitfalls. This blog is all about Staff+ software engineering and it'll try to follow the same basic format.  Each post will have a concrete tip.  A few things to note: I'll be typing the words here but many of the ideas are from other people.  I'll be linking out to their docs or websites and putting credits wherever I can.  If I miss one then please let me know and I'll fix it. This isn't written by AI, it's just me and a keyboard. This will always be free here. I'm leaving comments off for now as I'm comfortable with this being write-only and don't want to try moderating them. No ads. For fun, here are a few links to some of the books: Effective C++ Effective Java
Read more

Influence, part 4 of 5: Tactical tips

 This is the fourth part of a five part series on influence as a Staff+ Software Engineer ( part 1 ,  part 2 ,  part 3 ,  part 4 ,  part 5 ).  I've ported this here from where I  originally published it on Medium .  Tactical tips Give credit If in doubt, add a credits section to your docs and presentations to thank the people who have worked on something with you. It’s likely that you’ve been talking to them to refine your ideas and make plans, and it’s only polite — they’ll be far more likely to work with you in the future and share ideas. The combined wisdom of these people is likely to be greater than your own. This shouldn’t be a zero sum game, even when it comes to design docs for perf. It’s entirely fair to ask others to also include credits sections. Write the doc and know how to circulate it If you have a good idea then put it into a one page doc. Bonus points if you can actually make it one page long! This is good for a few reason...
Read more