Some Thoughts on Trust

When you have a blog, it’s easy to talk from a position of assumed authority. After all, writing something down makes it seem like the author must know something. If that author has a pedigree of any sort — say, a career of any significant length or certain accolades and honors — then we give their words even more weight.

It’s easier to trust someone we consider to be an expert, after all.

I’ve been thinking about trust lately, especially in regards to management. A former colleague of mine said she’d be interested in a management article on how to approach team members for details and updates on the cadence. My gut reaction was to go with “trust,” but I immediately questioned that.

What do I mean by trust, in this context?

I’ve worked with people who have had some experience in the industry. For example, I worked with someone who was quick to say, “I have over 12 years of experience making games like this,” as though that appeal to authority was enough to garner the trust of the team. It isn’t, however, enough. But it can be a start, in the right team environment. A statement like that can be used once or twice to get the team to give the speaker a little more time on the floor to explain a viewpoint.

An individual simply stating that they’ve expended a degree of effort over a period of time isn’t enough on its own to truly garner trust. Trust requires an investment, but that’s the wrong kind of investment. That investment means nothing to your team, because it’s done nothing for your team.

I’ve worked with people who believed that, because they had a title, they had power or authority over a department. Whether they had any actual authority was questionable, but they believed it to be so. They also believed that their authority conferred trust. What they got was compliance, and compliance is not trust.

I’ve worked with people who were quick to glad-hand and do all the “right things” per the management books out there. They would make sure the team got all the best snacks. They would take the team on outings. They would have Nerf guns delivered to the office, along with many other gewgaws and gimcracks. They were willing to close the circle, to bring it all back around, to energize the team’s momentum so that we could all achieve escape velocity together. Those people would never volunteer for a trust fall experiment, of course, because instinctively they knew their team would let them fall. Trust remained elusive, even with those who believed that — while they might not be the smartest person in the room — they were most certainly the most charismatic.

Trust doesn’t care about your charisma score. Not really.

Honestly, I think the evil geniuses with their lairs and their minions must be excellent managers. They have to have figured out the trust equation. Otherwise, why would their minions be so loyal? You don’t see the Super Friends engendering that kind of loyalty among themselves. Batman’s always going rogue. Superman is always sulking in his Fortress of Solitude. Aquaman… who cares what Aquaman is doing?

Okay, so I’m off on a tangent. Let me get back to trust.

This article started because someone in my position wanted regular updates from their team. I know how hard that can be. When I first started working as a producer, I had a very difficult time getting that information from my team. Every time the industry shifted gears — from console to web-based social to mobile — I had to fight the same fight. My team didn’t want to give me that information because they didn’t trust me. They didn’t trust me because they were scared. They were defensive. They were indignant. They thought that, because I was a manager, I must not want their success. I must want to squeeze as much as I can out of them. I must want that bottom line more than I want their peace of mind.

None of that was true, of course, but I had to earn that trust. Once I did, I would get those updates.

So what did I do?

First, I would listen. I would actively listen. I would talk to the leads. I would talk to my managers and my peers. I would keep my ear to the ground and listen, without judgment. I had to listen without judgment even when I heard things that offended or hurt me, because what I heard was a record of the experience of my co-workers. It was a record of their experience with management, their experience with development, their experience with me. They generally felt ignored or devalued by a process that had been — for the majority of their careers — legitimately dehumanizing. The validation that listening provides is, itself, incredibly valuable.

But mere catharsis isn’t enough. I would ask questions, in order to find out what they needed and what they wanted. If I could do something, I would follow through. I would write my intent down, I would loop in my peers, and I would ask those making the complaints to trust me. Sometimes, they did, and I was able to follow through. Sometimes, they didn’t. If they didn’t, they almost always apologized for their impatience after the fact. Either way, I turned their comments into actionable feedback, so that I could lay a groundwork for the trust required for a healthy team.

Second, I would communicate. I would provide information to the team. I’ve learned that you can never provide enough information to satisfy a team, and you will always receive complaints regarding the flow of information. Don’t let those comments faze you. Communicate in a way that works best for your team. Be fair and neutral in your language. Share in a way that sets the tone for the professional communications you want to have with your team. Demonstrate that you’re not immune to the processes that the team has agreed to follow. Emphasize that these are processes that the team has agreed to follow.

