So you inherited a legacy team, now what?

Congratulations! You have inherited a team with lots of classic technologies and practices. You might not even understand half of what they are talking about.

You may be thinking “Am I being punished for something?” You are not being punished!

Having been in the position multiple times I can tell you it’s very challenging but also can be quite fulfilling. In fact, some of my favorite memories have been working with the teams just starting their transformation journey. Sometimes you may feel like it’s too much of a good thing. That’s natural, hang in there and don’t become overwhelmed.

With the departure of one of my managers I recently found myself leading an SAP Systems Engineering (BASIS) team. If you are not familiar with SAP, it’s an Enterprise Resource Planning (ERP) System typically run by the Fortune 5000. Almost 45 years old it is deeply specialized and nuanced. As a n-tier application, it has it all (load balancing, high availability, databases, clients, servers, etc. )… All of a sudden, I’m starting to get nervous becase it suddenly dawns on me that I haven’t logged into SAP in more than 10 years.

Your new team needs your perspective, experience, and most of all your understanding as the team learns to work differently along their journey. I have a few suggestions to make your new role more effective

1. Your new folks are not resources

Your new team wants you to see them as individuals. Individuals with hopes, concerns, ideas, and occasional bouts of imposter syndrome (especially about your DevOps work you may have done elsewhere).

Spend a few minutes one on one in the first few days. Making this a priority will not only help you to understand your team but it will provide a foundation for any meetings or interactions you’ll have. In addition, it will be symbolic to the team.

As tempting as it will be to jump straight into business, I’d recommend that you learn more about your team on a personal level. As many of you know, I’m a big fan of walking one on ones, especially with technical folks as it allows a less formal discussion. There is something about not sitting directly across from one another that facilitates more candor and vulnerability.

If you have topics you don’t want to forget you might jot down a bullet list prior to the meeting. This list should be on a notecard or sticky. You should keep your phone in your pocket during your walking 1:1. Nothing says you aren’t important more than being glued to a screen.

2. Seek First To Understand

After getting to know your team a bit now you can ask lots of open-ended questions. Some of my favorites:

• What’s working well?
• What’s not working well?
• What should we stop, start, and continue?
• Can you tell me about a typical week (including number of hours being worked)?
• Do they have a backup on the team for their critical activities?
• What ideas do you have for our improvement?

You will likely find out that a great number of things need to be addressed but it will be impossible to handle them all at once. It’s vital that you not rush this phase of doing discovery because you don’t want to make ill-informed changes that will make things worse. In addition, if you make a bunch of changes before hearing feedback from the team, do you think they will trust you when you say you want their opinions?

3. Legacy technology is often misunderstood

Your team has spent many years specializing in designing, building, testing, hardening, and operating systems that support critical revenue generation capabilities within your company (because that is what their vendor, community, and management expected). These critical systems probably pay for the new hotness being explored or implemented elsewhere within your organization.

You should endeavor to have empathy for the legacy/classic systems your new team has to support. Just because the technology comes from another era does not mean it is necessarily inferior. As an example, the venerable B-52 was introduced in 1952 and has a planned service life until 2050. A hundred year lifespan is quite impressive, particularly when you consider that the B-1 (1986-2036) and B-2 (1997-2036) will both fall well short that longevity.

As you gain more familiarity with the technologies in your team a great approach is to assume the best intent for the architects of yore. Adopt an attitude of curiosity to discover the reasons why the system was implemented in a given way. This means you may need to be a forensic detective at times.

Just because you have legacy implementations doesn’t mean we can’t apply newer architectural approaches, but as a point of caution don’t change things just for the sake of implementing the new hotness.

4. Trust

Two-way trust is the only way you’ll create success. The team has to trust that you have their best interests in mind while also trying to fulfill both long and short-term enterprise objectives. In the early days, they are watching everything you do to gauge whether you really mean what you say. You should be on the lookout for win-win scenarios that benefit the team as well as the enterprise.

Have patience while building trust. You should expect that you will need to trust the team before the team will trust you. As inspiration, I’d recommend Turn the Ship Around by David Marquet for many reasons, but the ones most applicable to this post are:

1. Captain Marquet was vulnerable and trusted the team before earning the crew’s trust
2. He was relatively unfamiliar with the technology in his organization, so he had to lead in a completely different way. He had to facilitate experts to operate the sub versus being the expert himself

Consistently setting high standards will be one of your best friends in building trust. Are you living by the same standards you are asking your team to meet? Your team needs to know where you stand and that you aren’t playing favorites. You can help your team to know where you are coming from by communicating early and often, even if you feel like you are repeating yourself.

5. Reassurance

