Skip to content

The Secrets of Computer Programmers: The Shy Programmer

The shy developer is the secret desire of all development managers. They sit quietly in meetings, diligently take notes and routinely perform tasks as expected getting the work done on time with reasonably quality. If only all developers could be like the shy ones. Beyond all of the sunshine and rainbows, however, there is something to worry about with shy developers.

If you have ever watched participated in a developer meeting with strong Type A project managers and a room full of quiet and reserved developers you will notice a lot of agreement. Well, not so much agreement as a lot of talking by the project manager and a lot of nodding by the developers. The PM points and asks direct questions and expects immediate answers. The silent and strong developer trembles and responds with enough of a reply to get the attention away and the meeting continues on. When adjourned the developers scurry back to their dungeon and the PM sits back in his chair congratulating himself for a job well done.

Is this a job well done?

I don’t think so. Healthy teams have healthy communications and healthy communications involve conflict. I read a book where the ideal conflict was described as Level 1, polite but openly willing to disagree and work towards a solution. I apologize, dear reader as I cannot find it on my shelf to directly reference, it is a good read. Irregardless, to use a word that isn’t a word, a meeting where one person talks and no one communicates is not a job well done. No communication has occurred and you are not creating a truly high-performance team. To put it in perspective of the zones, if your programmers are all shy and unwilling to speak up then you will never have a complete Zone 1 team.

I don’t want to pick on the alpha male project managers here. They are not the sole culprit. To be fair I have, one time or another, stepped on another who was trying to communicate and inadvertently created environments hostile to open communications. Also, the arrogant programmer, as a defense mechanism will do it all the time. Just because it happens and just because we all do it does not mean we want to encourage it as part of our times. We need to seek out and quash behaviors that do not facilitate open communication but beyond that we need to identify and improve the ability of our shy developers to openly convey their ideas and opinions. If not that we merely have an echo chamber.

Is Shy Bad

Absolutely not! It is easy to want to apply a negative connotation to the shy developer to attempt to make them less desirable but that is the wrong idea. We are not seeking to “fix” shy merely to find avenues to help the shy developer communicate more openly. As a software development manager it is very easy to create an environment where “all opinions are valued” when nobody can speak; instead we should take the hard route and value all opinions and create an atmosphere where they will be expressed. There are many ways to do but I will only highlight a few.

The Token

Have you ever read William Golding’s, “The Lord of The Flies”? Well, in his book the boys use the Conch shell as a token of rule and authority. Whoever holds the Conch gets to speak. A similar device can be used with your teams, in the beginning, if you are having trouble with other techniques. You don’t have to pass the token around the table merely set it in the middle so any one can reach it and hold a conversation like normal. If a team member picks up the token immediately stop all conversations and let the person with the token speak uninterrupted and with undivided attention. This isn’t the time to send text messages on your phone, update power point, or check email. Every single person in the meeting should provide complete attention. Close your laptops even. When the token is replaced pause for a moment to see if another goes for it and if not resume normal communications.

Anytime you feel the communication of the group to be one side you as the leader can pick up the token, silence the conversation and ask for diversity of opinion. If there is not a diversity of opinion you can hand the token to an individual and ask for a devils advocacy. Spark the conversation.

The problem with the token is that communicating with it can be slow. Taking time to put down the token and pick it up doesn’t allow for true rapid fire communications. Plus, shy developers may never reach for the token unless you force it upon them. And while you should do that on occasion, remember it isn’t fair to openly create an environment hostile to someone’s personality.

Squash the Tyrants

Are there tyrants in your meetings? You know the Type A PM who doesn’t allow disagreement or the arrogant developer that demands his way or the highway, the overzealous manager with long winded speeches that cause time to overrun? You need to squash this bad behavior. Not after the fact in private but during the fact in public. We want to build a team communication environment where everyone can contribute. This safe environment will help shy developers to want to speak up. Tips?

After the PM states his demand (if you are not scrum) speak up and state: “Ok, the PM would like to do X, lets discuss what needs to happen to make this happen” move the conversation away from the individual and back to the group. When the necessary conversation has occurred yield the floor back to the PM. Don’t let anyone one individual dominate the meeting. If you do then it isn’t a meeting it is a memo.