If someone habitually doesn’t share their progress, their problems, their pace, it is important to remind them that they did, in fact, agree to the process. They may argue that they didn’t agree explicitly to that, but by participating on the team, they have implicitly agreed to play by the team’s rules. If they have OKRs and KPIs, then they are already playing by those rules. They cannot pick and choose which rules to follow. Their agreement to play by those rules is a professional promise. Hold them to their promise.

Let their leads know that they will be held to that standard. Let them all know that you are also held to that same standard. If they don’t like that process, it is okay to talk about it. It’s okay to try to amend the process. The process must serve the team, after all. But it is important to own and drive that conversation.

Core communication on any project is required. The project’s status — completed tasks, blockers, and other issues — must be shared and updated regularly, if the project is to continue smoothly. This is true no matter what production paradigm is in place. Failing to communicate will disrupt the project, which can result in a cascading failure that affects the very livelihood of the team.

That last statement may seem like hyperbole, but — please take it from someone who has seen a studio shut down this year — it truly is not.

Third, get the team to commit. People generally want to appear as though they are consistent, that they are trustworthy. If you need an individual commitment, reach out to that person through email and loop in their lead. Get an initial delivery estimate from the team member. Create a ticket in your preferred project software, and share that ticket. Then, trust that the work will be done. It’s acceptable to check in at the 60% point for a short task, and at the 40% and 70% points for a longer task.

Team members should provide updates on their tickets every day, but this escapes some people. Daily burndowns should be shared with the team, with department breakdowns in those charts. Team members with excessive numbers of open tickets should be mentioned in your leads meetings, not to condemn the team members but to elevate the project risk. Ask if production has overloaded the team or approved inaccurate costing estimates. Ask if you can help by redistributing tasks. Offer a triage. Accept responsibility and reach out. Let your approach come out of a desire to help the team hit the target on time and on budget.

When they follow through, thank them in a genuine way, with genuine gratitude, no more and no less. If they fail to follow through, remind them of their obligation and recalculate the time to completion. If they continue to fail, move on without them. As a manager, you should have a contingency plan for getting what you need. They will feel the weight of their failed obligation, and most will not repeat their mistakes.

Fourth, remain consistent. As part of that commitment process, I was keen to praise people publicly when they succeeded and to counsel them privately if they failed. I would let the team celebrate successes, and I would be clear that the production team owned the failures. Throughout all of this, I would strive to keep my actions consistent.

Another aspect of consistency is avoiding favorites and blame targets. No one can be a “favored” team member, nor can anyone become the blame target for a project. We are blind to the failings of our favorites. We are blind to the successes of our blame targets. We cannot afford institutional blindness, if our teams are to survive. Be consistent in how you treat your team. Be fair in your judgment, as frustrating as that might be for your and your team, and you will earn an unwavering trust.

Active listening, communication, commitment, and consistency. These four “soft skills” were at the heart of building the trust I needed, so that I could help the team move forward effectively. It took a lot of time and effort to build that trust, but it was always worth it. I experienced a couple of times where a manager above me in the chain of command destroyed that trust in an instant, and I would have to rebuild it again. Still, it was worth it.

It’s hard to admit that you may not have the trust of your team. It can hurt. It can feel unjust. And still, it is necessary to build that trust in order to move forward. Trust is powerful, and so managers and leaders lust after it. They covet it. They believe they deserve it. But trust is delicate. It must be tended and nurtured, if it is to take root and thrive.

People want to feel valued. They want to feel included. They want to feel as though they’re participants. They only truly feel like that in an environment that values trust between management and the development team.

Once you have that, you can institute a process or procedure with relative ease. This can be as simple as, “I’d like for everyone to send me an end-of-day email with what they accomplished today.” This can be as complex as, “I’d like to shift our development style from Scrum to Kanban over the next quarter.”

If you have the trust of your team, you can accomplish anything.