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