Published on September 30, 2015
Three key practices for getting to know and really communicating with your team members
In my last post, I spoke about engineers’ and engineering students’ bias towards seeing ‘what’ their team members produce as opposed to ‘who’ their team members are and ‘how’ they can contribute to making the team and the product better. Teams that only see the ‘what’ eventually fall apart or produce suboptimal work that no team member is proud of. Getting engineers to see and value ‘who’ their team members are is necessary to get team communication to a level where the whole team can be greater than the sum of its parts. This post explores some ways of effectively cultivating the ability to see ‘who’ your team members are
…The two most common competencies cited as necessary for effective engineering teams are showing respect for team members, and demonstrating accountability. …
In my research, I have surveyed engineering students on the most important competencies necessary to create effective teams. The two most common competencies they cite are showing respect for team members, and demonstrating accountability. However, to do either of these things the engineering students first need to know ‘who’ their team members are. They need to develop an understanding of each other to know what respect means in that team, and the safety to be willing to be accountable in times when their performance does not meet their team’s expectations. Developing a set of team rules, or code of conduct, is commonly cited as a way of providing structured behavioural expectations for each team member. However, I find this particular approach perpetuates this inability to see ‘who’ your team members are as it creates an external authority figure to be accountable to. As a result, team members may blindly follow these expectations without discussing whether they believe in them, or may ignore them all together as it does not provide a sense of accountability to the people they are actually working with.
… Developing a set of team rules … perpetuates the inability to see ‘who’ your team members are as it creates an external authority figure to be accountable to. …
I personally encourage those entering into a new team to define a process of working together that captures ‘who’ they are. To do this, I equip new teams with a set of guiding questions to discuss and negotiate until they have a sense of a collective team identity. As they do this, I ask them to observe who is contributing and ensure that everyone has input in defining their work process. In this way, they get a chance to discuss their beliefs and expectations around the work they are doing, but also get a sense of the communication styles and personal attitudes, of each of their team mates.Three practices that I deliberately seed in these discussions to ensure that more of the ‘who’ of each individual is included in the team are:
1. Engage in Collective Visioning and Decision Making
There is nothing worse than reading a design report with five different voices, discussing five different variants of the design. Taking some time before putting pencil to paper (or fingers to keyboard) to negotiate what is being designed, and what perspectives will be privileged is critical. As team work gets divided, this need for a collective initiation can be ignored; there are times and places for everyone to work on their own, and on a separate device, but decision making is not that time. I encourage teams to get everyone together (either through video-conferencing or face-to-face) and debate and negotiate until everyone is comfortable with the decision being made. This does not mean a team has to always have consensus, but means that there has been a space for everyone’s input to be heard, evaluated, and considered as a factor in the decision making process. In this way, the decisions made by the team can represent ‘who’ is a part of it.
2.Delegate tasks based on strengths, rather than project components
The concept of dividing a report by its section headings for different team-members to write is one of the most disheartening aspects of working with engineers. They divide the sections without seeing the interconnections between them, and the fact that the decisions that shape those sections have to be made collectively. As a result, there is no unified voice or vision in the document. Additionally, it means that team-members are not being leveraged for what they are interested in or are good at (their ‘who’). When a team is beginning to negotiate how they are going to work together, make sure everyone takes time to introduce who they are, what they like to work on, and how they like to work (e.g. well in advance, or under pressure). Bringing all these personal variables into the mix can create different divisions of labour amongst a team that allow the team members to feel more valuable and create work that they feel not only a sense of ownership in, but also (hopefully) a sense of pride.
3. Acknowledge Affect exists
Engineers in particular are great at adopting new technologies, and at times getting a little bit too excited about what they can do. The group chat box on the side of a Google Drive document does not substitute for a real discussion. Acknowledging the role affect plays in communication is vital to ensuring that everyone can see ‘who’ is communicating and not just what they are textually typing. Affect is severely inhibited in text-only communication mediums or has the ability to be interpreted in multiple different ways. This multiplicity of interpretations can be the start of miscommunications, and misunderstandings that lead to team conflict. When trying to effectively negotiate design decisions, or team processes, I push teams to use higher resolution modes of communication that allow for affect to be observed and responded to.I have talked so far about some discussions that can shape how a team works together to create a culture of effective teamwork. But what can an individual engineer do to make group communication happen easily/better when they aren’t starting a new team? In my next post, I will explore some strategies individuals can use to get to see more of ‘who’ their team members are and how to use this to improve group communication in their teamwork.
Patricia Kristine Sheridan is a PhD candidate at the Institute for Leadership Education in Engineering at the University of Toronto where she has been a team-effectiveness researcher and engineering design educator for 4 years. She has researched student behaviour in over 300 different teams, following some teams in depth for up to 4 months, and has designed an on-line system to facilitate the development of team-effectiveness behaviours in student teams. Her teaching and course development focus on creating interactive learning activities at the intersection of design, leadership, teamwork, and identity formation. She holds a BASc and MASc in Mechanical Engineering, and has previously worked on large plant design teams in industry, and on algorithms to develop co-operative multi-agent systems in robotics.