Turning Around a Dysfunctional Team

Problem

A few years back, I was tasked to take over a particular department in charge of back-end, tooling, and some critical systems when their VP of Engineering decided to leave the company. It was a large department totaling 60 engineers and widely perceived as not performing up to the standard. They were opaque about their work, other teams didn’t like working with them, and they would frequently be unable to deliver on time.

I had my own tiger team of four senior engineers -- small in size, but who used advanced development methodologies and could ramp up those systems without much overhead costs. We had to identify critical areas where we could either bring in technology or build things ourselves and capture the vanishing revenue due to the team’s dysfunctionality.

Actions taken

I knew the team and most people on it well since my tiger team was working with them on multiple projects. However, the first order of business in those situations is to bracket all the assumptions, assess what is happening and learn why it is happening. We had to examine all the systems, development methodologies, organizational structure, and every individual on the team with great care. It took us between four to six weeks to assess what was going on.

I immediately identified several serious problems. The team believed they did Agile, while in fact, they did waterfall with sprints. They didn’t use a CI/CD pipeline, and the way they used version control systems like Git was not how Git was designed to be used. The team did big, infrequent releases that would often become problematic. Furthermore, people were not positioned correctly; some senior engineers were spending their time doing bug fixes while juniors were in charge of the entire systems. The project management was almost non-existent. There was no pipeline for inbound requests, and engineers were approached on a personal basis to do something. That was coupled with an unfavorable outside perception of the team and a poor happiness score.

It was evident that a massive change was ahead of us, but walking in and announcing that we would tackle it all at once, wouldn’t work. Implementing smaller incremental changes, one by one, would certainly take longer but will pay off in the long run. We came up with a plan, but we didn’t want to impose it and continue with the practice of dictating down decisions made at the VP level. We reached out to senior engineers who were skillful but unhappy with their existing responsibilities and bought them in. We told them we wanted to realign them, have them take on more responsibilities, and become technical leads. They were quite excited about their new roles and eager to suggest some additional responsibilities in all but one case. The person who disapproved was a great IC, and we agreed that they continue working in an IC capacity.

We broke down a department of 60 engineers and three large teams into smaller teams, much like squads. We turned senior engineers into tech leads who suddenly became immensely motivated and whose productivity skyrocketed. We left them to decide whom they want on their team and then streamline their focus on a few projects rather than be spread over five or six code bases.

We also instituted an important rule: people outside the organization could no longer come in and talk to engineers directly. Instead, all requests had to go through the process we put in place. To do that, we purchased modern project management software. We previously used Jira, which was quite cumbersome, so we opted for Pivotal Tracker. It was a much more simple tool and didn’t allow for much configuration and what we needed at that moment was to conform to something. However, Pivotal Tracker allowed us to be more transparent about our work and anyone company-wide could see what the team was doing, which positively impacted the outside perception of how much and on what the team was working.

Next, we introduced Monday morning meetings, and if people wanted something to be on our radar, they had to show up in person to those meetings. Many people were unaware that we were serving that great many internal stakeholders and would be surprised to see 20 more people showing up at the same meetings. Those meetings also served as an opportunity to work with other teams to prioritize their requests against the company’s goals.

Finally, we moved to a simplified Scrum implementation but followed it diligently. We got everyone trained up, with tech leads getting high-end training. I hired a few directors who, together with my tiger team, attended every standup, retrospective, and sprint planning, making sure that we rigorously followed the process. I had noticed before that people would skip a thing or two when implementing Agile, which soon would be followed by a series of oversights that would snowball from there. Suddenly, people would slip into waterfall mode without realizing it. Therefore, we were rigorous about the process for the first six months until we built discipline around it and until it became second nature for our engineers.

Lessons learned

• If you care about people, you will be able to find a workable solution for everything else. Ask yourself: are people on the team happy, what they would like to do, would something else make them happier, etc. The common wisdom is that if people enjoy what they do, they will be productive. Create an environment where they can enjoy what they do, and no doubt they will be more productive.
• Make sure that people are aligned correctly and that they are contributing accordingly. The greatest engineers, if ill-positioned, will not be able to create value for the company. Be aware that restructuring can make some people unhappy. Explore with them if they would be happier in another team or if they should move to another part of the company.
• The more transparent the engineering organization can be to the rest of the company -- including how to be approached -- the better off they would be. Create transparent processes to get new requests into the queue. Software is not something tangible or even visible. Many things, especially back-end things, go unnoticed. If you don’t have a process to triage requests, you will be swamped and unable to serve your stakeholders.
• People often do waterfall with sprints because they mistakenly believe they do Agile. In most cases, people fail to do quick turnaround cycles and instead implement big plans that need to happen in certain sequences. But they boast with their two-week sprints. While it makes people feel good, it is not Agile. One should regularly reassess if they are following Agile because falling into the waterfall situation is quite common.