Slow is Steady, Steady is Fast

Scrabble pieces that spell how who and teamwork

Reflections high performing teams and the importance of sharing a playbook.

Welcome back! It’s hard to believe that next week will be the last post and the team will be wrapping up the project shortly after that. In this post, we will be taking a moment to reflect on what is working and what could have gone better with the team’s process from my perspective as an organization development facilitator.

Many folks dread working on team projects. I used to be one of those people, but after working in the organization development world for more than a decade, I’ve come to love working on a team. I feel very fortunate and grateful that all of the teams I have worked on at OSU have been great and Ted and Rebecca have kept that trend going. Everyone has done what they committed to and if they weren’t able to get it done by the time they committed to it, they communicated and were able to complete it without it impacting the rest of the team.

Practices of High Performing Teams

First, we will take a quick look at what makes a high performing team. The following list is from this post from Blue Beyond Consulting. It is one of my favorite lists about practices of high performing teams because it incorporates findings from much of the research available on team performance.

  1. Clear and aligned purpose
  2. Clear roles and responsibilities
  3. Build trust through relationships
  4. Communicate frequently and effectively
  5. Collaborate often
  6. Appreciate & encourage diverse thinking
  7. Manage conflict constructively
  8. Learn and adapt
  9. Celebrate success and show appreciation
  10. Measure outcomes and success

Additionally, this Harvard Business Review article and Patrick Lencioni’s The Five Dysfunctions of a Team have great guiding principles for teams as well.

Where We’re Crushing It

Now, let’s take a look at a few of the ways the team has been crushing the process of building the escape room in the context of these practices.

  • Clear and aligned purpose – We clarified that we were looking to meet all of the requirements of the escape room project proposal first and make improvements.
  • Clear roles and responsibilities – We clearly defined that we would all work together on the global aspects of the program first and then work individually on our own separate room. Before starting work, we let the team know what we were going to work on.
  • Build trust through relationships – We have asked each other for help and used humor to build relationships. We also were open about where our strengths and weaknesses lie.
  • Communicate frequently and effectively – We communicate on discord most days of the week and frequently on the days each of us is working. We also have been willing to jump on calls in order to help each other out or to get clarity.
  • Collaborate often – Team members checked in about design decisions and all of us worked on the player and camera movement implementation together because we couldn’t quite get it sorted out.
  • Appreciate & encourage diverse thinking – We ask for and welcome each other’s feedback and to speak up if something we are saying doesn’t make sense or if we have any ideas.
  • Manage conflict constructively – We haven’t had any overt conflict to manage. When we have had differing ideas, we clarified our ideas and generally agreed on how to move forward.
  • Learn and adapt – When we ran into issues with Git, we were able to learn from each other and the internet to fix the issue and get back on track. We were able to the same when we ran into an issue with the build right before we had to turn in our first version.
  • Celebrate success and show appreciation – Our Discord chat is filled with thank you’s, woohoo’s and celebration emojis. 🥳
  • Measure outcomes and success – This to some degree is built in for us in that our grade is a measure of our outcomes and so far we’ve aced it. We also have reflected on where we are at every couple weeks to see if we are back on track with our plan and where we need to pivot.

What We Could’ve Done Differently

From my perspective, if we were doing it all again, we could have done a few things differently that would have made the process smoother.

  • Clear and aligned purpose – We could have attempted to talk a bit about the program design and how we envisioned our classes integrating and interacting. We only had one person who was familiar with Unity before and it was harder for us to consider the big picture without understanding it better. While the structure would have likely changed, we could have gotten a general idea based on our more experienced member’s perspective. It was pretty clear they had some good best practices that we discovered after a couple weeks about how to have classes interact and assign them to game objects.
  • Clear roles and responsibilities – It would have helped to clarify the flow we were going to use for Git in more detail earlier on so that our team member who had less experience could ask questions. We might have been able to avoid a couple of issues that we ran into with differing file structures and undoing each other’s work in merges.
  • Build trust through relationships – We’ve had great rapport overall. We could have done a little more getting to know each other as people outside of the OSU and computer science context.
  • Communicate frequently and effectively – Since we left the class design structure open, it would have been great to communicate earlier and more frequently about how we envisioned our classes integrating.
  • Collaborate often – While we were coding, we could have engaged each other for ideas about how we would approach problems more. It would have encouraged us to learn more from each other.
  • Appreciate & encourage diverse thinking – Along with the last idea, it would have been great to hold a brainstorm session for puzzles and story line to connect our rooms more seamlessly and to come up with different ideas we wouldn’t come up with on our own.
  • Manage conflict constructively – There’s not much to improve here. We didn’t have any real conflicts. No one was really wedded to a particular idea or approach.
  • Learn and adapt – Similar to other areas, sharing best practices with each other earlier would have helped.
  • Celebrate success and show appreciation – We are pretty much crushing this. 🥳
  • Measure outcomes and success – We could be more systematic about using our Trello board as a team.

In Conclusion

I would definitely choose to be on this team again, which is a great sign. While, from my perspective, there are certainly areas where we could have made things smoother, we have been successful both in outcome and in the quality of the process.

The areas where we could improve are pretty common for most teams. Slowing down in the beginning and taking sufficient time for building relationships and for everyone to get clear before executing tasks is the area we see most teams struggle. It’s important for team members to not just be clear on what it takes to win the game, but on their skills, their positions, and the plays that will be executed to get the win.

That’s not to say more time planning, clarifying and relationship building is always better. There is a fine line between creating and clarifying the playbook and getting stuck in analysis paralysis or creating a plan that is too detailed or rigid. It can be a useful and effective approach to get started with a general understanding of the process and iterate from there. The key is in being able to identify the when clarity and revision of the plan is needed and that requires trust, relationships, and frequent communication.

Until the next post, be a goldfish.

Sources

Print Friendly, PDF & Email