Category: Education

Question For Developers: How Do You Rank The Importance Of Communication Skills?

AdventureTech was recently involved in a job fair hosted by KCITP and offered professional development as a value-add to job seekers that attended. For us, it was a perfect fit because one of our target audiences is, of course, developers.

We’re not shy about our opinions and we love sharing them with exactly this type of audience. We like helping developers out however we can, but we often end up talking to them about the one thing they aren't always ready to hear. Yes, it’s the 500 lb. gorilla in the room – interpersonal and general communication skills.

Many developers think they can get around the need for effective communication skills by simply having excellent programming skills. And we suppose some can. In fact, we spoke with a technical recruiter for a major local company at the KCITP event and they were quite happy to have certain “developer types” who would just sit quietly in cubes and program all day long.

We have to wonder if they are supporting the stereotype, lowering expectations, and accommodating weak interpersonal skills or if they simply don’t want developers and end-users working together.

From our perspective, this is a dysfunctional situation and ultimately a dead-end for the careers of developers. One of our core beliefs is that developers should be communicators because they are ambassadors of change who touch every aspect of a company’s reach.

One developer asked us what he should focus on in his career if he wanted to eventually make it in to management. He asked if he should get his Masters in Computer Science or perhaps more certifications or perhaps even an MBA. Another asked how to improve his communication skills – was there a class he could take, a course?

Our answer to these (and any other developers) is the same: Focus on your communication skills. Practice them. Seek out feedback. Get out of your comfort zone. Take a communication class or two or three or four. Engage with other developers (and people outside of our field) that have strong communication skills. Commit to it, practice it, and we are confident that your career will be the better for it.

If you think about it, it’s the same lesson on the technical side of your skill set. You can take a course and get certified in a particular specialty, but then you have to practice what you’ve learned in order for it to be applicable. Same goes for your communication skills. In fact, did you know that there are Communication Studies degrees in college? One of our social media partners, Mic Johnson, graduated with a Bachelor of Arts in Communication Studies from The University of Kansas. His wife has a bachelors degree AND a Master's Degree in Communication Studies. Excellent communication skills can be learned.

Now a course, class or degree program is no guarantee that you will be a good developer or anything else for that matter. You can load your cubicle walls with all sorts of merit badges and certificates but the acid test is simple day-to-day communication. You can improve these skills with friends, with coworkers, with clients, with your spouse, or through other avenues. At AdventureTech, we encourage developers to speak publicly, write regularly (blogs, articles, comments, emails with good business etiquette, etc.) and, most importantly, proactively embrace face-to-face interaction.

If face-to-face communication is outside of your comfort zone, it's important to know that you aren't alone and that you can get better. Additionally, it's critical to understand that you are potentially creating your own professional ceiling by ignoring the critical role that communication skills play in the world of the modern day developer.

If you are inclined to practice and improve your communication skills, we would offer one final piece of advice: Practice with non-developers because they are often the decision makers in business and the people you will work with on project after project over the liftetime of your career.

What do you think? Where do you rank communication skills in your overall skillset? What have you done to improve your communication skills? What advice do you have for others?

Did you like this? Share it:

7 Interpretations of Silence

Listen

Listening to clients is at the core of solid communication efforts. This is perhaps even more important to IT professionals than it is to average consumerism because we often deal with complex topics.

But listening is not simply affording someone the courtesy of audience, nor is it simply letting them speak because it’s their turn. The goal of listening is to understand the true nature of a client’s problem. It is an interactive, engaged discussion of discovery whose fruits are clear problem determination and resolution. In that order.

Demanding that any client, user, manager or executive fully explain themselves is not good listening either. It is a poor one-way model for collaboration; it builds fences NOT bridges. When communication goes south, you will probably be faced with silence out of nothing more than false politeness.

Understand that silence and head nodding agreement can mean one of several things:

1 – Mission accomplished

Yes, I’ve understood you!

This is typically the one we WANT to hear, so we presume it to be so most of the time.

The Risk? Potentially none, but ignorance is bliss.

2 – Partial absorption: Requires further baking

“I haven’t understood you completely, and I’m still attempting to process all of what you’ve told me. I might require more time to fully understand all this information, and may have questions later when some of it starts to sink in. I might ask you again, but then again, I might not…”

