I was recently asked a question regarding our developers and whether they should be representing the IT groups on conference calls with senior leaders. This is a very interesting question. Common stereotypes suggest that a developer has problems relating to people, often using lingo much too technical for their audience, blowing by business issues and going straight toward technical concerns as the primary objective.
In my experience, the results are varied. For some, this stereotype definitely holds true. These developers mere presence on the call means there are highly technical items to discuss, and you will be discussing them whether you want to or not. This type of person typically makes it difficult to focus on the core issue and a potential resolution or decision. The other type of developer I run into –slightly more regularly– are those that have a very good grasp of business concerns. They have attended enough business discussions and requirements gathering meetings or demos to get good at understanding of the level at which business partners interact and converse. This person is very relaxed, confident, but not presumptuous about another persons ability to comprehend or even care about highly technical concerns. I think this type of developer has worked on their “bedside manner”.
In medical parlance, this term means that a doctor brings the conversation to the patient, and does so with a human-centered, respectful mindset. Essentially it means they can “communicate” with their patient. A basic encyclopedia definition of the term says, “A good bedside manner is typically one that reassures and comforts the patient. Vocal tones, body language, openness, presence, and concealment of attitude may all affect bedside manner.”
I cannot think of a better term to use to describe what I feel is a skill that ALL developers and team members need to master. Why? Well, I can think of 4 reasons why a good developer “bedside manner” is important to the agile software developer.
1 – Communication is King!
In today’s complex technical landscape, communication is king! If we as developers don’t have the ability to communicate changes, inquire about a business person intentions, seek clarity, and help the customers refine their needs, then the promise of agility is lost. It is even more critical today that we as developers and team members are able to communicate in the language of the users. This is evident from our daily interactions in stand ups, through our ability to help craft artful user stories.
2 – Teams, They Are a Changin!
On agile teams, more often then not a non-technical business person is part of the team. When that is the case, every conversation cannot revolve around the most granular, hard core technical topics of the hour. In fact, even without business people in the room, an agile developer is more likely to encounter the need to converse in the language of the business when discussing requirements with BA’s, or exit/done criteria with testers and QA.
3 – Which One of You is the Architect?
The roles on a software development team are continuing to be blurred. Developers can no longer be insulated from other roles in the organization. When problems are brought to the team, we can no longer hide behind the one or two developers who “are good in front of the business”. We are ALL in front of the business. We all have similar titles and multifunctional roles, not to mention responsibilities for demoing working software. At no point can we feel like communication can be left to the team lead or the architect. Those roles are being blurred and we all need to pick up those characteristics to be successful.
4 – Shameless Self Promotion
Developers need to be aware that communication and successes with business partners also affects their ability to be promoted and make more money. This one seems obvious, but to many developers its not. I can’t tell you how many “one on ones” I have been in where a developer will say, “Communicating isn’t my strong suit. Just tell me what to build and I’ll build it!” This is wrong on so many levels, but the main one is this: communication is part of the gig. If your code is elegant, and your solutions are brilliant, but don’t address the business person need, we are still NOT delivering value. If you want to do that type of development, go work in academia or do research. In the business environment, the organizations ability to realize value hinges on our ability to extract the essence of a business persons desires for a system, and codify them for our customers. And at the end of the day, if that runs smoothly, everyone is rewarded.