While meeting with the SAP Basis team I mentioned that we have more demand than we have capacity to support. I told them that I was interested in bringing in contractors (staff augmentation) to help with the backlog. My heart was in the right place (reduce backlog, reduce hours, mitigate burnout), but I think they quickly became worried I was exploring replacing them with these contractors.

In hindsight, I had not done enough to reassure the team that they had done nothing wrong and that contractors were being pursued to improve the quality of their professional lives.

After a couple of months, one of the engineers who initially was worried about outsourcing told me “We probably need some short-term contract help to work through the backlog”. Kudos to this engineer for changing his perspective! Further, I take this comment as a positive sign that they are starting to trust me.

The idea I’m trying to impress upon them is we don’t need to own every facet of operating the services, especially if we can consume services via higher levels of abstraction. This idea flies in the face of almost everything the members of the team have known over the last couple of decades.

This same team will be moving some critical services to use IaaS in the public cloud over the next few months. They understand the decision at a logical level but periodically need to revisit “the why” when their emotional decision making gets involved.

6. What’s your vision?

Most legacy teams can’t pursue too many new things at one time. You need to establish a simple vision that resonates with your team. PS - your vision can’t be we need to implement __________ stat. A better approach is to focus on those outcomes that are important to your area. Can you figure out how to get better at those outcomes each and every day? Share your vision with your team regularly so they understand where you are coming from.

7. Tough Love

After understanding how your team works, cultivating the beginnings of trust, and determining what to focus on you are now ready to reinforce some changes that will be required as you move forward. Here’s a summary of a discussion I had with the Basis team a few weeks ago.

Let’s expand on a few of these in more detail

Multitasking is a myth :

When I told my son that I believed multitasking to be a myth, he quickly told me how wrong I was and cited the Mythbusters episode testing if men or women are better at multitasking. This episode had numerous tasks to be performed and it definitely appears to be multitasking or at least fast task switching. Another example is the unipiper (a Portland fixture). He certainly also seems to be able to multitask effectively.

I believe that knowledge work is fundamentally different. How can we think about two or more things at the same time? The core conflict appears to be : “I’m super busy already. If I am blocked on a task such as waiting for someone to give me something, I should switch tasks and work on something else.” This approach seems very reasonable and pragmatic but it contributes to the problem. When we multitask we incur switching costs each time we context switch. As a result, everything will take longer to complete than if we stay on one task. Don’t believe me?

a couple of proofs:

• So you think you can multitask - People, Ideas, and Things Journal UNC
• Multitasking undermines our efficiency - Journal of Experimental Psychology

A more fun example:

• The waiting snake - Impact of High Utilization to queues in knowledge work

As this team is a systems engineering team with many stakeholders and interruptions, we are working in 1 week sprints. I believe this puts an appropriate emphasis on prioritizing what is truly important to deliver in the current week while also enabling stakeholders to have higher confidence in what will be delivered. I can justify not taking a new task on day 2 of the sprint because on day 6 we will start a new sprint and we’d be happy to prioritize their need alongside other items.

• work in smaller batches : Related to the idea of multitasking being a myth, we should work in smaller batches so we can consistently focus on delivering value. While working in smaller batches we should have less occasion to multitask and we are less likely to be blocked by other people. The other benefits of working in smaller batches?
  • We improve flow
  • We receive feedback about the quality of our work so we can improve in real time.
  • If we have to kill a task we haven’t incurred much investment
  • We get a great feeling of achievement
  • Our stakeholders don’t have to wait as long for our delivery

Here’s a video that explains why working in smaller batches is superior to large batches.

Confronting habits :

Multitasking and working in larger batches are a deadly combination and are likely the results of many years of habits, both at the individual and the team level. So if we want to change habits, what do we do? The Power of Habit by Charles Duhigg offers some great suggestions related to the habit loop.

It turns out if you want to change habits your only options are to change either the cue that starts the habit response or the reward that results from the habit execution.

So how can we change habits? We need to bring awareness to the habits and perhaps gamify them in some fun way. You might also all try to change a habit such as shoe tying as a team to have a fun challenge. PS - Theo Schlossnagle thinks you are tying your shoes incorrectly.

Back to the Power of habit, I’d recommend you take a look at the 15 minute TED talk by the author on changing habits and willpower.

Final Advice

Have fun with your legacy team. You are likely going to grow quite a bit as a leader in the process.

1. Exercise empathy for your new team and their technology.

2. Don’t abandon your Lean / Agile / DevOps ideas but focus on a couple of small outcomes to build upon

3. Actively discuss the team’s habits and determine if you can hack some of the cues or rewards in order to drive different behavior

4. Be patient, you are all learning and seek a series of incremental wins as you move forward.