Story:
Organizational Trust 2.0: 42projects

In June 2006, we started to look at what we could change, organizationally, to better engage these relatively new employees with diverse experience and interest in contributing in areas where they weren’t necessarily experts. We looked, for example, at 15% or 20% time, made famous by 3M or Google, respectively—and yet, the ebb and flow of the project cycle prevented the deployment of a single holistic program across the entire organization. At that time, we encountered the paper “Well-being and Trust in the Workplace” from Helliwell and Huang, that showed that a 10% increase in organizational trust equated to a 36% pay raise as measured by job satisfaction. We had seen the role of trust in creative and innovative organizations. Behaviors like “freedom to fail”, risk-taking, and ability to suggest new ideas, empowerment, creative freedom, flexibility, and agility—all of these actions are rooted in trust. As we discussed how these activities would address our generational work style challenges, we agreed that creating a high trust environment on the team might invite these behaviors. While we agreed that a climate of high trust would have a positive impact, we had serious questions about how to take action. We knew we couldn’t simply send a memo to the team inviting them to “trust us”. At this stage, trust was a brand new, awkward, and potentially emotional topic. How could we convince people that trust was a good thing to actually spend their time on? No one disagreed with the notion that more trust was better than less, but to actually take time away from “real work” to build trust was a dubious proposal. We had already established a weekly forum where we bought pizza and invited team members to come and share—ideas, projects, proposals, and research. So we used one of these “pizza meetings” to brainstorm the list of behaviors that influence trust. Participants came up with about 150 trust-influencing behaviors (http://www.defectprevention.org/PairsLB.aspx?group=31a3675c-bbb3-4b91-9f...). At the end of the meeting, when people returned to their regular jobs, there was very little excitement—no one felt like we had just rocked the world. They were happy that we paid for their meal—and questioned whether we could use that time more effectively on more tangible activities. We continued the trust building behaviors we were already doing, stopped doing the things that eroded trust, and start working towards the new behaviors that were identified. We talked about trust constantly—aspiring to build the level of trust on the team—without knowing how—nor how we could measure progress. So we fumbled through talking awkwardly about fuzzy stuff—actions and behaviors that influence trust—and tried hard to measure progress—with little success. As a metrics driven organization, we wanted to know the top 2-3 things to do—and then to go execute on them. But this was different—because the behaviors were contextual and relationship-based. While “Be transparent” was important in some situations, “integrity” was important in others. To create some excitement, we built a simple game to help order or rank the behaviors (http://www.defectprevention.org/trust). The game reinforced the notion that the behaviors were relationship-based and contextual and there was no simple formula for success—so we built a wiki to enable group collaboration around a “trust playbook." As an example, one of our behaviors was “Praise Publicly, Correct Privately.” Part of the wiki entry looks like this: Praise publicly, correct privately "Praise in public; criticize in private." – Vince Lombardi Everyone makes mistakes, but that doesn't mean we like it. We like it even less when their mistakes are pointed out to others. 

To build trust with others, speak highly of them in public. This does not have to be artificial, but wait for an opportunity when someone deserves praise and tell people about the accomplishment. If they make a mistake tell them privately so they have the opportunity to correct it. Reinforcing this practice will help to build trust and encourage experimentation and risk taking. If people realize that mistakes will be corrected privately, they will be more likely to stretch themselves, worrying less than if their errors were broadcast and scrutinized in public. People knew that building trust was a focus of the managers on the team– and the effort to list out behaviors that influenced trust gave people an excuse—or a language or framework to call out things that they normally wouldn’t have talked about. So, for example, one person identified “show sincere appreciation for work done" —and with that, a first level people manager could now feel comfortable congratulating someone on an accomplishment. They might send email to the person and add a senior manager or director to the email—knowing that they wouldn’t be over-stepping their bounds—and, they could point to the wiki and the list of behaviors to say, “I was just following this guidance." The constant reminders of the goal to build trust brought an awareness that started to change behavior. We did not integrate 42projects into our performance review process, but deliberately kept it separate. This may sound puzzling, but we felt that we were trying to encourage a lot more than we had the ability—or the budget—to reward. We wanted to encourage “organizational citizenship”. Some, but not all, of these achievements were going to be reflected in work that we were being paid for in Windows Security tasks—our “in-role behaviors”—and those achievements would be part of the annual performance evaluation. We had no special funding or additional budget for 42projects. It was a completely volunteer effort—and not every member of the team wanted to work on games, or trust, or management innovation—and that was OK. If people wanted to focus on their Security work—which was our ultimate business goal—then that work should be where the organizational rewards should be distributed. The additional 42projects work was optional and voluntary—and while we felt, and witnessed, that this would lead to more productive Security work, it was an experiment—ans our performance evaluation rewards budget should be allocated in line with achievements related to our Security business goals. The belief, and our subsequent experience, was that a culture of trust, freedom, and collaborative play would lead to innovation in how we manage, innovation in how we do our jobs, and a positive impact on our tradition business metrics. We used productivity games – games built on top of the work we do – to encourage fun, competition, engagement. We had a small book club, that would share latest management and innovation related titles. And, when we finished up the Windows 7 project, we saw our traditional productivity metrics rise.