While I was in India, I met many people, both at work and outside of it. Aides, mentors, grad students, and researchers from elsewhere in India or Europe. Although it has been many years, I barely integrated any into my research process. Why was that? I believe I failed to see how to engage them with my research (water rights for farmers) beyond whether it was tangential to what they were working on. Although I faced challenges, I rarely discussed my project for them to mitigate my problems from their experience.
Now, I am in a much more senior position. I need to assign and form teams that don't fall prey to the many problems I had. In my department, teams are sized by importance and resources, not necessarily the extent of tasks. Many teams are built from people volunteered from their office, to serve the greater good, but also because these workers have bandwidth to support. This kind of team building doesn't use the strict business function representation criteria of many product teams (Trott, Chapter 15) or (Cooper, Chapter 3), representing knowledge on delivering a product. To make my teams more effective, I can address deficits found in both my old and current process with best practices from teaming research.
One deficit I had and still see was a lack of regular feedback, even self-examination. In Agile, the retrospective is core to development. In Stage-Gate, rapid spiral development helps build that feedback users need. As the PI on my grant, I didn't work with my team in India to get that feedback, with a collaborative mindset (Garrett, Chapter 6). In government, the team leads rarely have formal process to give frequent feedback when leading assigned teams; this is oft undocumented and informal. This should be made explicit in charging the team with their task. Furthermore, the teams should ensure they have set aside time to review their teaming and not just produce.
A second deficit was determining the membership of my team. Although I have some knowledge of the skills of people on a team, my initial interviews with my research team in India did not provide that understanding. My cultural divisions, faultlines, were so large, I failed to recognize the diversity and utilize it (Garrett, Ibid). On the teams of volunteered people, we typically only know the role they are in and whatever team roles they may volunteer to fill. Research teams, like product teams, must understand their membership to address knowledge gaps related to tasks assigned. As I assign teams, I will ask them to both draft out the activities they expect or may need to take, list who has experience with each. I could encourage that they further share resumes or CVs help spread that awareness of unknown skillsets and experience.
In short, because of lack of process competency, I failed to utilize my team. Because of lack of experience, I failed to recognize the skills available to me on my team. I want future team to examine what they do and the diversity they have. The best way to do so, is to have the team draft out what they expect, who can assist, and to return to it regularly to inform their path forward.
