The Quick Fix to a Slow Team: A Consultant’s Perspective
30 September, 2020
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.
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.
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.
Peter Berg, Founder and CTO at Forward, recounts how he introduced processes for continuous improvement and thus creating a more psychologically safe working environment.
Founder / CTO at Forward
Peter Berg, Founder and CTO at Forward, describes how he helped ramp up a slow-moving team by applying his simple, yet expert approach.
Founder / CTO at Forward
Caroline Parnell, previously managed product teams at O2 and Vodafone, shares some of the techniques she applied with her team to ensure diversity of thinking during product discovery workshops.
Most recently Head of New Product Innovation at Previously O2 and Vodafone
Justin Potts, VP of Engineering at MoneyLion, tackles the ever-intriguing problem of simplifying the architecture and thus reducing the overall complexity of the systems.
Head of Engineering at MoneyLion
Brian Guthrie, VP of Engineering at Meetup, shares how he learned the hard way that many Agile processes he eliminated had their second-order effects that the team was benefiting from greatly.
VP of Engineering at Meetup
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.