Building Team Trust, Front to Back

Trust is more than a feeling. In a project, it is something that can be grown from careful planning and development of good requirements. Ellen Gottesdiener describes three types of trust which can be built from good requirements and team management.

In a TV commercial for an auto insurance giant Geico, a clueless boss says to the hip gecko (the company's mascot),"Trust is key when talking about Geico. Ya gotta feel it." The executive then suggests they take part in a trust exercise "where I fall backwards and you catch me." He rises, turns his back to the tiny lizard, and begins to fall. The gecko-outweighed by, oh, 180 pounds-mutters, "Oh, dear."

Trust is key in all kinds of business settings, including the most daunting part of software development: defining the product's requirements. Without trust, development teams experience project churn, high turnover, low morale, and unhappy customers. Stakeholders may cultivate hidden agendas, spread rumors, whine instead of contribute, and even subvert the team's work.

But contrary to the TV boss's beliefs, you don't nurture trust among your team by making people (literally) trust that they have each other's backs. And even though you "gotta feel it," trust isn't simply a feeling. Instead, trust grows out of good requirements practices that are established up front-at the start of your project-and serve as key elements of the team's standard processes.

Insights About Trust
Reina and Reina (2006) identified three types of trust that organizations need to foster. Contractual trust is based on an unstated agreement that everyone is jointly responsible for the success of a project. This is the kind of trust the insurance guy is looking for: you have my back, and I have yours. If things change, we will renegotiate. Communication trust depends on frequent and honest communication. Team members share (not withhold) information, tell the truth, acknowledge their errors, respect confidentiality, and seek and provide feedback. Their actions are consistent with their words. Competence trust means that team members respect everyone's ability to get the job done. They promote mutual learning and development of everyone's skills and knowledge. The good news? Using good requirements practices-the ones you should be following anyway-builds these three kinds of trust.

Building Trust by Defining Vision and Scope
A product vision describes what the team needs to build and for whom, and it explains how the product will serve its customers and will differ from existing products. Developing a vision of your product builds trust. I like to facilitate this process by using hands-on activities, for example, leading team members in drawing a picture of the before and after state or creating an imaginative "product box" (Hohmann, 2006). I combine these activities with writing a vision statement, often by using Geoffrey Moore's product vision format (Moore, 1999). This process builds contractual trust by establishing shared goals for business experts and technical staff. It acts as a contract for what will be built, and it establishes boundaries within which trust can operate. If the team can't agree on the vision, you're not ready to plan and build the product. As the project unfolds, teams should also maintain a glossary to define business terms. When team members understand and speak the same language, it builds competency and communication trust.

It's crucial to have the right stakeholders participate in defining the product vision and requirements. The first step is to identify stakeholders and other sources of requirements information. Consider a variety of people who can take on the perspectives of different stakeholders: product owners, champions, sponsors and buyers, end users, subject matter experts, developers, business analysts, project managers, specialists in testing, QA, auditing, regulatory issues, training, sales, marketing, and so on (Gottesdiener, 2005).

You build communication and contractual trust by planning how and when to involve stakeholders. You sustain trust by following through and collaborating to explore, elaborate, and decide on requirements. Another good practice-planning how the project will acquire and improve team skills-also promotes competency trust.

About the author

Ellen ellensqe's picture Ellen ellensqe

Ellen Gottesdiener, Founder and Principal with EBG Consulting, is an internationally recognized facilitator, coach, trainer, and speaker. She is an expert in Agile product and project management practices, product envisioning and roadmapping, business analysis and requirements, retrospectives, and collaboration.

In addition to co-authoring Discover to Deliver: Agile Product Planning and Analysis with Mary Gorman, Ellen is author of two acclaimed books: Requirements by Collaboration and The Software Requirements Memory Jogger.

View articles, Ellen’s tweets and blogfree eNewsletter, and a variety of useful practitioner resources on EBG's website,

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!