11–20 of 37 posts
Whether this is part of the problem here is impossible to say without knowing more about the situation, but it's something to keep in mind. He may see his teammates as less approachable than you do.
Let him share his ideas a way he feels more comfortable (maybe an RFC/document write up he can share via email/slack, etc).
I would recommend being explicit about this expectation with him. Some shy people are badly calibrated and have the erroneous impression that they are speaking too much already leading to their low contribution rate. Make him aware of this issue and get his response to why it is happening and working together to address whatever the issue is. You may also want to directly call on him in meetings to solicit his opinio…
Um, so a meeting will go from "very uncomfortable" to "anxiety inducing Russian roulette standup".
Maybe collaborating and theory crafting on a task could take the pressure off his ego and image. Focusing on him could be a mistake, getting him wrapped up in a group task could be enough to dissolve the shyness.
1. pair programming
Pair programming, if done correctly, encourages you to communicate with your partner. If he is shy, he won't be to excited about it, so I would start giving him the possibility to attend a pair-programming session of two other developers working at a pretty trivial task.
2. coding dojos
Participating a coding dojo and solving a problem in groups of 2 or 3 devs can support you not being shy about presenting your solution. A fizz-buzz unit testing dojo maybe would be too trivial, but I think adventofcode[1] may provide some interesting problems that have nothing to do with your daily tasks.
3. Code reviews
Weekly 45 minute code reviews build up a regular practise and knowlege transfer. My recommendation would be that you start by having a conversation about a piece of code, that everybody likes to get into a positive mood. Presenting something that you are proud of can be a problem but discussing a problem about an existing solition is often a common ground.
I'd suggest not trying to change him. Instead, enable him. Let him share his ideas a way he feels more comfortable (maybe an RFC/document write up he can share via email/slack, etc).
I would suggest a combination of pair-programming, coding dojos and code reviews with NO force to participate. 1. pair programming Pair programming, if done correctly, encourages you to communicate with your partner. If he is shy, he won't be to excited about it, so I would start giving him the possibility to attend a pair-programming session of two other developers working at a pretty trivial task. 2. coding dojos P…
I think the better question to ask here is, can you get the input you're looking for out of the guy through a method that best suits their style. These suggestions are very 'force the round peg into the square hole' - like; the guy's shy? ok, we'll fix that by ramming him into situations where shyness isn't permissible until he gets over himself.
It may be better to figure out how they can best deliver their contributions; some people prefer to digest input and write emails than engage in a 'face to face' because they see that as inherently adversarial and tend to back down.
At the end of the day, not everyone is going to be able to stand up and advocate loudly for themselves in a group scenario; that does not make them a bad contributor. You need to evaluate their ability and ensure that your processes do not mean that an insistence on 'face to face, talk it out, say what you mean' style of communication in the business results in their contributions getting steamrollered.
I would suggest a combination of pair-programming, coding dojos and code reviews with NO force to participate. 1. pair programming Pair programming, if done correctly, encourages you to communicate with your partner. If he is shy, he won't be to excited about it, so I would start giving him the possibility to attend a pair-programming session of two other developers working at a pretty trivial task. 2. coding dojos P…
If the guy is just - for want of a better word - genetically shy and a sole-contributor type who likes to take tasks and bunker down and churn out code, implementing any of these suggestions will probably make them snap quit. I think the better question to ask here is, can you get the input you're looking for out of the guy through a method that best suits their style. These suggestions are very 'force the round peg…
I'm pretty useless in sprint refinements with asking questions in a group setting, but if I'm given a set of requirements or mockups, I'll knock it out of the park every time. Been doing it this way for almost decades now. I didn't snap quit when a previous employer started trying to get me more sociable but I was gone within a few months.
OP would be well-served to take your suggestions if they want the developer to stay.