What should I do in the first few months as a Staff Engineer
Posted by No_Direction_5276@reddit | ExperiencedDevs | View on Reddit | 35 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?
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
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.
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.
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.
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
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.
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.
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?
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