ASP.NET Security Consultant

I'm an author, speaker, and generally a the-way-we've-always-done-it-sucks security guy who specializes in web technologies and ASP.NET.

I'm a bit of a health nut too, having lost 50 pounds in 2019 and 2020. Check out my blog for weight loss tips!

Creating trust between technology and business

Published on: 2012-01-22

The issues between IT and the rest of the business in a corporate environment is a popular topic in IT magazines and web sites. In all honesty, I think this is more due to the behavior and approaches of people in technology than any other cause. Hope is not lost, though. Here are some things that I do to build trust between me and my clients.

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.

I always do my best to ensure that I can deliver what I promise. I plan for difficulties I might not see yet, and resist the temptation to lower my estimates to look better to others. In the rare cases when I can't deliver on what I promise, I'm always up front and tell the appropriate people about the possibility sooner rather than later.

Avoid the use of technology jargon

Technologists, when surrounded by like-skilled individuals, tend to lapse into tech-speak. That's fine when the person you're talking to understands the jargon. But when a non-technical person is involved, it's almost impossible for him/her to continue listening. No one likes to be in a conversation they can't understand. 

Aside from trying to use the terms my audience uses, I'll stop frequently to ask if anyone has any questions. If I do need to use a technical term, I'll ask the group if they understand what I mean, then explain it then and there if not.

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.

Treat misunderstandings as your fault, not theirs

It's easy to get frustrated with people you're talking to have a different vocabulary than you do. But most of the time, it's you who is causing the problem (see the above points), not them. And frustration can leak through, further eroding trust and making the conversation more difficult. What helps me is to realize that misunderstandings are probably my fault, and I look upon them as an opportunity for me to learn how to be a better communicator.

Remember, everyone is on the same team

Nothing is more harmful to any relationship, whether it is personal or business, if one lapses into "us and them" thinking. Our job is to create software, enable communication through networks, etc. The business person may 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. When I keep this in mind, professionalism from all sides nearly always follows.

This article was originally posted here and may have been edited for clarity.