Is the arrogant developer talking down to someone who dared to speak, maybe your shy developer?

Manager: “We don’t talk to people on our team like that. Everyone has an opinion. Jake (your shy developer), I want to hear what you have to say on the matter, go ahead”

Don’t tolerate continued abuse. If it continues, unabated, you can ask the arrogant developer to leave.

Eliminate Distractions

Have you ever walked to a podium and looked out into an audience of a few hundred individuals and been discouraged when you noticed the entire audience was more interested in their phones and their laptops than you? Now imagine your shy developer sitting in a meeting with his peers, the people whose opinions he respects, beginning to speak. When his voice rings out into the room all eyes divert from him to the respective listeners device of choice and slowly Jake’s (the shy developer) voice trails off and someone more dominant immediately steps in to fill the void.

A meeting is a time for team work. If you have not called the meeting for teamwork then use email, it will save time and money. If you are in a meeting your attention should be directed at the person speak or writing on the board. Side conversations, side meetings, preparing for the next meeting, texting, emails, and any other activity is unfair to the speaker. While most of us are able to carry on without undue distress shy developers only see this as negative reinforcement in their abilities and since a lot of developers define who they are as what they do you are further taking away from them creating a cycle that only increases shyness and decreases collaboration.

Set the standard for your meetings that distractions are not allowed. Phones must be in pockets and laptops left at the desk. Your meetings will go by a lot quicker and you will get a lot more done. In fact, this is a great tip even if you do not have any shy developers

Proto Agenda

Meeting agendas are great and you should do those anyway but what about the attendees? Usually most developers show up to meetings without an agenda and just wing it. This is great if everyone forms their thoughts well and is able to get their agenda across but what about our shy developer? A method that seems to work well is the proto agenda. After sending out the agenda ask that every attendee create their own smaller list of items. No real detail but enough to be a contribution and then collect them at the beginning. With everyone’s thoughts collected you can then make sure each individual gets an opportunity to express them. I don’t like to get proactive in the beginning, try to let it happen naturally, only interfere towards the end if everyone is not heard.

The Proxy

You have bi-weekly 1:1s with your development staff right? You don’t? They are annually? Well you are really missing out. Anyway, a bi-weekly 1:1 is a great opportunity to learn more about your developers, how they are working, the challenges they are facing, and they great ideas they are having. You don’t want to wait for them to come to you; instead you need to come to them. With the power of these 1:1 sessions you can identify thoughts and ideas from shy developers and then formally bring them up in meetings.

Manager: “I was speaking with Jake the other day and he had this great idea. Jake’s idea was … (paraphrase), Jake would you like to take it further?”

Build your team up and give them the credit they deserve. Jake, the shy developer, now knows his idea is great, the boss said so, and with undivided attention in the room he can speak up. Slowly working on his comfort level with the team.

Summary

We don’t “fix” shy developers we merely want to create an environment of trust where they can openly communicate and feel values. Often this is described as opening up. It may take more work for you as a manager to take the time to value your shy developer like you value your rockstar but when you put in the effort you will be rewarded. As a bonus, team members who feel their contribution is valued feel significantly more loyalty to their company. And a shy developer is not going to want to relocate to a different company or a different team within a company and risk starting over when they know how valuable they are to their current team. Shy developers are great assets when you put in the work as a manager.


Ennis Lynch

Ennis Lynch

Ennis Lynch is a Professional Coach Based in South Florida. His primary area of coaching focuses on coaching Software Engineering Leadership. On occasion he does Agile Transformation work as well but prefers coaching at the Team and Individual level vs. the organizational level.


If you have ever wondered: is professional coaching right for you ? Are you a Software Engineering Manager, Director of Engineering, Director of Software Engineering, VP of Engineering, or CTO reach out for a free initial coaching session. Initial coaching sessions are the real deal, no hard-sells, no "here is what you would get if you paid". Individuals that receive a free coaching session will get a normal private professional coaching session of 90 minutes (30 minute onboarding + 60 minute coaching) and it will be up to you to follow-up if you want to continue with help on your journey.


Ennis Lynch

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *