Back to resources

Turning Around a Dysfunctional Team

Team Processes

6 August, 2021

Dale Cook

Dale Cook

VP of Product Engineering at Stack Overflow

Dale Cook, VP of Product Engineering at Stack Overflow, speaks of his efforts to make a dysfunctional team functional by introducing incremental changes, one by one.


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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

How to measure Engineering Productivity?

30 November

When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..

Ramkumar Sundarakalatharan

Ramkumar Sundarakalatharan

VP - Engineering at ITILITE Technologies

How to improve engagement and retention in remote engineering teams?

25 October

Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Company Culture
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy

Assessing the Performance of Your Team

20 August

Parallels between Work and Sport.

Goal Setting
Different Skillsets
Coaching / Training / Mentorship
Ron Pragides

Ron Pragides

SVP Engineering at Trustly Group AB

Team Development Framework for new managers

26 June

Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Building A Team
Team Processes
New Manager
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart