Why you need to put a personal face on IT

The business/IT relationship builds -- or deteriorates -- one interaction at a time

Relationships are complicated, and the one between business and IT is no exception. As is the case with so many relationships, the place to start is agreement on roles and power. (Not to worry, I'm not about to delve into the subject of marriage and what to do about it.)

As discussed last week, IT's proper relationship with the rest of the business is peer and collaborator. If you're tired of hearing about it, I'll make you a deal. If you drop the whole idea of "internal customers" and everything that goes with that philosophy -- that IT should be an internal supplier responsible for "making the business happy" and "satisfying their requirements" -- I'll stop harping on the train wreck that awaits you.

[ Get Bob Lewis's continuing IT management wisdom in his Advice Line blog and newsletter. | Find out why running IT as a business is a train wreck waiting to happen. ]

IT's relationship with the business depends on its interactions with the business. Application development, operations, and whatever other subdepartments you have in your organization interact with the company's various functional and operational divisions and departments. It plays out between individuals who work in IT and the rest of the business, one interaction at a time.

These interactions are built on the individual roles employees in IT play: The CIO interacts with the company's other top executives, while the heads of application development, operations, and so on do the same with the company's middle and frontline managers.

Which brings us to levels -- and the importance of personal interaction.

The dynamics of the business/IT relationship
Consider this: Help desk analysts interact with employees across your entire org chart. As agile increasingly dominates application development, every developer will also be interacting with employees throughout the business ranks. IT operations is a bit more insulated, but not by much -- a lot of operations work calls for direct interaction as well.

Roll this all up, and you can see that the quality of the business/IT relationship as a whole depends on getting these connections right, from the top level on down. But here's the tricky bit: While the relationship between business and IT builds one interaction at a time, from person to person and team to team, every one of these interactions depends on the interplay of at least three separate dynamics.

The first dynamic relates to the business/IT relationship model employed by your organization, and it requires a shared understanding among participants. If we in IT consider ourselves to be peers and collaborators while our counterparts elsewhere in the business consider themselves to be our customers, the resulting conversation won't go anywhere, and it won't go there with a lot of loud noise.

The second dynamic is role to role. From a role perspective, when the CIO interacts with the rest of the company's executive team, it's as the company's technology leader and as an adviser on the subject of IT; the heads of application development and IT operations are in equivalent roles when interacting with their business counterparts. When business analysts stop asking business managers what they want the software to do and start asking how they'd like their part of the company to operate differently and better, that's a change in role as well.

Role-based interaction has nothing to do with personalities. It's about what each individual does in the company and what they need to do together to move the company forward. In principle, with sufficiently ingenious programming, robots could have the same interactions, with equivalent results -- so long as the robots were programmed to the same set of APIs. Otherwise, they'd all bark out error messages, and work would come to much more of a standstill than happens with human employees, who can talk with each other and figure it all out.

1 2 Page
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies