Getting a Team Back on Track

Sometimes, an important team that’s part of an otherwise healthy company culture starts tanking and the people on the team get frustrated and even quit.

In this article, I want to share what I learned when I started to manage a team — referred to as the R Team from here on out — that had huge problems when I took over as Engineering Manager, as well as explain how I got it back on track.

I hope this post raises your awareness of some of the issues that can affect a team and that you will be able to apply them too — whether you’re a manager, an individual contributor, or just observing a team from the outside.

The TL;DR

• Operating at the throughput limit of a team will tear it apart.
• Technical challenges and business pressure are not the problem. The problem is a lack of focus and collaboration.
• Limiting parallel work streams will increase productivity, team happiness, and stakeholder trust.

The Beginning

The R Team was always under a lot of pressure but somehow coped with it. But then, all of a sudden, the team seriously tanked. In a very short time, one of the engineers quit and the team’s Engineering Manager went on a break and later left the company. In the meantime, two of the team’s five engineers handed in their notices. This left the team with only two engineers, and one of them was also entertaining the thought of moving on.

On the product management side, it was similar. One Product Manager left, and the next one stayed for only one month. The team was behind on everything, and the backlog was infinite. Work was no fun.

What Was Broken?

Most of the time, issues piling up is what can turn a team of great and motivated engineers into a frustrated bunch of individuals. But in order to understand the full picture and to come up with a plan to recover, it is important to put everything on the table. Within the R Team, there were a few very obvious problems that we identified right away:

• A huge amount of tech debt
• A large group of stakeholders, each of them asking the team to work on equally high-priority tasks
• A high amount of domain complexity

To put this into perspective, the amount of tech debt and domain complexity made onboarding new team members — a process that should normally take no longer than a month — a long and intense three-month journey. And because of being pressed for time, there was never time to clean up tech debt. For instance, the oldest of the team’s data pipelines was still in production alongside two generations of rewrites. The same was true for other systems that had multiple generations of rewrites in production. The backlog stretched for years.

It was a lot to deal with, but even under such arduous circumstances, a motivated team could take all this as a challenge and work hard to catch up. So why didn’t this team do this? Why did the members instead feel like giving up? To find out the answer to this, I had to do some digging.

After continued talks and investigation, mostly in one-on-ones, more and more issues became clear. One was that in order to cope with the competing high-priority deliverables, the team parallelized workstreams, which made the members function more like a group of specialists working on separate things as opposed to a team with a shared goal. For example, the team often had more than one epic per person in the sprint as a way of keeping all high-priority tasks going. As a side effect, this pretty much prevented effective knowledge sharing. Indeed, in order to get a complete overview of the tech stack, all team members, each with individual special knowledge, were needed to give their input.

The parallelization also delayed shipping, which then eroded trust from stakeholders. To make matters worse, the business expert who was needed to clarify technical specifications during implementation was overwhelmed by repetitive, manual work. This not only made his job tedious and labor-intensive, but it also made the feedback cycle on technical questions very long.

In the middle of all of this, there was a big change in the organizational structure sitting above the team, and the manager of the team’s new group started up a parallel workstream to review alternative approaches to reducing the tech debt, ultimately replacing the team’s existing technical vision.

Although this was done in collaboration with the team and one member of the team was seconded into the workstream, it couldn’t help but feel like the team wasn’t trusted to solve its own problems.

All these issues considered, it’s fair to say that the team members had the collective feeling of not being heard, understood, or supported by the rest of the company.

Fixing Things

Call for Support

The R Team is absolutely critical for our business, but the team was falling apart. Engineers wanting to leave a team or even the company is a very clear signal that a fundamental change is needed and things can’t continue in the same way. It was also a signal that we failed to take action on earlier signs. To deal with this, we knew the situation needed to be escalated through the whole company. And we escalated the hell out of it: within stakeholders meetings, in executive updates, and with whoever asked about the team.

For starters, we began to look for people internally, and thankfully, we found great people to join the team. Both senior and junior engineers stepped up and wanted to help. And in an effort to bring the team back to its old capacity, we opened a job ad.

We also got first-hand support from a Senior Principal Engineer who joined the team for more than a quarter. He kick-started migrating to a new tech stack, helped with forming a new tech vision, and provided guidance. All of this aided in relieving some of the pressure on the team. In addition to that, we found an amazing Product Manager whose tasks were to clearly prioritize projects and chase down simplifications. The situation of the team was being addressed, and the members felt like they were being listened to by the rest of the company. Support had arrived.

When scaling the team, we also made it more diverse. We now have a team in which three out of seven engineers are women and the ratio of junior engineers to senior engineers is also balanced. This change automatically brought in new, differing, and fresh perspectives. It also helped the team in discussing problems more holistically; no questions remained unasked. This increased knowledge sharing and collaboration, and this alone already began shifting the team’s mood.

New Trust

In my opinion, the most important asset of a team is a shared goal in form of team vision, and the vision must come from within the team. The team members are the experts, and only the experts will be able to come up with the right plan. And as a bonus, because the entire team is involved in forming the plan, each team member naturally buys into it from the very beginning.

