The Quick Fix to a Slow Team: A Consultant’s Perspective

Problem

I was hired as a consultant to help a team that was moving slow. They lacked a product direction and enough of back-end resources. In addition, the project management process was poor and the team didn’t have much managerial bandwidth. Part of the problem was also that as a consultant I was time-constrained and had a limited number of hours I could dedicate to the team.

Actions taken

The first thing I did was to institute weekly retros that would serve as a space for individuals working on that team to discuss what was working well and what didn’t. I used retros to drive buy-in for the addition of weekly sprints and iteration planning meetings (IPMs). Weekly sprints were based on Kanban and the ticketing system and during retros, team members would discuss how to use pointing and time estimation, project assignment, etc. We took a very iterative approach to our process -- we would attempt a thing for a week, see how it would work, and then change it. One of the key findings -- after running several retros -- was that the back-end was a bottleneck and that we didn’t have enough engineers to help out with it. In addition, the data team that was building interfaces for the back-end team was also a hold-up.

Then I proposed to have biweekly one-on-ones with all members of the team. One-on-ones were not only a venue to exchange feedback, but I used them to speak to each of the engineers where they would see themselves in the project, what type of work they wanted to be doing, what they were interested in learning, how else they could contribute, etc. Once I got a better sense of what each of the engineers had an interest in and a propensity for we decided to transition one front-end engineer to work on the back-end.

We also discovered there was a lack of product direction. There was no clarity around what business objectives we were trying to hit and we decided to work more closely with Product. I leaned in and started working with them on figuring out what the business objectives were and what we wanted to build and why. As I focused more on working with Product we had to find another person to become involved with project management. We found another developer on the team, deputized them, and made them responsible for managing sprints and retros.

After a while, we also added another developer to the team and strengthened our communication with the data team as I became responsible for contact across functions making sure that nothing was lost in translation.

Many changes were introduced in parallel; there was a product and project management thread, a resourcing thread (from a back- and front-end perspective), etc.

Lessons learned

My approach included a lot of delegation and investing trust in other people. If I were employed full-time I wouldn’t have been forced to delegate. I am not sure, though, that it would be the right thing to do as we as managers have to provide other people with an opportunity to learn and grow and create a space for them to be challenged.

• You should be delegating as much as you reasonably can and be honest with yourself what can be delegated.
• Having processes for continual improvement in place is vital. Those kinds of processes also serve to drive alignment for the team on what is working and what is not.
• Teams need to develop their own process and structure and good process and structure are critical for the success of any team.