The Risk? Partial knowledge or interpretation means the client will fill in the missing pieces with what they *think* they heard. Those assumptions will come back to bite you – especially if they choose not to reengage the dialogue.  

3 – Looking the fool

“I haven’t understood you, but I don’t want to look foolish in front of you because you act like your time is important – OR – I haven’t understood you and we are in a group setting. I don’t want to look foolish in front of my peers, boss or subordinates. They’re all nodding their heads and seem to get it, so I’m hoping someone will explain it to me later in language I understand.”

The Risk? No one likes to feel they haven’t understood something. Fear of asking important questions early leads to a paralysis of activity and co-operation later.

4 – Research required

“I haven’t understood you completely, and am hoping to research this all a little further to fill in the gaps myself. I have some lingering questions that I believe I need to ferret out myself.”

The Risk? IF a client takes it upon him/herself to get educated on your topic, understand that it is still potentially non-communicated. You won’t know if they actually performed any due diligence, so you cannot assume they did from silence.

5 – Wait and see

“I’m a practical/visual type. I’m hoping that later on, when I actually see this all in action that it will finally make sense. I’ll let you continue your speech and involve myself when this idea is made reality, and then provide feedback.”

The Risk? While you now believe that everyone has signed off and will start on your plan, this individual is withholding his/her vote of acceptance until it’s actually up and running. The potential waste of work here is high, and the 11th hour death-marches start with this definition of silence.

6 – The personal touch

“What I’m hearing is that later, you will hold my hand in this process and personalize it to me. I’m expecting that you will follow up with me personally, and your speech today is just an introduction.”

The Risk? Personal touch types cannot work from pieces of paper, emails, phone calls or boardroom presentations. They require face-to-face communication and an emotional connection to a concept. Without that personal touch, this type of individual will fail to engage. Silence of this kind is in the form of non-communicated, assumed, personalized expectations.

7 – Assumption of ownership

“I’m assuming that you are just explaining this to me out of full disclosure, but that you will actually be the one doing it because you’re the one giving the speech.”

The Risk? What this individual has heard, is that you are in charge of this entire process. They expect to be managed rather than a willing and active team participant exercising initiative. They expect that you will be the one both watching to see if a ball is dropped and catching it.

And the list goes on…

If you are the type of individual who always believes that silence and/or head nodding means #1, your professional life will prove to be a frustrating one. Do not attempt to interpret the meaning of silence – you will fail miserably and it will only serve to dismantle trust and foster antagonism.

Do not place the burden of silence on the client. When you hear silence, flush out misunderstandings with empathetic, engaged, courteous dialogue. When you see a look of mild puzzlement on a clients face – ask questions and try another angle. It means that at least one thing you have presented did not click with them.

The responsibility is on you to facilitate a solid understanding with your audience not for them to simply participate as spectators of your speech.

Silence is a red flag. Know how to spot it and use it to create a positive client experience.

Did you like this? Share it:

The New Model Is Here: IT and Business Must Work Together

For decades now, business and IT have been perpetuating the Division of Labor model to get work done. There have been a lot of reasons for this but the reality in today's world is none of those reasons make sense. Five recurring themes that have developed over the years include:

1. Business doesn’t really know what they want, so IT should go away for a few months in a vacuum and figure it out for them.
2. Business can’t effectively communicate their needs, so IT should force them to spell it out with ridiculously excessive documentation and hold them accountable if they change their minds.
3. Business has forgotten all of the technology decisions they've made so IT should manage those conflicting cross-departmental business decisions.
4. There are so many cool things IT could do to help business – we should just do them and ask for forgiveness later.
5. Business has difficulty communicating with technology types so they put requirements together in a series of documents and throw it over the fence to IT and wait to see what they come up with.

In today's world, technology changes rapidly and permeates every aspect of business. So is it still valid to be looking at the Division of Labor model as the right one for a business and technology marriage?

The only truthful answer is NO. It just doesn't make sense anymore.

It’s simply impossible to know everything about your industry (let alone someone else’s) because of how quickly things change. In order to write high quality software that adds real value to the business, there must be an ongoing, collaborative exchange of specialist knowledge between IT and business.

