Relationship management: The unsung art of optimizing IT teams

Success for an IT leader requires mastering a wide range of skills. One must have technical acumen and business savvy, be a great communicator and problem-solver, and know how to secure funding and capitalize on it.

But getting the most out of IT staff and unleashing synergies among IT teams is among the more underappreciated skills an IT leader must have to optimize their organization’s efforts. And for that you must develop an uncanny knack for relationship management and an understanding of how differing personalities can enforce and work with one another to great effect.

After all, IT brings together a diverse range of personalities, from statisticians, mathematicians, and developers who are rooted in the rigors of computer science, to liberal arts majors who might just as soon be writing a novel if it could pay the bills.

So, how do you as an IT leader unify these wide-ranging personalities into a cohesive project team?

The short answer is that you don’t try to change anyone. Instead, you seize on common goals most team members have: To see success, feel good about the work they do, and contribute in ways that play to their strengths — while avoiding what they find off-putting or unproductive.

Relationship management in action

Mastering this, of course, isn’t easy. For IT team leaders and CIOs, it can require as much psychology as it does skills matching when you build a project team. And for all the talk of skills balance in team creation, chemistry among the personalities involved — their relationships and ways of bringing their best selves to the tasks at hand — are more often than not the key to unlocking synergies otherwise hidden within your teams.

Here is an example: Let’s say you are developing a retail sales system that will be used in Europe and the US. The European countries charge a value-added tax (VAT) to goods, while the US uses a sales tax that varies by state. In Europe, VAT taxes also vary by country, so you have business analysts working with end users on screen formats and process flows for sales order entry, and so on, but you also have an IT infrastructure programmer on board to develop a callable, internal tax calculator module that can apply the correct VAT or sales tax rate to a given transaction based on the applicable country or US state involved.

In our example, the infrastructure programmer normally works — and prefers to work — on her own. Her domain is pondering and developing highly complex technical work, and if she doesn’t talk to anyone in a day, it’s preferable.

You understand this, so to limit this individual’s time on the “people” side of IT, you assign QA to the quality assurance team, as well as to the business analyst and end user involved in the project. If for some reason there is a problem with the tax calculator module, it is the IT-savvy business analyst, who can speak the infrastructure programmer’s language, who engages with her on any needed changes.

This example sounds straightforward, but it emphasizes something subtle about relationship management that goes beyond roles-based working arrangements. Contrary to development methodologies like agile, here you’re not trying to engage the entire project team on every phase of the project. What you are doing is taking account of everyone’s preferred mode of performance so they can do their best work.

Putting personality to work

I’ve talked to other CIOs about scenarios like this, asking them whether they take staff personalities into account when establishing work processes. Many counterargue, saying, “We don’t think about personalities. But we end up running our projects that way anyway, because we don’t want our most expensive infrastructure programmers wasting their time in user meetings.”

Touché. But there is also an ingredient in project team staffing that should take into account the natural synergies between people. And this requires learning about the individual personalities on your team.

Among the personality types I have encountered when leading IT organizations, these are the most prevalent:

• The business analyst and consummate communicator and empathizer who is a natural for working with end users on projects
• The programmer who best enjoys working on their own on technical issues, but who will address technical glitches with an IT-savvy business analyst who serves as a liaison to end users
• The “save the day” problem solver who works best under high pressure and is a natural for resolving mission-critical production and system installation problems
• The “give back” mentor who might be nearing the end of an illustrious IT career and is interested in training new people on IT responsibilities — and who might be the perfect fit for working alongside a junior project team member
• The entrepreneur who could change an entire project approach or timeline with a stroke of genius because they see a better way to design a key element in a system
• The administrative IT pro who excels in contract, compliance, or project administration — important jobs that most IT staffers don’t prefer to do, but that must be done

I have also seen destructive personality types — like the technical guru who becomes a prima donna that everyone caters to, and decides which projects they will support, and which ones they won’t.

I first encountered this personality type during my first IT project management job at a software company. My project was competing with other projects in the company for this database expert’s attention, and she kept stalling my project because she preferred to work on the projects of more senior managers. Day by day, I watched my project timelines slip because we couldn’t get data schemas updated. I finally solved the dilemma by using a much more junior person on my project team to do the work. Mistakes were made and the work got done slower, but it got done.

What I learned was that as IT leaders, we don’t always have the luxury of placing the right people in the roles that best suit them. But the more we can be as sensitive to personalities as we are to skillsets, the more cohesive our projects will be, and the happier team members will be in their work.

How are you accounting for relationship management in your IT team makeup and collaboration practices?