I asked my team to tell me what they did last year…something magical happened

Software developers have been stereotyped as unsociable, uncommunicative, eccentric, or just plain odd. There’s always empirical data to support any stereotype — but we’ve learned to be cautious when applying our data to everyone.

So before we toss all developers into the same bucket, let’s take a timeout. Perhaps it’s possible that most developers actually exist in the fat part of the bell curve of behavior but aren’t often given the opportunity to show their personalities or individualism in a curriculum that demands binary answers to often ambiguous problems. Their affinity toward (and reward system that perpetuates) the binary may infect any dalliance into the nuance of actual human interaction which is anything but binary and deterministic.

I’m here to tell you are doing your team a huge disservice by buying into the developer stereotype and you should reject it as your a priori modus operandi (it always feels good to throw some Latin into the conversation). If you accept the iconic developer view of your team, you may be the one molding your team into anti-social coding monkeys. Yes, the problem may be you, not your team.

Including me, my team consists of 13 IT professionals. In our heyday we had over two dozen in our group, but various business mergers and acquisitions have reduced our number. Thank goodness we moved our stack to the cloud — but that’s a different story. Needless to say we are kept very busy supporting a $40M/year business unit. My team is responsible for supporting the entire stack — from infrastructure in the cloud to software applications, billing, and financial reporting. We rely on mostly homegrown applications using open source software.

Accordingly, our heavy workload makes us a quiet bunch. Other departments comment on our steady state approach, the lack of drama and the low profile we maintain. Historically, it’s been difficult to engage the team socially for the most part. So, when I asked my Director to schedule a town hall in which my senior technical staff and developers would present their achievements for the previous year and their goals for the new year, it was met with groans and pushback.

“Why do I need to tell you what I did? You already know!”

“You mean I have to stand up in front of everyone and speak?”

“I have dentist appointment that day.”

The fact that someone would rather go to the dentist (literally) rather than speak in front of the group of people they’ve worked with for years is telling. Since I had already provided a framework for the town hall and limited their required time to 5 minutes, I knew this would not be a big lift for them and even the most reluctant of them could muster a 5 minute Power Point slide with 3 bullets. No passes — everyone would be required to participate. I wondered to myself whether I’d get any *real* pushback with someone going to HR to protest the requirement. In the end I rationalized that their broad HR written job descriptions actually did cover this type of activity…”ability to communicate effectively with peers and supervisors…”

The methodology was to create a safe environment, limit the required talking time and provide a basic outline to help them prepare their presentations. In this way, we could keep them at ease and engage them in our yearly planning exercise. I had my Director work with each developer on their presentation so that we had a cohesive and somewhat interesting day of actual social interaction.

Here was the agenda for the day:

• 2018 Recap of Achievements
• Cloud infrastructure and migration (Senior Architect)
• Major projects (Technical Leads)
• Process Improvement (Director)
• Lunch
• Staff Presentations
• Project participated in
• Role played
• Learning milestones
• Goals for 2019
• 2019 Business/Department Goals
• Cloud infrastructure (Senior Architect)
• Business Objectives (VP Technology)
• Q & A

And guess what? It worked! To my suprise, the 5 minute presentations were at least 10 minutes with some lasting as long as 15. The developers were informative, clearly proud of their accomplishments, deferential to their peers acknowledging each other for the help on their projects and even entertaining.

What I learned was how well my team works together, what excited them about their projects, and the roles they played. It was clear that rather than being intimidated by the situation, they rose to the occasion and opened up by showing their personalities and enthusiasm for their work and each other.

In retrospect, I think this worked because of specific things we did. In no particular order:

• We restricted the attendance to the department — at first I had contemplated inviting our product development department, but in the end felt that a safer setting would keep everyone at ease.
• We provided a framework that was simple and easy to follow and told them they only had to present for 5 minutes
• We provided assistance in creating their presentations. Each presentation was reviewed with the Director
• We offered a free lunch and a day off from the grind :-)
• We required everyone to participate in one way or the other
• We shared a vision of the future with them before asking them to build it

A yearly recap and look ahead may be a good way to engage your team. It worked for me.