At AdventureTech, we believe and continually foster an environment where that knowledge exchange is done face-to-face with cross-directional, open, honest, and valid feedback. We understand that this approach is new to many on the business side of the fence. But we also know that if business will work with us to get out of their comfort zone and dip their toes into the world of technology (and vice versa), then we open the door to a collaborative knowledge exchange that will undoubtedly result in both a rewarding experience and a sucessful software project.

Tell us what you think. What have your experiences been with IT? How do you think the process can be improved?

Did you like this? Share it:

Dropping The “I” From Interfaces

Blanket man

Image via Wikipedia

This is not really disruptive. It’s not even a new idea. This has been blogged about before. But one thing that I think seems to get missed is the fact that that “I” maybe keeping developers from understanding the real power of interfaces.

The way that interfaces generally get used is the “I to a type” convention. So I might have an IAuthenticationService and an AuthenticationService, or IUserRepository and UserRepository. Unfortunately, the implementation class doesn’t tell us anything about what makes him an implementation, let alone what sort of implementation. Developers begin to lose sight of the fact that the interface is the contract that everyone agrees on, and the class is an implementation of that contract. Now lots of developers know this theoretically, because it’s been beaten into their heads. It’s memorization. And you might be okay all you life just memorizing that. But I think it’s better to crystalize in your head what interfaces bring to the game. There are two suggestions floating around about what to do with the “I” in interfaces:

Use It

Some folks suggest using it as a proper noun followed by a verb to almost make a declaration of what this contract you’re about to build is for. For instance, if you are making a service that reads files from the file system, you might call your interface IReadFiles, or a calendaring service might be called ISetAppointments. This is fine, but I think it feels uncomfortable to name implementations. The IReadFiles is implemented by the FileSystemReadFiles class or it is completely removed with FileSystemFileReader class.

Lose It

