Continuing with my focus on the Bruce Tuckman model, this week I recount my experience of working with performing teams.
There are lots of external factors that effect a team. They are part of a wider network of teams, a larger system, be it the company, the vertical, the industry, the supply chain. Changes in any part of the system can have both positive and negative effects on the team and vice versa.
What I think makes a performing team is one that is inwardly supportive and outwardly flexible enough to thrive in a changing system and environment. Performing doesn't mean that everything goes right, and this is especially not the case in tech. It means that the team pull together and can resolve the things that go wrong in a way that is satisfactory to all parties, without having a destructive impact on the team and whilst still hitting targets.
Years ago I was replacing a legacy piece of technology that was underpinning an essential piece of functionality in a wider system, with a new third party application. It was what I refer to as 'open heart surgery' and not something I would have attempted with the responsible team for years prior to this time because they were not the team we needed to do this.
Initial deployments in the test environments went well (too well I remember thinking) and so we schedule the live date. It was linked with a larger piece of work in our internal user base and as such there was an immovable deadline that had to be worked to. We were up to the wire on timings (what IT project isn't) and we only had one chance to roll out. We knew the lead developer on the project was not great at asking for help and so we had worked together to develop several back up plans so that we could all assist even without being asked.
The roll out went ahead one Friday night and for the first few hours the info from the dev team was positive. I forget now (probably blocked out of my mind) what went wrong - it was one of those ridiculous little things that come up in large systems integrations every now and then that no one could have foreseen until the point it was found. We had been here a couple of times before but this time it felt different.
The whole team hunkered down and started brain storming and quickly came up with a plan. They took note of the developers who had already lost sleep over this project and divided the work that needed to be done between them over the weekend. They were agile, self managing and didn't have to be asked once to stay and get it sorted. There was absolutely no question of the project failing and they were all in it together until it was put right.
I wasn't needed in my usual crisis management role. My authority wasn't needed to make people stay and I was no longer the best person to solve the problem. My role was to provide pizza, red bull, even the odd hug and make sure everyone was getting the sleep they needed. And once it was live in the early hours of Monday morning, the business and client none the wiser, it was my role to thank and recognise the efforts of the team and ensure they were rewarded adequately. And to reflect back what had been achieved to cement it in to their toolkit of experiences for use in the future.
The sense of achievement and comradery that team had from then on was incredible and from this common belief that we could do anything, we went on to attempt even bigger and more major projects that were very successful and met every expectation of the business and user base. It wasn't a permanent state, things change, people move on, and you start again, but I know the friendships made and experiences gained from working in that team will stay with each participant for the whole of their careers, most so me.
If you are interested in arming your leaders and their teams with practical models and a shared understanding of these team phases to help improve your team resilience and performance, please reach out so we can arrange for a chat about how my team coaching partnership Dynamic Connections can support you.