But before a team can start discussing great plans, it needs be able to discuss effectively. So let’s get back to forming the vision later and instead focus on communication.

The foundation of team discussions in which everyone speaks up and all options are being brought up is trust. This is not only a must in order to come up with a long-term team vision, but it’s also absolutely necessary to effectively discuss small design decisions ad hoc. The fascinating simple mechanic here is: Get people to open up and share their story, and see how mutual understanding and trust grows. There are plenty of exercises to foster trust within a group, and a lot of them work. For us, two exercises did the trick: “Paint a picture about yourself,” in which we explained where we’re coming from; and “Ways of working,” in which we discussed how we worked — more specifically when we’re the most productive, what’s most important to us, and what’s most frustrating to us individually.

And of course, offsites were instrumental in building togetherness within the team. Taking time away from project work to have full-day offsite meetings, which are primarily focused on vague trust building, might first seem like a big investment, but these paid off immediately. Everyone got to know their teammates better, and as a result, both communication and collaboration improved almost instantaneously.

Defining a Vision

In a couple of workshops, we discussed the biggest pain points the team was facing. We started to put together a “Most Wanted” list of the worst kind of tech debt. In separate sessions, we discussed an ideal solution to our domain challenges and came to similar conclusions, albeit from differing angles. We decided we would weigh work in planning sessions to determine if it would bring us closer to our tech vision or help eliminate painful tech debt like slow, flaky, or tedious manual processes.

But how do we cover what we actually need to deliver to our business? It turned out that just two metrics needed to be visualized to measure our progress: First, a view of how well we were doing in hitting monthly deadlines to generate data outputs (pictured). And second, the number of completed deliverables versus the total number of deliverables. This made our progress and our targets very clear.

Another tool that turned out to be super useful was a complete system diagram, which functioned not only as a snapshot in time, but also as a living document we would actively maintain. We would even color components we wanted to get rid of in red. And in order to visualize progress we made, we cloned snapshots of the drawing every quarter. We also linked all the components to repositories or other resources. If anything was unclear or missing, we often discussed this in the comments of the diagram.

Now we had a go-to visualization that everyone could use to help in understanding the big picture. And we still use this diagram today — for example, during sprint planning, in order to discuss upcoming epics and their dependencies and changes in relation to the rest of our infrastructure.

Automate All the Things!

The productivity of the R Team relies upon a responsive business expert to clarify all kinds of questions, but as mentioned earlier, the expert was often too busy with manual tasks, like creating reports, to respond to requests. He was even trying to help the team by manually delivering tasks, but this almost led to a deadlock situation. He was a constraint in the team’s value chain.

Automating the tasks on his plate unblocked us and freed up more than 30 hours of his time each month. In addition, it also increased quality and decreased the total time of the related business processes. Computers were invented for the purpose of automating repetitive tasks, and doing so in this situation made work on the business side much more meaningful. Together with business, we now tightly collaborate on the epic at hand. With the shorter feedback cycle, we’re much faster. Additionally, the business side now has more bandwidth to talk to external partners directly and manage their relationships.

Ruthless Prioritization

Even if determining top priorities may seem impossible at times, it can always be done. It must always be done. Depending upon your team size, you also need to limit the amount of work streams. As a rule of thumb, the number of team members divided by two is the maximum number of work streams that should be in progress.

There is a long list of reasons why this is absolutely necessary:

• For individuals, working sequentially is faster because it reduces context switching.
• Collaboration is the most effective knowledge sharing. Ignoring that leads to self-imposed fires because any individual team member may eventually go on vacation, go on parental leave or sick leave, or leave the team altogether. Ideally, you actually want at least three engineers to have enough context to work on each task.
• It has a direct impact on team happiness. It allows people to support each other by discussing and solving problems together and to ultimately feel like they’re part of a great team.
• Wrapping up work-in-progress as quickly as possible helps with managing stakeholder expectations and gives the team a sense of accomplishment and progress.

Of course, this all may sound like common sense. However, it’s really easy to fall into the trap of committing to too many things when we are under pressure, both individually and as teams. Taking on more work when there’s already too much is neither healthy nor effective.

Stakeholder conversations can be tough because you need to push for the exact order of the top priorities and the team must only work on a few of them at a time. This might be quite a shock for the stakeholders. But by doing so, the team will actually start to ship efficiently again. And by showing you can complete work efficiently, you regain trust with your stakeholders. In short, building trust with stakeholders is fascinatingly simple: Be very clear with the progress of all your projects and deliver them one by one.

Conclusion

With the right approach, the R Team’s morale was recovered in a very short time. And after only four months, the team was back on track delivering on business requirements while chipping away at tech debt. And none of this was magic.

As stated in the beginning, operating at the throughput limit of a team will tear it apart. A team with 99 percent utilization will actually be slower than a team with some breathing room. And as tech debt piles up and knowledge silos develop further, the team will start to struggle.

Technical challenges and business pressure are also not the problem. We all want to work on important and challenging problems and make a great impact. The problem is a lack of focus and collaboration.