What should I do in the first few months as a Staff Engineer
Posted by No_Direction_5276@reddit | ExperiencedDevs | View on Reddit | 51 comments
As I join a new company as a Staff Engineer— a role I've never held before—what should I prioritize during my first few months? What should I focus on in terms of technical leadership, team dynamics, product ownership, and any new responsibilities that may arise from stepping into a more senior role?
Additionally, what non-technical skills should I be aware of in this role?
willcodefordonuts@reddit
First few months you observe - don’t be the “well at my last job we….” guy. Everyone hates that guy.
Observe the processes. Meet the people. Learn the product. Learn the codebase. That’s what you need to focus on.
After a month if you see things you could start suggesting small improvements etc but you need to build credibility with the team before you just tell them everything they are doing is wrong.
I’d chat to the engineering and product managers you’re working with. Find out their problems and their plans for the future. How they would like you to help.
As for non technical skills you really need good organisation and communication skills. Being able to talk to people and get them onboard with your ideas will really help a lot. And being able to give feedback in a constructive way is also a huge thing.
CrowAssaultVictim@reddit
I would be frustrated at any staff engineer who sat around observing for a (few) month.
Raise a PR your first day/week even if it’s something like editing a README.md.
If you do nothing but observe for months and then simply make suggestions, you’ll lose the team and be looking for a new job.
Take a couple tasks no one wants to do or no one can do and do them. That’ll earn the team’s respect.
a_reply_to_a_post@reddit
pretty much the approach i took when i landed a staff role 4 years ago...being self taught from back in the days before we were "software engineers" and more "Webmasters"
my first day on the job, found an issue with a docker version that didn't play nice with our local dev setup that ended up being an issue with docker desktop, validated it with our dev ops team, then submitted a bug report to Docker
first week, i just went through a launch backlog and fixed a bunch of accesbility issues in our storybook components in an order to familiarize myself with the codebase
then i spent a year basically just helping out with whatever people needed while learning the pain points of the codebase and helping ship projects because i joined during a big migration
building relationships is important, understanding the needs of the business is important, and being able to pivot to help unblock others is important
jepperepper@reddit
no one is a software engineer. i know real engineers who build bridges. we are not engineers, we are developers, and barely that.
Local-Corner8378@reddit
I think working with enterprise code is harder than building a bridge
Beryllium1010@reddit
Why? To me I think one is may more risky than the other
Local-Corner8378@reddit
risky is not equal to hard
Beryllium1010@reddit
While I don't know much about structural engineering and building bridges, I'm almost positive electrical engineering is much harder than being a software developer
Clavelio@reddit
I don’t understand why they should pick up those low impact tasks instead of doing something more relevant to their job so they can do higher impact work sooner
IsleOfOne@reddit
It's week one. Low impact work is the goal just to get a feel for the people and tooling.
eliotik@reddit
Small low impact is not risky to try the full system out: code, process, team health, etc. More relevant to the staff role indeed will have higher impact, but it can be a bigger more complex task.
Bullshit103@reddit
I felt so bad because I took a new job and the code base for the team I took over used 0 design patterns. Within the first month I suggested us restructuring our code to use SOLID. I felt like a dick because who the fuck am I to tell them it’s wrong, but it was so bad, I had to
t0w3rh0u53@reddit
With the right arguments and attitude I would actually be happy somebody would come up with such suggestion. Just like: "guys you did great, but there are some pitfalls... this and that... and I believe you can overcome this with applying solid principles because of this and that. What do you think, give it a try? happy to help"
It is very personal but for me, that helps. I hate the guys who know it all and can only be very negative, but I work with lots of architects and most of them are always enthusiastic, never say something is done wrong, always give constructive feedback. And I love working with them.
jepperepper@reddit
you're not a software engineer, you're a developer.
second, i agree with you about SOLID, when you come across a codebase that's just shit and a release process that has no testing, trying to be productive to build trust is impossible - the process prevents you.
likwidfuzion@reddit
TL;DR build knowledge, relationships, and trust
In the first week or two, you’ll likely be busy doing typical onboarding stuff, but on your down time, focus on the above three points. You won’t make meaningful impact until then.
wwww4all@reddit
This is a double edged thing. Depends on the company, where many companies want senior+, experienced person to take charge and hit the ground running, solving problems.
You have to be proactive while doing "observe" thing. You have to have sense in they type of team, company and take action accordingly. There's no one size fits all in senior+ roles. That's why the job requirements are gazillion lines of bullet points.
No_Direction_5276@reddit (OP)
excellent, thanks. i haven't been the most organised person so I can invest some time on this.
Izacus@reddit
Do check if your manager is ok with that though - because "don't be that guy" is a perspective of coworkers, but it's entirely possible that the management hired you to do changes and you'll get severe issues on your performance review if you won't have anything to show.
Keep your finger to the pulse.
Anders_142536@reddit
I'm european and we dont have nearly as many weird titles as americans here, at least not in the companies i worked for.
What exactly does a staff engineer do?
blbrd30@reddit
“Staff” indicates level
Anders_142536@reddit
So a staff engineer is not engineering personnel, but it's simply a level above senior or so?
jepperepper@reddit
there's not really a standard for titles - every company makes up their own stuff, you'd have to talk to a specific developer in a specific company to find out what they do and then guess that someone with a job in a similar company that sounds like a ismilar job might be doing similar work, but it's all a guess.
jepperepper@reddit
no, it's not above or below anything, it's just randomly chosen by the company you work for - one company may put "staff" above senior, another below, another may call them "master" and "journeyman" or any other made up or stolen terms. It's all meaningless.
blbrd30@reddit
Yeah I think it’s usually above principal, but I’m not sure
jepperepper@reddit
"engineer" can be interpreted as "software developer" - we don't have a software engineering exam or license, so people who claim to be software engineers aren't really engineers, the title just fattens up their pay packet.
if you have worked with an actual engineer who works on bridges and roads or electronics and seen how hard they work this would be clear when you see the garbage software we produce and the rotten processes we use to produce it.
"staff" just means you have been hired in a certain salary range, and it means nothing to the next company you work for - it's completely arbitrary.
So the entire title is just made up nonsense and cannot be translated to any other reference frame.
titogruul@reddit
I got recommended "the first 90 days" in a different thread. It's only arriving tomorrow so no direct experience yet, but seems like it could come in handy for you!
wwww4all@reddit
If you're asking these kind of questions to internet strangers, then Senior+ role is questionable.
This isn't learn on the job type role, you're there to solve higher level problems. Not just finish out random jira tickets.
There are gazillion resources to "learn" aspects of Senior+ role. However, the only way to "prove" mettle is simply doing, taking action. That's where senior+ experiences matter, where you can look back at past experiences to approach and solve problems at the company.
No_Direction_5276@reddit (OP)
define "these kinds of questions"
wwww4all@reddit
Your responses indicate lack of senior+ experiences.
Your best hope is that the role is inflated title situation, that the company is ok with just basic tech stack skills.
No_Direction_5276@reddit (OP)
With the powers bestowed upon me and the experience I will continue to gather, I would be more than happy to mentor you and help raise your professionalism to the standards this community expects.
No_Direction_5276@reddit (OP)
Your comment doesn't seem to add much value to the discussion. Based on your response, it doesn't appear that you're a Senior+ engineer, which undermines your credibility. If the argument is that one shouldn't seek advice from "internet strangers" about staff positions, then why would Senior+ roles participate in this community at all?
You talk as if that position is some frat club with exclusive access and that members of it shouldn't spill the secret sauce.
fuka123@reddit
Bang Hoes
DeterminedQuokka@reddit
Shhhhh. Go sit in the corner and don’t bother anyone. Watch quietly
Impossible_Way7017@reddit
find a pet project that you can work on in obscurity, learn enough about the business to sometimes ask a spicy question during all hands.
cballowe@reddit
The most important thing for a staff engineer in my experience is the relationship with leads on neighboring teams, especially the teams that depend on yours or that you depend on. Also product managers who have anything to do with what your team develops (and to that end, a good understanding of the product that your team is a part of.)
Next most important is the code your team is responsible for and the capabilities of your team.
You should be able to work comfortably on the code, but most of your focus is on how your team gets things done when the problem extends past just your team.
So... Have meetings with everybody you can - get familiar with what your team is doing through 1-1 meetings and make sure they feel you're accessible if they have problems. You're more likely to be able to help think through a solution than just do it (at least at first, but pay attention to where your team struggles and dive in to see if there's an obvious gap, make a plan to close it.) also find out what kinds of interactions they're having with people outside of the team - what's being asked, what they need, what's hard.
Outside of the team, look for things people need from your team and things your team needs from them. Your goal is figuring out what's coming in the next 6-12 months and having plans to deliver it, circulating those plans to the outside groups, getting feedback, etc.
Code wise, you'll probably delegate way more than you do yourself, but need to be able to dive in and do stuff.
Turbo_Laser@reddit
Read "The Staff Engineer's Path"
EchidnaMore1839@reddit
My issue with books like these is they make me want to die of boredom.
Mountain_Sandwich126@reddit
Get the book as it has an index to refer back to things. I got gifted the book, and I bought the audio book so I can listen and travel.
staffing.org is the website with some of the stuff
Turbo_Laser@reddit
I'm usually with you on these kinds of soft-skill books, but this one is really resonating with me for some reason. Worth a try if you're eyeing the leap to Staff+
gfunc@reddit
Take on tickets and write code as much as you can to learn the ins and out of the code base and product. You should have some time to do this up front and if you don’t take advantage of it you may not get another shot as you’ll be pretty busy and pulled in many directions. Getting that ground floor context is going to set you up for success in the long wrong.
blingmaster009@reddit
Start here: https://staffeng.com/guides/overview-overview/
lunacraz@reddit
there’s also another book called first 90 days that was recommended to me- might be useful to you OP
blingmaster009@reddit
What book is that please ?
lunacraz@reddit
it's called First 90 Days
LogicRaven_@reddit
Also this (paywall warning): https://newsletter.pragmaticengineer.com/p/ways-staff-engineers-get-stuck
killbot5000@reddit
The best description I’ve heard for what you should do is “speed run your career over again”. Start with basic junior dev work, then move up to senior dev work. Use your social skills to meet and get to know relevant stakeholders.
Once you’ve established technical competence and credibility can you begin to influence the process of development and the architecture of the systems you’re working on, taking into account feedback from devs, managers, etc.
zaitsman@reddit
Not to come across too harsh, but shouldn’t you already know if you reached Staff level?
Having said that, it’s incredibly hard to answer this in a generic way for a 5 people startup and a FAANG both.
The challenges and the focus areas are likely to be unique in each place.
Rather than look for recipes I’d use the expertise that I’d have built up for this role to identify common challenges and optimisation points, be that in process, people, approach or, indeed, code. Take your time and don’t jump to conclusions. Evaluate the ‘why’. Understand the measurables at the company and the valuables. Identify what actually makes a difference to the bottom line and what is only perceived to do so.
Things like that.
No_Direction_5276@reddit (OP)
Forgot to mention, thanks for the advice!
No_Direction_5276@reddit (OP)
> Not to come across too harsh, but shouldn’t you already know if you reached Staff level?
That's a valid point, but at times, you also need to adapt to meet the expectations of the role you're being moved into. I believe I fall into the latter category.
I could have been functioning as a Staff-level member and can easily carry those traits forward without further thought. However, this question was intended to build awareness within myself about areas that may have been more implicit / second nature to me.
aizzod@reddit
buy snacks.
advizzo@reddit
Talk to other engineers and ask what are the biggest engineering pain points first