Building Good Business Relationships Isn’t About Going Out for Beers

I once knew a warm and engaging CIO named Frank. He was the life of any company event or party he ever attended. He was a talented guitar player and a wonderful singer, and he never failed to impress his colleagues. Everyone always said Frank was such a great guy. He was so much fun to have around. And like most smart CIOs, Frank used his personality and considerable social skills to build relationships with his business peers just like all the professional literature tells you to do.

In meetings with his direct reports, he’d emphasize the need to “get close” with the businesspeople, to “spend time with them” in order to build relationships. He’d tell his own stories of social interaction and wait expectantly to hear similar tales from his direct reports, but he never did. His IT team was just a bunch of normal IT guys. They didn’t have those sorts of relationships.

Over time, it turned out that Frank’s relationships with the business were far from ideal. Even though people liked him, he never developed any meaningful business relationships with his colleagues. And sure enough, over time, his IT group became less and less respected and his leadership came into question.

Rather than waiting to get canned, Frank saw the writing on the wall and opted to leave for greener pastures on his own (I told you he was a smart guy). But even as he was leaving, he was still quite surprised at his situation. He couldn’t get over the fact that all his relationship building didn’t save his job or earn him the respect he had hoped for.

What happened?

This little story sets up a couple of important questions about the idea of “building relationships with the business.” We’re always hearing about how important it is for IT leaders to “build relationships” with their business peers. Sure, that’s a great idea, and it makes sense. But the question is how do you do it? Frank seemed to have great relationships. So what went wrong?

Was Frank led astray?

To help answer what went wrong with Frank, it’s useful to look at the type of advice he has been getting. Sadly, when I look around at what’s being written and talked about regarding the topic of IT leaders building relationships with the business, I find that most of the advice is woefully lacking. It’s focused largely on form and little on substance. Generally speaking the advice forms a sort of checklist of key to-dos, something like:

• Develop a list of “relationship targets”
• Do regular “meet-and-greet” sessions
• Formalize “relationship management” activities
• Engage in “stakeholder analysis”
• Volunteer for “extracurricular activities” with your business peers

I also hear a fair amount of the “personal relationship management” stuff that focuses on activities like learning to read people, being friendly, leveraging your personality, and so on.

So what’s wrong with all this advice (beyond being way too generic)? And why is it that so many IT leaders are still struggling to build relationships with their business colleagues? Why is Frank out of a job despite the fact that he seemed to be doing everything right?

Frank’s crucial mistake

It all boils down to one key point: Frank never learned (or perhaps was never taught) that there’s a huge difference between a social relationship with a business colleague and a business relationship with a business colleague. Frank didn’t understand that as friendly as he may have been with his business peers, they never wanted to be his friend. They were happy to be “friendly” with him and to be entertained by him, but the social relationship with Frank never translated into business respect for him.

So what’s the answer?

A relationship with business peers has to be first and foremost a business relationship. And to enjoy a business relationship you need to have common ground, in other words a basis for the relationship. The fact that you both work at the same company isn’t enough. The fact that you go to the same meetings isn’t enough. The fact that you support their systems isn’t enough.

To really build business relationships between you as the IT leader and a business colleague you need a “bonding agent,” something that acts as the essential glue to the relationship. In fact, I’d go one step further. What you really need is a value-adding “bonding agent” to effectively connect with your business colleagues. Because, as the IT guy, you’re coming in with an inherent disadvantage. You’re the geek looking to hang out with the cool kids. And if you want to, you’d better bring some nifty toy that does cool stuff or else you ain’t gonna be asked to sit with them at lunch. And the most effective bonding agent I know of in this context is value-adding content from the world of IT that’s directly germane to the world of your peers.

You can have all the “relationship maps” in the world and you can make sure to have lunch with your colleagues once a month, but if you don’t show up with some of that magical bonding agent, the relationship will never stick.

Real-world case

Here’s an example: I spend a lot of time working with the pharmaceutical and healthcare industries and helping CIOs in those industries develop IT visions and strategies.

As part of our landscape analysis, we collect, research, and analyze a huge amount of information regarding the billions of dollars being spent on healthcare-related technologies across the industry.

When the FDA quietly announced early plans for a patient safety database, dubbed Sentinel, it did so in very technical terms that involved collaboration among a number of parties. On the surface, the potential business implications of the database weren’t clear.

To get behind what was going on required working through all the IT terminology, which essentially pointed to the fact that the FDA was about to go into business with a bunch of insurance companies to provide access to patient data. And it was done specifically with a view toward checking up on the safety and efficacy of drugs in a way that could severely skew the balance of knowledge between pharma and the community of payers and patients. This, of course, could be very disadvantageous to the industry.

So here we have a classic situation where a strategic IT development has the potential to massively impact an industry. But it is still early days and few people know it and understand it.

The next step for the pharma IT leader is to clearly package the essential insight/knowledge in one or two crisp slides to share with his key colleagues at the right times (informal settings work best). This opens a dialogue on an important issue. More importantly, it creates the fabric of a business relationship that bonds you, the IT leader, with your colleagues.

But it doesn’t end there. As a result of this kind of bonding, IT isn’t viewed only as the data pipes and apps. You expose the strategic business insight IT can bring to the table. And as a result, your colleagues will view you as an insightful peer — one who’s on top of the issues that affect the business that come from the world of IT.

The wrap-up

To be sure, I’m not suggesting that the only way to have a relationship with the business is by constantly coming up with new and interesting IT trends that may affect them (although that’s hardly a bad thing). There are many more things an IT leader needs to do in the course of day-to-day business. On the other hand, I am saying that a personal relationship not grounded in real content — business-related, value-added — won’t cut it.

If you’re still with me, you are probably wondering … So how do I develop that sort of content? Where do I get this kind of value-adding information? That’s an important question, and one that I dealt with a bit in a previous post (“The Vision Presentation”). But I digress.