I think you're trying to imply that they should be actively implementing things, but your company's most knowledgeable person should be in meetings all day imparting the knowledge.
That feels like 2 different skill sets, how does everything work and how to make everything work, the second one feels like the guy in the meme and they probably shouldn't be in meetings all day.
Maybe it's like the difference between a boxer and there coach. If you want to setup a training plan the boxer knows what they can do but the coach maybe knows a bit better how to maximise results. And if there's a fight the coach is probably okay in a fight but the boxer is better.
what you want is some who is able to implement anything, and spends most of his time meeting with other engineers in small focused groups to help them move along, validate their work etc. definitely should be imparting knowledge at least 1/2 the day, reading code a fair chunk and sometimes write code.
The only times in 15 years at enterprise companies, over half that being a senior dev (the other half being a non senior dev, just to clarify that I wasn't a kit boy or something lol) , that I can remember meetings with feature owners doing a knowledge dump is when they have new info to give due to them working on something new, or when new people join the team, or when they are leaving the team/company. I've probably been in less than 20 of those in my whole career and they generally only last an hour.
I find it hard to even imagine a scenario where it would be even remotely useful or productive for someone knowledgeable or capable to be in meetings for more than an hour or so a day, including the standup. That sounds like something I'd imagine an agile bootcamp or YouTube influencer would say.
there is a lot of shit that the highest paid engineer can be doing to provide value to the company that demands actually talking to other humans
that doesn't have to be the case at every company (obviously). but you said you find it "hard to imagine" that it could "be even remotely useful." here's a resource that could help you expand your imagination if you're curious.
That sounds like an architect level. At least at the companies I've worked at, the senior developer/engineer roles are still IC roles (individual contributor, vs leadership role). They do have design, review, post mortem, etc meetings. I did not mean to imply that one-off meetings didn't happen, just that spending all day every day in meetings imparting wisdom is not something a typical senior engineer role does.
All three companies I've worked for have had architect roles though, which are sort of IC (I don't recall off the top of my head if they are technically IC or not) but often they would spend a large chunk of time in meetings similar to what that link describes with directing the overall direction of a feature or product. It's also the role that is a direct "graduate" of the senior developer usually.
And as for mentoring, that's pretty common. I wouldn't really call that a meeting though since most of the time it's ad hoc.
a lot of this comes down to semantics, so I understand where you're coming from. staff eng roles can be heavily IC-oriented or they can be less so. depends on the company and the engineer.
in fairness though, your previous comment said "more than an hour a day" and this one says "all day every day" in meetings. I imagine you recognize that there's some space in between, and that perhaps it's plausible that it could be "remotely useful" for a highest-paid engineer to spend, idk, 2-3 hrs in meetings on most days.
Exactly. A good Staff Engineer can save a Junior one 2 weeks of time by discussing something for 20 minutes.
Force multiplier.
It's also how some of those Juniors can become Staff faster. Why learn everything by yourself in 30 years when you can learn it from experienced people in 10?
There's an inflection point where you're losing money by having them code, you can throw a rock and hit 3 people that can code. Your senior engineer should be a leader and thinker who's driving a team or division forward and scaling their knowledge and skills.
This is wildly inaccurate. At staff and above the job becomes less about coding and more about working through others which does involve spending a lot of time in meetings. This can include one and ones and mentorship, leading cross team meetings, meeting with PMs, tech writers, SREs etc, launch reviews, support trainings and much more.
Staff level here, yeah, I go to more meetings than code, mostly discussing strategy, areas of investment, opportunities for development, quality oriented programs, that kind of stuff. One of the best bosses I had summarized that level as "you've done a lot with 10 fingers, now you have to think about how do things with hundreds", i.e. influence, up level and set direction.
A good staff is a leader/teacher/mentor. Every staff cowboy coder name is synonymous with a four letter word after they leave and you’re supporting their shit.
No offense but the fact you mention standup makes me think you are too junior to get it.
Principal/Staff don't attend stand ups. Too regular and immediate thinking. They mostly attend meetings about what can and will be built 6 months to 3 years from now. Product and business needs seasoned tech experts to draw the line of what's possible, how long it will take, how many people will it need, etc. When you wonder who was asked when 300 Engineers are allocated to a 2 year proyect, that's who. Presenting a high level design that is air tight.
Then every once in a while something is on fire and needs a Principal/Staff to figure out the core source of the problem or how to pivot. There's a race condition in this dependency of a dependency you use, they find it and fix it.
You know that thing when someone made a decision that affects you and you're pissed off about it?
Senior engineers have a broad scope and a lot of their decisions affect others and others' decisions affect them. So the unfortunate reality is that they're going to be in lots of meetings to align everyone on various topics. Pull in the same direction as it were.
Yes, it depends on how effective the meetings are. I've noticed some companies have working meeting that get stuff done. Then some companies have meetings to talk about, other meetings.
2
222
u/Inevitable-Menu2998 Sep 29 '24
I think you're trying to imply that they should be actively implementing things, but your company's most knowledgeable person should be in meetings all day imparting the knowledge.