Assuming your company even has an intranet.
Past your training period you are responsible for your own productivity. Don't make it the problem of your peers.
Of course, people are responsible for their own productivity, but there is also such a thing as a team. And the team itself will benefit if people are less disruptive of each other.
My point is that teams should retrospect aggressively on where they spend their time, and if they find that lots of their time is spent on answering questions to onboarders or big knowledge gaps between one another, they should do something about it.
I won't waste space here outlining what can be done, but there ARE things that can be done. Do those things, and then the argument that you:
A) "must" be in the office to do good collaborative work
B) and you "have" to ask 5 min questions all the time
loses any validity and becomes just corporate laziness and bad management.
The goal is to make the team succeed, not to be individual rockstars.
This is the problem: you've invented this scenario. There is a gaping middle ground between what people are describing and your stereotype of what they "must really mean"?
Too many people are too un-self-aware to recognize that their "just a 5-minute question" is being asked because they have not internalized the knowledge, rather than because it's genuinely something that they haven't had an opportunity to learn—too un-self-aware to recognize that this situation is unnecessarily stressful and it's their fault.
Of course this has nothing to say with selfishness or else. It's simply that each Group project their own ideas to the outward world -- so people who like to outreach think other people like that too, while people who doesn't think the inverse. But taking a step back as a third party, we would realize that Group 2 is usually more harmed than benefited.
This is just assumptions though. Too many? Compared to what? Narrators are just as unreliable as anyone; some will be unreasonably opposed to any questions. Complaints aren't all 100% trustworthy. And complainants can also be un-self aware in that when they were more junior, or new, then they also asked questions. They just maybe had people answer them who were more happy to invest in them.
I'll be blunt here. I have very little interest in how the team I'm part of performs in general. Trying to make one person feel guilty that someone else can't do independent study is very toxic in my opinion, and I usually remove myself from under management that approaches leadership like that.
Asking questions should always be done, in my opinion, _after_ you tried to unblock yourself by RTFM-ing. If people feed you information every time you're stuck, it seldom sticks to your mind as well as going through the motions yourself.
Your job security is extremely dependent on the health of your company and team. If the structures which provide your employment contract start failing, and you do nothing about it, don’t be surprised if you get bitten.
I don’t expect appeals to empathy will work based on your posts, and I hate “we are a big family” smoke and mirrors too, but let’s be pragmatic here. The fact that your job even exists is predicated on a social and legal contract to provide your expertise for the benefit of a multi-person entity.
Team health does also depend on nudging those who can’t RTFM to do so… you can be an asshole, but you need to be a prosocial one as far as the company is concerned.
In a lot of situations that would be considered fairly toxic itself. :(
Why do you think that a whole team of people should be responsible for the inability of some? I have empathy for individual people that start their careers and struggle, but I also believe that if you apply for a job, you should be qualified to do it independently.
i do not want to be just a cog in a machine that grinds out work without any consideration for the project as a whole.
it is also needed to allow new team members to get onboarded faster.
as a hiring manager i find your attitude unwelcome.
Also I don't dismiss camaraderie that appears spontaneously between coworkers, I was complaining about the company enforced fake camaraderie that gets pushed down everyone's throats with trite team building exercises, company parties, team goals and other methods of hammering people into conformity.
> it is also needed to allow new team members to get onboarded faster.
Of course, it's fine to have team members absorb domain knowledge through interactions with their peers, but if that's the only way to on-board them, I most definitely don't want to work for you, but again, that's fine, I'll just look elsewhere.
This is nothing to do with what you said before, about not wanting team performance to be important. Unless you're there to do a very specific job, a lot of performance is actually about team performance. If nothing else, the bus factor on people who want to do things solo makes them an automatic liability.
it's fine to have team members absorb domain knowledge through interactions with their peers, but if that's the only way to on-board them, I most definitely don't want to work for you
ok, you lost me here. what other way is there? it's not possible to assess all the knowledge a new hire has. if i have to hire a trainer to get them up to speed it will just cost more money and they will not learn the company specific domain knowledge.
in my experience specifically onboarding can only be done by others on the same team. it's a teams responsibility.
for more thoughts on this topic, see the discussion here: https://softwareengineering.stackexchange.com/questions/1190...
Don't be surprised when others show the same level of empathy towards you, then. It's not about making you feel guilty, it's about making you do you effing job. Unless you're in a very junior position, your job is not to pump out code day in and day out.
It's a little disconcerting to see someone make such self assured inferences about me, based on a single comment.
I mean, sure, that's fine if this is stipulated from the start, but if you expect someone to solve leet code, do programming homework, and then when they get hired they have to also navigate your extra requirements and teach people the basics of their job (because probably you couldn't be bothered to pay enough) then in my opinion you're taking advantage of these people pure and simple.
And to top it off, I know managers sometimes fools themselves that the team is invested in the "project moving forward", but that's rarely the case. As an individual I probably don't give a damn about the project, unless we're solving one the big issues of the world. The bullshit CRUD application you work on, or the latest cryptocurrency is just a means to get a paycheck for most of the people, and if you expect anyone to fake enthusiasm for it you're just deluded.
you seem to prefer working on your own, neither willing to teach nor learn from others. that's fine if you can find a job as a lone developer, but i don't consider this a suitable attitude for working on a team.
Not all jobs are simple enough to hire people into with generic skills. People need training. Even if it's just "I think that other team should prioritise this feature for us; who do I ask?" People need to ask questions and bed in over time. If you've just done simple CRUD apps in small orgs you may not have seen this, but that doesn't make it not the case.
> And to top it off, I know managers sometimes fools themselves that the team is invested in the "project moving forward", but that's rarely the case. As an individual I probably don't give a damn about the project, unless we're solving one the big issues of the world. The bullshit CRUD application you work on, or the latest cryptocurrency is just a means to get a paycheck for most of the people, and if you expect anyone to fake enthusiasm for it you're just deluded.
You seem to keep on inventing things no one is saying to respond to. If you have a load of unrelated things to get off your chest that's fine I suppose, but it seems you actually think people are saying this and you're making points in response to them.
How about you encourage the team to actively monitor where onboarding takes time, year by year, learn from that, make onboarding materials which encompass institutional knowledge, and make the process as much self serve as possible?
Or assigning a "buddy/mentor" like persona that is responsible for this specific onboarding, so the rest of the team don't get distracted + the expectations on delivery are lowered for the "buddy"?
> it takes that is in their capacity to move the project forward
It takes quiet and uninterrupted work and focus time, and spending effort on making onboarding as smooth as possible. Just hoping your devs will do all the work of onboarding + their own work, and you doing nothing, that's just...what I expected I guess.
being that buddy/mentor is part of your job, and i expect everyone on the team including me to be able to take on that role as the situation demands.
moving the project forward takes quiet and uninterrupted work and focus time
and it takes making sure that all team knowledge is shared with everyone. where do you get the idea that i do nothing? it is my job to allocate resources properly, but it is also my choice how to to do that.
you seem to look at onboarding as a kind of burden that i throw onto you on top of your other work that you'd rather not have to deal with. i see onboarding as part of the process to grow our team, exchange knowledge and experience and enable us to do ever better work.
when i am starting a new team then i onboard/mentor everyone myself, until the team is grown enough and some of the team members have enough experience to share that role. eventually, the team will be large enough to divide up into multiple teams, but i am still the one doing the hiring, and i'll be involved with onboarding until the company grows so large that it no longer makes sense to do that personally. but at that point i'll still make hiring decisions because i feel that hiring the right kind of people is to important to completely delegate.
the attitude that i expect from my team is that everyone is made welcome and we all do our best to get them integrated. onboarding materials can't replace that attitude which i see as necessary for the team to work well together.
WFH comes with a lot of issues, when it comes to a timely response from people.
I had many of colleagues in the WfH world, that just ignored me for a month...
The idea that all engineering is highly focused and non-social just feeds the rockstar developer culture. And most of us aren't even close to rockstar status.
There is always a balance between collaborative discussions and focus time. I thought that we learned it 20 years ago, that devs should not hide away in cubicles?
This is very one-sided. If you can unblock someone now so they don't spend 3 hours searching through the local intranet for some information, then that makes your team faster. There's a balance to be had, of course, but your team's overall delivery is what's important.
> I view it as a type of interruption.
It's not your view. Of course it's an interruption. That doesn't make it bad.