Sunday, January 22, 2012

Things technologists can do to get the attention of business stakeholders

The issues between IT and the rest of the business in a corporate environment is a popular topic in IT magazines and web sites, yet the problem still exists.  Part of the issue is that business people need to know more about IT. (To start, you can read a blog about needed knowledge for business stakeholders in a software development process here.)  Part of the issue, though, is that information technology professionals need to do a better job of delivering what they promise and communicating technology issues is business terms.  Here are some specific things that, if done by IT, should improve relationships between technologists and general business people.

Under-promise and over-deliver
I can’t tell you how many times I’ve encountered situations where a technology worker or group was completely unable to deliver on promises.  There are many reasons for this, ranging from optimistic estimates to unseen roadblocks to deliberately lowering estimates to impress the “bean counter”.  High estimates can certainly make financial stakeholders nervous, but you can bet that blown estimates make them even more so.  Be sure that you can deliver what you promise.  Plan for difficulties you might not see yet, and resist the temptation to lower your estimates to look better to others.

Avoid the use of technology jargon
Technologists, when surrounded by like-skilled individuals, tend to lapse into tech-speak.  This is fine when the recipient of your ideas understands the jargon.  But only bad things can happen if you lapse into tech-speak when talking to a non-technical person.  Your listener may get annoyed that he/she can’t understand you, or may get angry because he/she feels like you’re intentionally trying to make them feel stupid, or may just stop listening because he/she can’t understand what you are saying.  You get the idea.  When in doubt, when you can’t simplify a concept, be sure your listener understands before moving on.  Your listener may learn something about technology and you may learn something about how to communicate technology concepts effectively to non-technical listeners.

Avoid going into too much detail
One pitfall I fall into often is trying to explain too much of the implementation for a particular scenario.  Sometimes I get excited about a particular implementation method, sometimes I want my listener to find holes in my thought process, sometimes I’m just thinking out loud, etc.  In most cases, though, my listener doesn’t care.  I’m just wasting everyone’s time trying to get them to care.

Know your value
Most developers I know simultaneously overestimate their value to a business as a developer and underestimate their value to a business as a knowledgeable stakeholder.  Their overestimation comes from the fact that developers feel important because they can do things that the typical business person can’t, and so it is obvious where the developer’s value to the business is.  Everyone has value to the business, though, otherwise they would get fired (in any reasonable company).  On the other hand, by creating information systems, developers often see how information flows from one part of the business to another, thus giving them a great background on how the business works.

Treat misunderstandings as your fault, not theirs
Technology professionals often get frustrated with non-technological listeners for a lot of reasons, but these are usually the fault of the technology person, not the listener.   Your listener will pick up on this frustration and think that you are frustrated with them.  Understandings are most often caused by overuse of jargon or going into too many details.  Once you understand this, if you do lapse into jargon, you will be much more apologetic and put your listener at greater ease.

Remember, everyone's on the same team
Nothing is more harmful to any relationship, whether it is personal or business, if you lapse into “us and them” thinking.  Your job is to create software, enable communication through networks, etc.  The business person will likely want to push off problems solely onto you as “computer problems”, but you need to resist the temptation of thinking of business requirements as “business problems”.  Technology can no longer be thought of as a separate department, but instead is an enabler of business as a whole.  All problems are team problems which require team solutions.  If you keep this in mind, professionalism from all sides usually follows.

No comments:

Post a Comment