Working Well With Your IT Team

Development vs. Support Whether you're a member or an overseer, the various aspects of the IT team can often be seen to be in conflict.  It's ent...
Tuesday, 16 May 2017
Working Well With Your IT Team

Development vs. Support

Whether you're a member or an overseer, the various aspects of the IT team can often be seen to be in conflict.  It's entirely understandable—and it's also unnecessary.

This is not to diminish the importance of the folks down in the server room who keep the entire infrastructure running—their world is too esoteric for most executives to understand, so they manage to escape a lot of the conflict.  Their problems are generally tied up with budget, and prying loose the funds necessary to upgrade equipment. 

The Development team, on the other hand, is generally filled with creative geniuses that are full of unending surprises.  They can make computers dance the same way that animal-trainers can teach their pets to jump through flaming hoops.  

They can also tend towards vanity because they are aware of the fact that they are pretty clever.  However, no matter how innovative their solution is, if it's not what the customer wants, then they have to reign themselves in.

Support, the other half of this duo, is tightly wrapped up in making sure that customers get what they want.  They are very enthusiastic about this; they always want to help people.  As each sprint in the Development phase is concluded it becomes the job of Support to interact with the customer, interpret their needs, and then communicate that to the Development team.  

It is Support's responsibility to enumerate any shortcomings, interoperability problems, dysfunctions, and to pass on requests for additional functionality.  It is not their job to tell Development how to accomplish that, and they shouldn't try.  That's like leaning over the shoulder of your plumber or auto mechanic during a repair and saying "Wouldn't that work better if you …" because you may have a notion about this subject, but the fact is you're really not an expert.

For both Support and Development it comes down to respect for each other's domain of expertise.  Development shouldn't try to tell the customer what they want; Support should mediate solutions, not suggest them.

Your business is a community—unfortunately it's often a gated community.  Yes, yes, your Development team is full of geniuses that need to be protected from the outside world, from poachers who would try to get them to leave your company in favor of another.

But fencing them off, isolating them from other people in your own business, only serves to create barriers.  These two particular departments should not be separated.  Ideally they would be located right beside each other, and they should share a lunchroom or cafeteria space directly across the hall from both.

If you set them up as the Confederate Army and the Union Army, you have built-in conflict.  They are two aspects of the same thing, working at cross purposes.  How well did that work out last time it happened?

The Rules

Once again, whether you're a member or an overseer of the IT team, here are the factors that you have to get right in order to be a success:

Communications (everyone)

If you're in charge, always be honest with your subordinates.  Be clear with directions, clearly setting out expectations and timetables.  

If you're in Support, make sure Development has all the information it needs.  Describe pain points, but quantify them so Development can figure where to apply their effort.  10–8 is a must have—product fails without it; 7–4 is essential functionality; 1–3 represents nice to have.

If you're in Development tell Support honestly when something is impossible, or too far out-of-scope.  Stay on track and don't invest time building unrequested functionality.

Reliability (everyone)

Irrespective of your position on the team, if you promise something, whether it’s resources or a deliverable, make sure it's ready when it's expected.  Keeping your promises builds trust and allows people to extend themselves and feel confident that you will keep your word.

Open mindedness (team members)

Sharing a lunchroom is a great way for Development and Support people to get to know each other.  Conversations that start out: "Hey, Susan, I'm obviously not an expert on this subject, but I was wondering how difficult would it be to program [idea X]?  One of the clients was asking if they could accomplish [goal Y].  What can I tell them?"

These sorts of interactions build trust.  

Sharing credit (everyone)

Glory-hogs annoy everybody universally.  The department manager looks great when the department looks great.  There is no reason that s/he shouldn't point out the contributors to the success.  That should continue all the way down the line.  Everybody who contributed should be happily acknowledged—leaving people out sets them up to move to another company where they will be appreciated.

Let leadership evolve (managers & supervisors)

When assembling a team of half-a-dozen people you should have two "creatives", two "practicals" and two "pragmatists".  Notice there is no "leader" per se.  Just give them the assignment, lock them in a room, and let them work it out themselves. 

Utilize talents appropriately (managers & supervisors)

Don't ever assemble a team of six "creatives"; you'll have nothing but conflict.  Six "practicals" will probably produce functional but unexciting work.  Six pragmatists will get it done but it will take much longer. 

Don't micromanage (managers & supervisors)

Unless there are serious problems with your team, hands off.  Let them do their job.  If you can bring yourself to do it, sit in on a weekly progress meeting but don't say anything.

Delegate upon failure (managers & supervisors)

If your team is going off the rails, step in, delegate, and then step out again.  If they have to rely on themselves they will be better next time.

  • Meet regularly (team members)
  • Monday: Planning meeting
  • Wednesday:  Progress Meeting
  • Friday:  Review & goal setting for next week

Have a defined methodology for measuring progress  (everyone)

Milestones are important.  If there are no signposts, how do you know if you're still on track?  If there's no Finish Line how do you know when you're done?  Amorphous "progress" is no sort of progress at all.

Offer to help other members (team members)

If members are behind for any reason, assign them help to get them back on track.  Any project manager will tell you that everybody's task must be completed on time because other tasks depend on them.  

If you're the one who is falling behind, even if other people don't recognize it, ask for help.  Floundering about, desperately trying to catch up makes your life more difficult and threatens the project.  Don't be afraid to ask for assistance.

The Takeaway

You do not have to be BFFs but you do need to respect your fellow workers, avoid stepping on any toes, be appreciative of their efforts, and support them when they need it.  

It is every team member's responsibility to reduce any adversarial relationship which has been deliberately or accidentally created.  Remember: we work best when we work together.

Read 522 times