Covenants for Establishing Team Community by Mark Komen and Kodyne, Inc.

Covenants for Establishing Team Community

Mark Komen, President

Kodyne, Inc.

Plymouth, MN

Over the years, many studies have outlined what types of environments technical professionals (used synonymously with the term “knowledge workers”) prefer to work in to be at their most effective levels of performance. So the obvious question is how does an organization take advantage of this information to create this environment? After spending my 30-year engineering career in large companies, I would have thought more of them would have done a better job at this than they did. After all, if they hired us to create products for them, why wouldn’t they unleash us to do just that? What was important to consider here?

Thinking about this from the corporate or divisional level was too large a universe for me. There were too many political, social, economic and competitive variables at play here. It wasn’t until I began working in the self-managed/self-directed work team environment, that I was able to get my arms around considerations for building these local environments, or just as descriptively, work communities. This very question energized me to do some research of my own on this subject of building creative environments on self-directed work teams of technical professionals. I learned that what’s needed to support creativity and innovation on these teams was a combination of technical and process elements along with a very heavy dose of interpersonal considerations. All of these were pushed and pulled on by the environment the team existed in and were heavily influenced by things like time, money, management support, contract technical specifics and the culture of the surrounding organization. See my related article, The Creative Space Model – A Tool For Teams.

More on culture in a moment. I built and led one particular self-directed team (SDT) for 5 years. During this extended time, I was able to guide our team’s formation, growth and learn what worked and what didn’t. Our mission was to develop a sensor that could survive extremely harsh environments for a defense application. The overall sensor system required hardware and software integration in a very small, robust package. Team members were divided between 3 separate locations in one city, with 1 member located on US eastern seaboard – which qualified us as a distributed team. We found that inclusion, access to the “team memory” (also referred to in the literature as corporate memory or organizational memory), and the philosophy of building on our combined strengths, helped us to build the trust necessary for all members to contribute our best efforts and to represent team interests with a single voice. The end result was a successful autonomous field demonstration of the entire system years ahead of the typical schedule for such a development program.

Our team was one of several teams on this project and we needed to fit all the teams’ contributions together to create the total system. We were able to achieve scalability, literally, by achieving smallness. What I mean is that we were able to work at the “micro level” with the relatively small number of members on a given team to get them operating effectively and then expanded the interactions to include the other teams; this as opposed to working the entire 100-person project team as a single “meta-team.” Our challenge was to maintain an entrepreneurial spirit while still recognizing the need to consider the bigger picture needs of the project.

An important consideration was for us to recognize that although each discipline represented on the team featured its own technical specialties, we needed to develop technical literacy – the ability to expand beyond our individual niches to understand how each specialty interacted with the others and how this would impact the whole. To some ways of thinking, distributed SDTs are independent entities so disconnected from the organization at-large, they can never produce useful outcomes. In my view, the successful SDT approach doesn’t automatically create chaos – but it does require a special kind of structure, especially if team members are not physically co-located. The key elements for success require a shared understanding and agreements (covenants) about: goals, processes, tools, skills, values, and normative behaviors. These items speak to the culture inherent in the work team. Culture is generally defined as the characteristic patterns of thinking and behaving common to a group, informed by shared values and beliefs of its members and observable as the norms and expectations necessary to fit in and succeed. In the team described above, we established constructive cultural elements upfront as expectations for team membership. Constructive organizational cultures combine aspects of achievement, risk-taking, personal and professional growth, humanistic interchanges, and openness to build the trust necessary for a cross-functional team drawn from different technical disciplines to constructively identify, evaluate, refine and implement ideas.

It should be very apparent that the role of the team leader is a key one and requires special attention to the selection, training, and support of the person in that position. Building a zero-history group from an architectural perspective avoids the need to overcome resistance to change by imposing and architecture first, then permitting teams to add the detail they need to function and produce their products. I think of this as an analogy to building a home. The owners agree to the specs called out in the house design blueprints and then they pick out the appointments they want or need. From the organizational perspective, this minimizes idiosyncratic approaches by outlining cultural expectations upfront – even as requirements for new or continuing membership on the team. After establishing the cultural elements, the next step is to build task alignment/roles/responsibilities/relationships in concert with a culture of achievement. Hire team members for fit to these expectations and reward them for fit.

At the same time, you need to be ready to remove someone from the team for lack of fit (or production) but provide them first with the opportunities and guidance for making changes. This same approach is well-suited for use at the organizational (corporate) level where a launch of a new corporate entity is planned to take place. Alignment of the cultures between the organization as a whole and the teams existing (embedded) within it can be addressed by similar attention to shared expectations for collaborative normative behaviors, common goals, processes, tools, skills, and values. As long as alignment is approached as a system architecture initiative, teams can be aligned within a single organization or teams can be aligned in a distributed configuration. Think small to think big.