One of my friends just took over a new team and found… far more of a situation than she was expecting. She faced a choice: commit to the turnaround, or switch to something that seems like a better bet.

Of course, I advocated for the turnaround. Struggling teams are places of opportunity, both for leaders and other team members, to demonstrate dramatic improvement and impact.

But we shouldn’t gloss over the very real risk that the team will not improve and ultimately be disbanded, presenting a career risk for everyone involved. (Nor should we gloss over the fact that bias and inequity means certain portions of society are much more able to take career risks than others.)

Turnarounds mean the hard work of change management, which is a daunting task. I previously wrote about the first questions to ask when your team is struggling, but what do you need to do even before that to answer the question: Should I take this on?

Step 1: List your biggest problems

Failing teams have a list of common symptoms, with failure to deliver usually being the first big external diagnosis. But delivery is a trailing indicator. Looking more closely you’ll often see a litany of things that cause the failure to deliver. Attrition. Poor or missing roadmap. Lack of ownership. Lack of necessary people or resources. Over time, you will want to address all these things, but step one is to identify the biggest bottlenecks that are currently holding the team back.

Example 1: The team in question is tasked with delivering user-facing features and is made up of 10 back-end engineers, but only one front-end engineer and no designer.

This team either needs to refocus as an infrastructure team (not a product team) with clear priorities and internal clients, or needs one or two full-time designers and at least three more front-end engineers to deliver on the stated priorities. Will you get buy-in from the company’s senior leadership for either of these strategies?

Example 2: This team has four ongoing projects. The status of each is unclear although it is agreed that all of them are running longer than expected. The first thing to do is to define what a shippable state is for each project and assess where the team is in relation to that.

Going forward, you will need to institute better upfront planning, clear deliverables, and metrics for all projects. Are these achievable goals?

Step 2: Decide how to debug the cycles

All teams fail, at least on occasion. They miss dates, lose people, get caught by surprise. All teams fail because they are made up of humans, and failure is the human condition. The distinction of high-performing teams is not that they never fail; it’s that they fail less, and fail differently over time. Failing teams, meanwhile, snowball into a state where failures in one place create failures in other places. This cascading effect compounds the problems, making them harder and harder to fix.

Example 1: The team is understaffed because of attrition. This is largely related to poor promotion rates, which are a function of poor delivery (and a promotion process that emphasizes shipping new features over anything else). Meanwhile, the reputation of the team is low, and this makes it hard to attract people onto it.

Can you legitimately give people a reason to stay? Can you lay out a roadmap that demonstrates impactful, promotable work, and ties the work of individuals to it? Can you summon support from senior leadership in the next promotion cycle and in recruiting?

Example 2: The team is not delivering on key projects, nor are bugs being fixed. This is leading to a perception amongst leadership that the team can’t deliver at all, resulting in a smaller and smaller mandate. The team, meanwhile, resents being distracted from project work by all the bugs and argues this is slowing them down.

You need to clearly delineate maintenance work and start delivering incremental improvements that help break the cycle. You will have to work to improve trust and transparency outside the team while filtering the criticism to make it understandable, fair, and actionable to the team. Can you change the narrative from “this team isn’t delivering” to: “This key project is delayed by six months for reasons that we really should have understood up front; meanwhile our site reviews are increasingly critical and generating a high volume of requests for support because we went “all hands on deck” for the key project and haven’t addressed consumer feedback on anything else at all”?

Step 3: Define the constraints and understand the latitude you have

Getting through a turnaround requires support from your direct boss and peers. You need to understand what they expect, what they will support you with, and what latitude you have. Can you focus first on staffing issues and let delivery improvements slide for a while? Or do you need to focus on delivery and work with what you have? Does leadership have a very different sense of the problems the team is having? And are you able to make the higher-level view gel with your more detailed one?

It’s important at this point to ask for what you need to be successful, and it’s better if you are in a strong negotiating position to do so. For instance, when my manager gave me six months to turn around a team, one of my requirements was that, if necessary, I would be able to send struggling individuals to other teams. These kinds of non-negotiables are part of being upfront about the extent of the work you can and can’t commit to in the given timeframe.

Now what?

Once you are agreed on the problems, you get to make a plan. There is always more to do than we have time for, but with a struggling team and many things to fix this is especially true. The key thing is to identify the highest-leverage activities to address your biggest problems and focus your energy on them. As part of this process, you also may identify useful things to do later—but not yet.

Perhaps your list looks something like this:

1. We will immediately replace the manager of the operations team with someone who is more focused on delivery and has better interpersonal skills. (Here you might list some internal candidates who are potentially a good fit.)
2. We will clarify the roadmap for the next three months by the end of next week. We will need a longer-term view, too, but that can wait a couple of weeks.
3. We will kill a failing project and reallocate staff to other priorities.

Item zero, 1.5, 2.5, and 3.5 on your list is to listen. Struggling teams are made up of struggling individuals who need to be heard. They are surrounded by peers and partners who feel let down. Listening can be scary because it often involves admitting that the problems others are experiencing are not the problems you’re taking on right now. But if you are clear about what you’re working to address and why, and you can lay out a path for improvement, people are more likely to give you latitude than if you ignore or avoid them. Then, if you can demonstrate that you’re meeting the milestones you laid out, you build trust.

The other thing to recognize is that this process is often not a one-time thing, but a cycle. As you tackle the first set of problems, new ones emerge. Midway through my second turnaround project, I produced a 13-page document—meant for me, not for wide consumption—that outlined the constraints we had broken through, and the constraints that were coming next. It was an emotionally draining but fascinating and cathartic process. One of the things I found most interesting was how the same problems surfaced, in different forms, again and again. We would break constraints on, say, communication or project planning, but as other areas improved, those things would become constraints again.

So, should you take on the turnaround project? That depends on whether you believe you can succeed. But that should be a rational assessment and not one based on emotional responses to commitments or risk. Hopefully this process helps you sort through that. My friend and I went over these steps, and she put together her plan and took it to her boss. I can’t wait to see what she does next.