If you don't trust your experts, how expert are they?

I had a great chat with an experienced IT software development leader in IT this afternoon.  He was telling me of a business customer that he had once worked with.  His customer had the habit of coming to IT with not only the problem to be solved, but the entire solution already mapped out.  They didn't want IT as a partner.  They didn't want them as a vendor or even a contractor.  They wanted to use IT as a hired lackey.

He began sharing an expression with his business partners to get them to face the consequences of this kind of behavior.

If you come to me with a problem, you'll get a solution.
If you come to me with a solution, you'll get a problem.

I love that.  It's true in so many ways. 

But it speaks volumes about a lack of trust between business and IT.  If our business customers believe that we are experts at what we do, they would want to ask our opinion.  So why do some folks still insist on solving the problem first, without IT in the room?

Perhaps they don't believe we are experts? 

And if they don't believe it, just how expert are we?  Doesn't the core competency of "expertise" include the ability to communicate competence and reassure partners that problems will be solved, value delivered, and integrity maintained? 

So, the next time you find that a business partner comes to you with a solution... thank them.  They have shown you two things: that they have creative ideas, and that they don't trust you.  Listen to their ideas.  Earn their trust.  (I'm not sure you can successfully do one without the other). 

Then, do what is right for the customer and the enterprise.

Comments

• Anonymous
  April 02, 2007
  I've been a developer, analyst, project manager, and "owner" for software development projects.  I now work for a University grappling with their human workflow issues. When IT was presented with the problem of workflow, they came up with a group of systems that can discuss things like authentication, role, and organizational hierarchy through web services.  While that's all well and good--and from a developer's perspective pretty cool--it doesn't come close to solving the problem. In reality, we (the non-IT groups) are moving forward with a project to implement SharePoint Server 2007--and getting no input from IT.  Hopefully, this will allow minor workflow issues to be solved by the business analysts and information workers themselves without involving the self-proclaimed "experts of all things technology". Just because someone has the title "IT uber-geek" doesn't qualify them to solve anything and it doesnt' mean that there aren't co-workers outside of the IT inner circle that have technical skills (my SQL skills put most devs to shame).   Workflow is the specific domain of the business analyst.  While the BA isn't going to code a new BPEL WF designer interface in JAVA, he's also not going to be able to use a "developer's solution" to common problems--which is what we got when we asked. I disagree with the premise of your article because it shows a myopic view of the relationship between project sponsors and IT.  But IT has made that bed in so many cases.  IT frequently makes statements like "I don't care what the business case is, what are the specs?" When professional developers act like that, they deserve to be treated like a "hired lacky".

• Anonymous
  April 02, 2007
  The comment has been removed

• Anonymous
  April 02, 2007
  The comment has been removed