GitPrime is Renaming to Pluralsight Flow Learn more

Improving “Problem Teams” – When There’s No Definitive Cause

Perspectives in Engineering

Improving “Problem Teams” – When There’s No Definitive Cause

GitPrime elevates engineering leadership with objective data. In this interview series, Engineering Leaders talk about how to build high performing teams.

If you’re like the rest of us, you’d like to think that you tackle company problems as soon as they arise.

But if you’re like the rest of us, the truth is that a number of problems go unaddressed indefinitely — there are only so many things that can be fixed at once.

Sometimes these problems are just a low-level hum that you think you can ignore a while longer.

“I think everyone at a certain point can relate to being in this situation,” says John Cutler, Senior Product Manager for Search Platform and Relevance at Zendesk. “You can hear it. You sense that you’re grinding your wheels on something.”

We’re talking in vague terms here precisely because this drift into failure is itself difficult to pinpoint. Things started to crack at some point in the past and by the time anyone does anything about the issue, it’s a chronic injury. It’s not acute anymore. “Yeah, you can measure it,” Cutler says, “but unraveling it is super difficult.”

So if you can’t isolate a problem and address its systemic source, what hope do you have of fixing it or preventing it in the future? Cutler, whose background ranges from business analysis to UX research in addition to product management, spoke with us about problem teams and how to improve them when you can’t identify the problem’s definitive roots.

Listen to the front-liners

Because these drifts into failure tend to reverberate through an entire team or a whole product development process, the impulse might be to take a bird’s-eye view of the scenario. Instead, Cutler suggests that you get closer to the ground.

“Most teams and most professionals, assuming you’ve hired decently, will know when the slip is happening,” he says.

Your engineers know when failure is happening. And honestly, they’re often the ones raising the warning flags at all the early symptoms. They’re the ones saying “Hey, we’ve got more production issues this month than we had last month,” or “Hey, we had to tackle more debt when we tried to get these features through.”

“Most teams and most professionals, assuming you’ve hired decently, will know when the slip is happening.”

“Leadership culture assumes that you’re going to pick up on those cues and act on them immediately,” Cutler says. “But the challenge is, that the frontline people are often not the best to communicate that to the business in a way that is actually actionable or practical.”

Part of the way to address these problems in a productive and timely fashion is to emphasize and implement an early warning detection system for this stuff. Actually, you already have that system—it’s your engineers. So you need to empower them, as the people closest to the work, to speak up about these problems.

That hand-raising and flag-waving doesn’t happen, though, if you have a system that dings people for that drift.

“You can have the best implementation, the best instrumentation, you can have all of that, and if a manager is only looking at it and dinging people for what’s not part of their day-to-day, then I think you get a bad cycle that spins out of control,” Cutler says. “The engineers will never feel open enough and safe enough to say, ‘This is happening.’”

Escape the Feature Factory

That emphasis on the day-to-day without the freedom to voice concerns is part of what Cutler calls the Feature Factory. “It’s the sense that you’re just churning out features but nothing is working,” he says. “Everything’s on time. Everything’s out the door. Everyone’s happy. We hit all our particular deadlines, but we’ve never seen any data to show that it works.”

Engineers in a Feature Factory are “doing their part,” but they seldom see that anything is actually working. In other words, they don’t see any impact. “Engineers really want to see the impact they’re creating,” Cutler says. “The novelty of pushing something in production wears off.”

Engineers require feedback loops with hard data from the product side. They need to feel closer to the customers to understand how their work matters.

He has worked with engineers who, even early in their careers, say, “I need access to the data. I need to understand if any of these features are working, because this feels reckless, and it feels like you’re asking us to cut corners, and there’s no evidence that any of this is working.”

So what these engineers require are feedback loops with hard data from the product side. They need to feel closer to the customers to understand how their work matters.

Getting the data for the engineers is about engaging them. “The flip side is that engineers own their technology, and what they’re working on, and how stuff is accumulating,” Cutler says. “They feel responsible for what’s happening.”

By understanding how their work matters, engineers will take greater ownership. And that means both flagging problems as they arise, and experimenting to improve the system proactively.

“You’re trying to encourage a new behavior of some kind,” Cutler explains. “You intervene in the system, so you perturb the system somehow. Then you need some way to observe the results and see what happened. And then, the whole process starts all over again. That’s the nuts and bolts of it.”

In other words, engaged engineers are free to flee the Feature Factory. Then they can actually advance the work they’re doing for your product and your company.

A safe space for craft

Cutler points out that on a problem team there’s often a loss of hope. Someone has been waving the flag for years, and nothing’s happened. Then a team can succumb to what he calls the “Ops Death Spiral.”

It starts when, for whatever reason, a team’s chronic problems are becoming more apparent. To overcome the grief, the team decides to adjust to “do things better now”—or appear to do things better. So they start developing silver bullets and shiny objects, which don’t address the root concerns.

Despite the production coming out of the team, they lose the organization’s trust and ultimately get cut out of the development loop. “This team is like Survivor,” Cutler says. “They’ve been on an island. They’re gnarly and their hair is all tangled. You need to break out of that cycle somehow.”

“There’s a craft movement going on in software development. People care deeply about craft.”

He touched on the concept of psychological safety earlier in regards to feeling free to speak up about problems. The more forward-thinking side of psychological safety is that a safe environment will foster continuous improvement.

“One part of psychological safety on teams that’s often missing when people talk about it is craft,” Cutler says. “There’s a craft movement going on in software development. People care deeply about craft.”

“We’re at a point now where if you think holistically about craft, teams can take on responsibility,” he explains. “We’ve got the tools to think about continuous improvement. Monitoring your own data about your output as a team. Thinking about what you can do to improve that. Bringing everyone into the game.”

This safe environment opens up your team to tackle much more complex problems too. And Cutler’s best advice for those problems is to allow for safe-to-fail experiments. That way, a team isn’t just responding to problems—they are testing the system itself, trying to break it, in order to make it stronger.

In this environment, with both immediate problems and systemic ones, a team is now able to be proactive. To call things as they see them. No one is freaking out, and folks are nipping problems in the bud as they arise. And there will always be problems; that’s a given. But in a constructive environment, you won’t have a problem team. You’ll have a problem-busting team that can solve its issues organically, creatively, and independently.