How do you "sell" your work and show impact as an aspiring Staff Engineer?
I had a question on how does one exhibit impact and staff level behavior as a Senior engineer.
The staff engineers on the team code as much as me. Although I am a lead for a team, there is distinction between me and how another lead is being perceived. I am happy for them.
They have been in the company way longer, they advocate, question and are not afraid to speak up.
But code wise, I have way more commits. We are both leads, but I can tell they are on the way to becoming staff, and it is the behavior. I am not able to put a pin on it.
How can we be perceived of being extremely valuable and influential to the team without crunching code.
Discussion
(3 comments)- 5a year agoSenior Software Engineer [5A] at Uber
You have misunderstood what the staff job entails. Consider that the staff vs senior role are 2 different jobs.
Senior: Problem known, solution unknown
Example: "Build x feature on Android + iOS. You also need to tell the backend what to send down"
Staff: Problem unknown, solution unknown
Example: "Reduce land times by 5%" This may include optimizing the build system itself, looking at machine capacity, caching mechanisms, increasing CI performance, etc. There are so many different areas that you may have no context on that you'll need to jump in and quickly become an expert in.
Or maybe you're in a product team
"Eliminate our dead unused code"
Its akin to being dropped on a deserted island and asked to lead a team to get off of it. That will mean
- Figuring out what vehicle we should have. Should build a canoe or a row boat? Or maybe there's an abandoned plane on the island. If we need to build a boat, do we have the resources for it? Then delegating building the boat or fixing the plane to someone.
- Figuring out how long we have to live. Is there any hope? Does the island have food and water? How should we allocate those? Should we instead take the longer way and invest into building a farm so that we have more time to think? Or maybe we have a finite amount of non-replenishable food and we need to build an escape as soon as possible.
- Rules for survival. Should we enforce a "only eat when you finish your job" rule? Or should we be more lax and let people eat whenever, trusting they will get the job done?
- Organization of tasks. How do you track the progress of everyone? What happens if someone is encountering issues and slows down the timeline? Can you readjust/reallocate or abandon tasks to compensate?
- Plus, being able to get your hands dirty if someone is slow or is struggling. Can you figure out the plane repair faster if need be?
Each one of these has its own engineering equivalents. I leave that as an exercise to the reader.
What I think you're misunderstanding is that you think its all about code. Its not. Shipping code is one of many angles by which to measure your productivity but its an ends to a mean. Why are you writing the code that you're writing? How does it fit into the bigger context? How will it get us closer to the overall strategic solution? Why should we allocate time and developer hours to this? Can we maintain it in the long run?
Your thinking should be strategic and try to handle the unknowns and potentially unknowables. Allocation of resources and identification of problem areas that are previously unknown is a big chunk of that. Ontop of that, because of how complex these systems and codebases are, unknowable/unpredictable changes will always come at you and you must be prepared to not let those derail your efforts.
If you cannot show the initiative to do that in a way that contributes to the strategic direction of the team, then you are not ready to be a staff engineer.
- 4
a year agoDev with a pinch of sales.Try this...
- List all your accomplishments (commits, optimizations, projects, heroic saves).
- for each, ask "so what"? "what impact did that have on the team"?
- take each answer and ask "so what"? "what impact did that have on my management"?
- take each answer from above and ask "so what"? "what impact did that have on my company"?
This exercise will give you:
- Talking points to showcase when asked "what are you up to"?
- Dollar amounts (revenue, cost savings) that you contributed to.
- Gives you some context to use when speaking to execs and management.
- 3a year agoTech Lead/Manager at Meta, Pinterest, Kosei
- Talk to your manager for an honest opinion about your influence (or lack thereof), and if that may hold back your promotion to Staff Engineer. You've made good observations about differences in behavior, but I'd like for us to validate if they are indeed problems. ("If it ain't broke, don't fix it.")
- Start with the outcome you want, which is to be able to answer questions for the team, influence team direction, and help others? Which projects would best allow you to do that?
- Observe which forums the other Staff Engineers are using most effectively. Are they doing a lot more 1:1s, team meetings, group posts compared to you? (You should creep on their calendar, wiki contributions if possible!) I talk about this in the "Talk & Observe" onboarding framework.