The other school of thought, and the one I favor and have been practicing whenever I can for the last two years or so, is to remove the “I” completely. So my IAuthenticationService becomes AuthenticationService. This has three distinct advantages: I am now forced to name my implementation something meaningful like FormsAuthenticationService. When I am using the interface in my consuming code, it has no inkling from the name that this is an interface (which is the way you should use interfaces. Finally, it can become very clear to programmers what the Interface brings to the game. The Interface is a Generic AuthenticationService it does certain things somehow. The implementation(s) are actually more clearly defined and help developers understand how and when to use different implementations of an interface. Sometimes, just understanding that you can have multiple implementations is a breakthrough for some programmers.

I know this is the programmers last Hungarian Notation Woobee and developers don’t want to let go. But on your next small project, try dropping the “I” from your interfaces and naming your implementations with meaningful names and see how it feels. In the words of Tony Toni Tone, it “sure feels good to me”.

Did you like this? Share it:

4 Characteristics Of Every Great Developer

At AdventureTech, we spend time carefully fostering what we refer to as "a community of developers for developers". While it might sound like an altruistic endeavor to allow local talent to congregate and collaborate, we believe it’s an essential component of every successful software development project. But there’s something in that picture that needs explaining and it speaks to the very reason we seek out excellence in Kansas City:

NOT ALL DEVELOPERS ARE CREATED EQUALLY!

With that in mind, let's take a look at 4 Characteristics Of Every Great Developer. This isn't meant to be an exhaustive list, but these characteristics are ones that are critical to successful software development projects.

1. Pure technical excellence. This one kinda goes without saying, but any great developer has extremely strong technical acumen.

2. Be a good systems thinker with the ability to understand how technology fits with business needs and knowing how to deliver value AND software.

3. Be a strong educator. When confronted by users “not getting it,” a good developer takes the time to explain choices and options in technology. Software development is truly a learning culture and placing clients within that team spirit affords the highest possible business value.  

4. Strong written and verbal communication skills. We saved the best for last and want to expand on this topic because we believe it is increasingly important and not discussed enough in the developer community.

At AdventureTech, we believe it’s important to speak directly to the traditional criticism surrounding the lowered expectation levels for communication skills in IT. While below average interpersonal skills are not unique to IT, we believe they lead directly to antagonistic client relationships, misunderstood software requirements and ultimately delayed projects. Stressful communication environments quickly erode customer confidence and can provoke the need for intermediaries. Business analysts, for example, are often simply replacement ambassadors to this forced need for mediation and translation.

Forcing the developer/client relationship into the realm of signed and sealed paperwork does not mitigate this antagonism either. We believe it only exacerbates it. Face-to-face collaboration is critical to project success and breakdowns in communication should be addressed directly and personably. When done correctly, the end result is successful, collaborative software that meets the needs of the client.

Have you ever sent an email or instant message to a client where the tone or intent of your message was misinterpreted? Developers who choose email or instant messaging as preferred methods for communication run an increased risk of miscommunication. While that preference might be appropriate for developer-to-developer interaction, we prefer face-to-face or phone calls when collaborating with a client. Email carries with it an inherent danger of allowing people to be braver (and less personable) than they otherwise would be face-to-face.

Additionally, blogging, writing articles, and speaking engagments are invaluable ways to stand out from the crowd of technical excellence. We not only hire educators and public speakers; we also encourage every developer to have their own personal blog and to contribute to the AdventureTech blog.

Clearly, everyone has different levels of proficiency when it comes to written and verbal skills…and that's OK. The only way to get better is to continue to fine tune these skillsets (just as you do your technical proficiencies) and seek out feedback on how to improve from people you trust and respect.

Those in our industry that do will undoubtedly evolve from good developers….to great ones. And that's GREAT for everyone involved.

What do you think? What have you done to improve your communication skills? What other characteristics do you think are important to becoming a great developer?

Did you like this? Share it:

Connect With Us

     

Contact Us

Toll Free: (888) 373-8718
Main: (913) 402-9600
Fax: (913) 402-9603
7450 W. 130th Street
Suite 320
Overland Park, KS 66213

Upcoming events

  • Events on May 16, 2013

    LWS Lunch

    Starts: May 16, 2013, 11:30 am

    Ends: May 16, 2013, 1:00 pm

    Location: DEG Offices

  • Events on June 18, 2013

    Kanban Training

    Starts: June 18, 2013, 12:00 am

    Ends: June 20, 2013, 12:00 am

  • Events on June 20, 2013

    LWS Lunch

    Starts: June 20, 2013, 11:30 am

    Ends: June 20, 2013, 1:00 pm

    Location: DEG Offices

  • Events on July 18, 2013

    LWS Lunch

    Starts: July 18, 2013, 11:30 am

    Ends: July 18, 2013, 1:00 pm

    Location: DEG Offices

  • Events on August 15, 2013

    LWS Lunch

    Starts: August 15, 2013, 11:30 am

    Ends: August 15, 2013, 1:00 pm

    Location: DEG Offices

  • Events on September 19, 2013

    LWS Lunch

    Starts: September 19, 2013, 11:30 am

    Ends: September 19, 2013, 1:00 pm

    Location: DEG Offices

  • Events on October 17, 2013

    LWS Lunch

    Starts: October 17, 2013, 11:30 am

    Ends: October 17, 2013, 1:00 pm

    Location: DEG Offices

  • Events on November 21, 2013

    LWS Lunch

    Starts: November 21, 2013, 11:30 am

    Ends: November 21, 2013, 1:00 pm

    Location: DEG Offices

  • Events on December 19, 2013

    LWS Lunch

    Starts: December 19, 2013, 11:30 am

    Ends: December 19, 2013, 1:00 pm

    Location: DEG Offices

  • Events on January 16, 2014

    LWS Lunch

    Starts: January 16, 2014, 11:30 am

    Ends: January 16, 2014, 1:00 pm

    Location: DEG Offices

  • Events on February 20, 2014

    LWS Lunch

    Starts: February 20, 2014, 11:30 am

    Ends: February 20, 2014, 1:00 pm

    Location: DEG Offices

  • Events on March 20, 2014

    LWS Lunch

    Starts: March 20, 2014, 11:30 am

    Ends: March 20, 2014, 1:00 pm

    Location: DEG Offices

  • Events on April 17, 2014

    LWS Lunch

    Starts: April 17, 2014, 11:30 am

    Ends: April 17, 2014, 1:00 pm

    Location: DEG Offices

  • Events on May 15, 2014

    LWS Lunch

    Starts: May 15, 2014, 11:30 am

    Ends: May 15, 2014, 1:00 pm

    Location: DEG Offices

Recent tweets