Carefully Forming Teams to Begin Technology Modernization

--

It’s a common sight to see technology organization re-inventing aspects of their operating model. Often, it’s a combination of migrating to modern cloud technologies, adopting new organizational models, and striving for better ways of working.

I find that modernization is often triggered by market pressures, such as not being able to deliver at the pace of competitors, or new leadership with big ambitions and a different mindset.

In any case, there are many challenging aspects to modernization. Deciding where to start is definitely one of them. And zooming in further, forming the team(s) that will deliver the first slice of modernization is particularly challenging, yet vital.

Choosing the wrong people can derail an initiative before it gets going. An openness to new ideas and some patience is essential. Equally, it’s important to have the right mix of experience, to ensure the balance of learning and delivery matches expectations.

Attitude Mismatch

I never enjoy having people removed from a team due to their behaviour, but unfortunately I’ve had to do this a few times. What I’ve learned from each of these experiences is that clearly these people didn’t have the right attitude to be in a team leading a modernization initiative and should not have been in the team in the first place.

On one of those projects, I had to deal with a very confrontational senior engineer. I was getting reports on a daily basis that he was shouting and arguing with the tech lead and other team members. He had been with the company for a number of years working in a certain way, and seemed very unhappy with mob programming that was being introduced.

The consequences of this were severe. A significant amount of time was spent dealing with this conflict. And the atmosphere in the team was extremely tense. Everyone seemed unhappy and afraid to speak in meetings. But not only this, the negative performance of this team was spreading around the organization and the whole modernization initiative was being questioned.

The company wanted to build a more collaborative approach to engineering. Mob programming and pair programming were at the heart of that, and these new teams were here to try out these ideas and see if they could work in their organization. Clearly, this person was not a good fit for this team. Why were they even put there in the first place?

I came to learn that this person wasn’t performing well in their previous team, either. The manager of the previous team said to me: “His attitude brought the whole team down. He worked well when left alone so we just left him. He was put on the modernization team because we thought he would be happier there.”

This is not the kind of risk I would advocate for when kicking off a technology modernization. A healthy dose of skepticism is needed on any team. But in this case, the engineer had completely the opposite approach to what the team needed (individualistic vs collaborative) and had a history of bringing down a whole team with his attitude.

People aren’t just interchangeable resources. Think very carefully about each team member who will be part of a modern initiative that is fundamental to your future technology capabilities.

Experience Mismatch

Learning is a constant in modernization. People in the first modernization teams must be especially open to learning. However, it’s also important to be aware that the demands of learning and coaching can be detrimental to the team and the modernization initiative.

I encountered this problem on a modernization initiative where the initial team was a bit too big. There were a lot of people who wanted to learn but not enough people on the team who could coach them. Some members of the team had very basic programming skills so needed a very high level of support from just the two seniors on the team.

The team made very little progress establishing the new technology platform and building product features, because the two experienced engineers in the team were at fully capacity teaching the 6 other members of the team.

What’s interesting about this example is that there was another team with just two senior engineers and two junior engineers. The smaller team was making rapid progress in comparison and the two juniors were learning at a greater rate because they had the support they needed. It was actually amazing to have this side-by-side comparison of how to do things and how not to do things.

Building teams is not a numbers game. The more people on a team who lack the experience to contribute and need coaching, the more senior expertise needed in the team to support them. On a modernization initiative, this is especially important to keep in mind where an extremely high level of learning is expected.

A Bit of Planning Can Save a Lot of Pain

When it comes to forming teams for key initiatives like modernization, it is vital to carefully think about team composition. The impacts of poor team choice affect every member on the team, and can even spread to the wider organization and undermine the entire modernization initiative.

There are two obvious things to ask about each person you plan to put on the first team(s):

  1. Has this person shown signs that their attitude will be a mismatch?
  2. Will there be enough expertise on the team to give this person the support they need to get upto speed and contribute (within a reasonable timeframe)?

There are many other factors that contribute to putting great teams together. Good luck on your journey.

--

--

Nick Tune
Strategy, Architecture, Continuous Delivery, and DDD

Principal Consultant @ Empathy Software and author of Architecture Modernization (Manning)