I recruited a junior developer for my company who I knew to be very shy and reserved. He has been working with us for almost a year in an open-minded and low-hierarchical company.
He is a good player, but his shyness prevents him from sharing its ideas and contributing to the company's progress like any other employee.
Do you have effective management techniques that I could use to help him?
I'll probably suggest him to make small informal technical talks within the team or even in public to show him that he has things to share. But i'm sure some people tested very good method.
Thanks for your responses \o/
If you're happy with his "good player"ness, then leave him the hell alone. People trying to crack me out of my shell "because reasons" get an opposing and forceful response from me. I hate feeling manipulated against my will, and if you want me to be some sort of performative marionette and not a coder, then we're not right for each other, and I will be leaving soon.
Weigh where you value this developer. Not everyone gives a hang about "contributing to the company's progress" in the macro, and are content with micro problems.
I say this as a Sr. who has been somehow railroaded into a Lead/Management role that I loathe, and it has ruined a great situation for me, and it will soon ruin it for my employer. And my manager doesn't understand my objections, as many times as I have told him.
$0.02. Have you bothered to ask this dev if his quietness is indicative of anything other than his shyness and reservedness that you already knew and are somehow not respecting? Maybe Email it and await his response. It might blow your hair back. The howler you'd get from me, if I respected you enough to be honest, would certainly adjust your posture. :)
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.
It is possible that he sees his situation as perfectly fine and not in need of any correction. In that case any change in his behavior would be caused by pressure from others, and I am not sure this is a good outcome.
You may also want to directly call on him in meetings to solicit his opinion thereby forcing him to speak ("Hey Bob, we haven't heard your thoughts yet, what do you think about option XYZ?"). If you do this often enough, he may see that his fears about speaking up are unfounded.
Um, so a meeting will go from "very uncomfortable" to "anxiety inducing Russian roulette standup".
But, I mean really small. Do you do much pairing at your company? Just sitting down with him and 1:1 and getting him to show you his stuff and then slowly expanding that group with people that he feels comfortable with. That's what I did anyway - I even did my first conference talk this year.
Do not throw him in the deep end and make him the focus of something that he's not comfortable with. When in a group as well take more pauses so he has a chance to speak and invite his opinion occasionally.
Hope you can work it out, if you can you'll do him a massive favor.
I also had many casual discussions with my manager so that helped me open up with him. Later I had discussions with other (equally welcoming) senior devs. Now the whole team feels like friends to me and I generally don't shy in speaking up.
Let him share his ideas a way he feels more comfortable (maybe an RFC/document write up he can share via email/slack, etc).
Second, examine your own relationship with him. Does he trust you as a manager? Is he open to your feedback? If not, you should work on building that relationship - you know how you can/should do that.
Finally, once you have that relationship and understand the root cause, give him constructive and candid feedback. If he's shy by design, you could have a constructive conversation about it - does he perceive it as a weakness? Does he realize that it might be holding him back? Make him think and align on a plan to help him overcome it. If he's not seeing psychological safety in the team, dig into how the team works and make a plan for yourself to fix that.
Then make this part of your regular 1:1s and track progress. Important that he sees that you are vested in his success and are genuinely helping him.
Needless to say, this assumes that you want him on the team and help him become a better version of himself.
Psychological safety is by far the most important requirement for group participation. You could be doing everything right for people in the middle of the bell curve and still have this person struggling because of something very specific to their childhood or personal experience.
Do you have an email address or a contact method?
You can introduce your team to various books/videos/articles around people overcoming all sorts of challenges on a day to day basis.
Such an environment motivates everyone to take on challenges: fitness, intellectual, social, and so on.
It is important not to single out anyone on a particular dimension. Acknowledge that we are all lacking in one area or the other - so make it a general team thing, something super normal within your group to work on enhancing both strengths/weaknesses.
As a practical step - share your own shortcomings, and how you have/are overcoming them. This sort of personal struggle, and your efforts to overcome will motivate others to share their own struggles and overcome them.
We discussed it and tried a few things, but ultimately what worked for him was to write down some bullet points about what he wanted to say before a meeting. This gave him time to do the thinking up front and relaxed him greatly.
Turns out he was really quite clever and chatty. It can just be very intimidating to think and talk on the spot amongst a group of experienced peers.
Ultimately they may never be the most chatty member of the team but some output is far better than none and encourages the contribution to grow.
What does he say about why he’s reserved at work?
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.
[1]: https://adventofcode.com/
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'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.
If anyhow I ever get into such a situation, I feel better prepared.
Thank you.
Some people are shy or reserved, some people are happy to follow and go with the flow.
Trying to force a shy person to be outgoing can backfire and you'll lose a valuable teammate.
Can't personally think of anything more likely to make an entire team quit in unison.
It isn't that the workshop was bad, or uncomfortable. They did a good job making it work for everyone. It was more of a realization of how blind the leadership was to truly understanding their people and finding ways to work together that made us all thrive.
Clearly the OP sees the net problem and wants to fix it. But you want to do it in a win-win way.