3 ms·

I see your point - but rather than hate your colleague for not doing their job well, why not find a way to give them feedback? "Trust" is obviously not a substi

I see your point - but rather than hate your colleague for not doing their job well, why not find a way to give them feedback? "Trust" is obviously not a substitute for performance management - but having high psychological safety/trust makes it 10x easier to have a conversation with a colleague to say "Hey I noticed you asked this question in slack - we've actually got this in a wiki over here" or "hey, I noticed you keep submitting non functioning code - why is this?". This sounds like you are describing a junior engineer - perhaps you will learn something along the way - perhaps their local dev environment is broken meaning they can't run the tests without pushing to GitHub actions, and they don't know how to fix it, but they're in a low psychological safety culture that makes them afraid of asking "basic questions" (as you put it) in Slack. What's your philosophy on developing people in teams? I'm sure it's not just to 'hate' people into good performance. If you take a long view on people, you have to create a space where people are comfortable admitting their shortcomings.

ohdannyboy 4y ago
FWIW I don't mind being asked questions. As I have grown I've tended towards being a technical specialist over a manager and part of that is being a resource. I'm also very good with Git, GDB and Linux so I end up as the go-to guy for a lot of things (I've trained several teams on Git with a lot of success). I've never had to build/maintain a team from a management perspective. But from my own experiences the people I've learned the most from were competent themselves, good teachers (IE they explain their reasoning and ask leading questions to help understanding) and approachable. So if I was asking too much or stuff I needed to do myself, instead of dressing my down in front of the team they'd privately say "I know we're throwing a lot at you, but time is becoming an issue on our end. I'd recommend talking to [manager] and asking for a some time to research this subject with a wiki page as a deliverable." (this is a non-hypothetical form when I was a newbie). Semi-compulsory social interactions were never a factor. Also the person I had in mind when writing my post was actually very experienced. Affable, but totally incompetent with no interest in learning. My expectations are relative to experience. - Juniors need a lot of help and won't be independently solving complex problems. Every review they submit will need some guidance and it will probably be about basic things like "this function does 3 things and over uses global variables." If they're learning then they're doing it right. - Mid level developers should be independent contributors for everything except higher level design or very technical work. Mistakes will be present but more rarely and relating to harder subjects. Mistakes I'd expect from a mid level dev would be more along the lines of not knowing that signed integer overflow is undefined in C, passing a pointer in a not quite safe way, ect. - Senior level developers should need little technical guidance and their reviews should be almost all QA. Since they have a deep understanding of their field they can refer to documentation and datasheets more readily and when they need help they usually know what to ask. In general they should be answering a lot more than they're asking.

ohdannyboy 4y ago

FWIW I don't mind being asked questions. As I have grown I've tended towards being a technical specialist over a manager and part of that is being a resource. I'm also very good with Git, GDB and Linux so I end up as the go-to guy for a lot of things (I've trained several teams on Git with a lot of success). I've never had to build/maintain a team from a management perspective. But from my own experiences the people I've learned the most from were competent themselves, good teachers (IE they explain their reasoning and ask leading questions to help understanding) and approachable. So if I was asking too much or stuff I needed to do myself, instead of dressing my down in front of the team they'd privately say "I know we're throwing a lot at you, but time is becoming an issue on our end. I'd recommend talking to [manager] and asking for a some time to research this subject with a wiki page as a deliverable." (this is a non-hypothetical form when I was a newbie). Semi-compulsory social interactions were never a factor. Also the person I had in mind when writing my post was actually very experienced. Affable, but totally incompetent with no interest in learning. My expectations are relative to experience. - Juniors need a lot of help and won't be independently solving complex problems. Every review they submit will need some guidance and it will probably be about basic things like "this function does 3 things and over uses global variables." If they're learning then they're doing it right. - Mid level developers should be independent contributors for everything except higher level design or very technical work. Mistakes will be present but more rarely and relating to harder subjects. Mistakes I'd expect from a mid level dev would be more along the lines of not knowing that signed integer overflow is undefined in C, passing a pointer in a not quite safe way, ect. - Senior level developers should need little technical guidance and their reviews should be almost all QA. Since they have a deep understanding of their field they can refer to documentation and datasheets more readily and when they need help they usually know what to ask. In general they should be answering a lot more than they're asking.