How to improve communication and cooperation around technology choice

Question

I've been a team lead at my current workplace (an IT department) for a number of years.

There is a recurring problem here:

• Team A decides to start using technology X (e.g. ASP.NET), usually based on no formal selection criteria
• Team B already uses technology Y (e.g. PHP) which does the roughly the same thing as technology Y. They probably also didn't have any formal selection criteria.
• Team A and B would be happy to agree on one technology, X, Y or Z in the given space, if they actually talked to each other about what they were doing before it was too late.
• But instead we end up wasting money, time etc. using both technologies. Sometimes projects get killed after weeks of work because it turns out someone else was working on the same problem.
• To make matters worse Team A may only have one person who is skilled with technology X, and when they leave it may get handed over to Team B, which now has to support both X and Y

There is generally a cooperative culture in the workplace. If you ask someone from another team for help or information they'll usually be happy to provide it. Secretiveness isn't the problem - if you happen to be in a meeting with someone from the relevant team, and happen to get on to a relevant topic you'll find out what they're doing.

I have technology architecture in my job description. I keep raising the technology duplication issue in cross team forums, and have tried to lead by communicating technology directions from my team and seeking feedback. But without much evident sign of progress.

The workplace is fairly non-hierarchical, and any solution is going to have to rely on getting peers on board, rather than getting management to make orders.

Can anyone suggest actions I could take to improve the situation?

Answer 1

Let's break this down into its component parts:

The Problem

Within the organisation, you have multiple teams working with different technologies, sometimes overlapping tasks causing duplication and a lack of maintainability.

The Solution

You have partially identified this yourself:

I have technology architecture in my job description.

So you are the person who needs to drive this. You also state:

I keep raising the technology duplication issue in cross team forums, and have tried to lead by communicating technology directions from my team and seeking feedback.

The question is, who are you raising it with? I assume each team has a team lead or manager who is responsible for setting the tasks and selecting technologies to achieve their goals.

Ok, How?

Well, there's two parts to this. Firstly you need to get a baseline. And this is going to require your getting engagement from the people who sets the direction of each team. And secondly, you need to make sure that you keep this front of mind in future.

The workplace is fairly non-hierarchical, and any solution is going to have to rely on getting peers on board, rather than getting management to make orders.

Unless you have total anarchy, clearly each team has tasks being set and managed. And your role as architect is to get the manager for each of these teams to look at the bigger picture as well as their day to day operations.

What should I do?

Well, first thing is to get each of these team leads/managers into a meeting. You need to clearly articulate the problem in this setting. If you aren't getting buy-in, you aren't being clear enough about the problem. You already covered in your question what the issues are. Make sure they understand this.

So, once you have the attention of these people, get them to put forward their 6 - 12 month planned tasks and intended technologies. If they don't have intended technologies, all the better for decoupling the tasks from the separate tech.

Then, you as a team of managers, need to agree on how you plan to go forward. You say there is no hierachy within the organisation but there must be some overarching plan or this problem will not go away. You may also find that a combination of technologies depending on legacy applications, skill set and risk may be appropriate.

Once you have done this, this needs to be communicated through to their teams. Give the same reasons to the teams. Let the team leads/managers do this. Remember, you won't get anywhere if you don't have their buy-in.

How do we prevent getting here again?

Regularly scheduled meetings of the team leads with you as architect to describe what tasks you have coming up over the next period. I suggest two weeks, but whatever works for you. That way it should be clear if there is any duplication of tasks and you can look at how to reuse code rather than duplicate.

This all sounds too simplistic!

Well, no. If you want to drive change, you have to drive change! You need buy-in from the people that matter, which includes management to give you authority and the teams to make it happen. Even in flat structured organisations, unless you are all working together then you have the little silos that you see now. It is your job as architect to drive this, explain the reasoning and if they are competent professionals they will see the rationale behind what you are suggesting.

Answer 2

The workplace is fairly non-hierarchical, and any solution is going to have to rely on getting peers on board, rather than getting management to make orders.

Given that situation, what you describe is the normal outcome. There's a reason most places use a more rigid structure - proper allocation of resources.

Now, it's highly unlikely you can change this aspect of the company as it would have to be driven by someone with the power to enforce it. So, what you need to do is brush off your political skills and start meeting with the people in each team that make the tech decisions.

I wouldn't try to do this as an on site meeting at first. Something will always come up where Bob or Susan just can't make it week after week.

Instead, try to schedule a weekly lunch. Keep it informal, at least at first, and encourage them to talk about their existing and upcoming projects. If your really savvy, maybe you can convince people further up the food chain to actually pay for the lunch. A "free" lunch has a way of making sure people actually show up.