Most products are designed and built by a team. Small, big, dysfunctional or high functioning teams, but some form of team none the less. Having built products for over 20 years I have found the single biggest factor in a product’s success is how much collective trust there is within a team..
This does not mean that great teams automatically make great products and services. Plenty of ideas out there are too early, too complicated, lack general infrastructure, or are just downright terrible, even though high performing teams are working on them as we speak. These things will most likely fail in the marketplace regardless of the team. From my own experience on failed projects, I can list the Sega Dreamcast (too early), Nokia N-Gage (too early, terrible execution, lack of general infrastructure, etc.). But, the teams of these products were some of the best I have worked with and many people from those teams have gone on to do amazing things in their line of work.
What then makes a good team great? You need a group of high intellectual horsepower, strong emotional intelligence, and the correct distribution of skills necessary for the challenges you are tackling. I would argue all of that is very nice but even with all that in place, the primary limiting factor of a team’s performance is trust.
This is not a new idea; you can read many current articles about this such as Google’s study on effective teams or the article on Medium - The Future Of Labor is Working With People You Trust. Shoot, Stephen Covey wrote about this back in 2006 in The Speed of Trust: The One Thing That Changes Everything. What I find so amazing is that so many people seem to be aware of this, but at the same time, they don’t take systematic steps to do anything about it.
Let’s break it down a bit.
When I say teams move at the speed of trust, I don’t mean that in a metaphorical way, but in a real function of time and action. Think of the relationship of a manager to an individual contributor. If the manager does not trust the person to do good work, finish on time, meet specifications, etc., then the manager will invariably become a micromanaging boss, literally slowing things down from a lack of trust.
Let’s look at it from the opposite side, the poor person working for a boss they don’t trust. If you don’t trust your boss, you often hedge your work, not knowing what is needed or expected. Even worse, maybe you don’t believe your boss to represent your work or give you credit for your accomplishments, then you make sure that you don’t produce your best work, knowing they will take all the credit.
How about something less personal. A team that doesn’t trust in the mission of the project. A healthy reaction would be to question why. Why adhere to the vision? Why is this path going to lead to success? Why don’t we change course? That, of course, costs time and lots of it, especially on larger teams, and that is the healthy reaction to the problem. The unhealthy response is leadership that stifles dissent and ignores challenges to the vision, creating even higher costs in time as people disengage, go off on their own or leave, in pursuit of something better.
So if trust is so important, why are these examples of lack of trust so prevalent? Why don’t companies work hard to put in systematic processes to engender trust within and across teams? Because it is easier to believe in the fallacy that making a great product happens because of a single individual creative visionary. This ignores the undeniable reality that a great product is made by people, people who need to trust one another, trust the vision and trust they can actually get there if they are to perform at their best.
Ok, so what are some ways we can systematically build trust in our teams? There are lots of ways to go about this, from Stephen Covey’s, 13 Behaviors of High Trust to Forbes 12 Leadership Behaviors That Build Team Trust, but here I will outline my version of these based on specific examples during my career.
At a very base level, humans are animals that have evolved to believe what we see and distrust or fear what we can not see. Without transparency, the unknowns (gossip) expand and fill the void that should have been filled by near full transparency of information. I say, “near full” because there are things like payroll, performance reviews, etc., that should not be made public across a team. Ways to implement transparency:
Reporting up and out. While on The Sims Mobile team, we had a bi-weekly executive review of the performance of the game, key metrics, roadmap, velocity, etc. Usually, these sorts of decks were created by the leadership team and only shared with executive level stakeholders. Instead, we shared these decks across the entire team making sure the full team had access to not only all the information that was presented upwards but all the feedback we received on this material. This way the team was never guessing what was shown or where we stood on matters of metrics, priorities, milestones, etc., instead there was a single source of truth that they had equal access to.
Out in the open. Sit out in the open, in the largest grouping of team members, and sit in such a way that anyone can see your computer screen. It may sound simple, and it is, but I have found many team members respect and value this action. One, it is always clear what you are working on and encourages people to walk up and ask you a question about anything they see. Now clearly there are times when you need to work on things in private, and for those rare times, merely find a conference room, but spend the vast majority of your time out in the open available to your team. This is also part of leading by example. People trust others who are consistent in their actions and statements.
I hate speaking in absolutes, but pretty much, no matter how much you communicate, it is probably not enough. Nearly every problem on a project, within a team, or in a relationship, can be walked back to a breakdown in communication. Something was not communicated, it was communicated wrong, things were assumed, etc. I like to say communication needs the three C’s - Constant, consistent and constructive. Missing any one of those turns good communication into useless chatter.
Constant. Two typical examples that lack the principle of Constant, are only communicating good news, in a weak attempt to keep morale high, or just communicating bad news, often because you failed to communicate anything at all and now you are forced to say something. It takes discipline, but find a frequency, (no less than weekly), to communicate with your whole team. It can be via email, Slack, team meetings, agile standups, or even better, all of the above. Never fail to miss one of these communication updates.
Consistent. After setting up the frequency, be consistent in time (for example always on Monday morning), place (email, face-to-face, etc.) and structure. From my experience, I like a weekly format, over email, first thing Monday morning to the full team. The structure will always include the following - critical announcements, top priorities for the project, key milestones/dates, agenda for the leads meeting (and expected outcomes), open requests for feedback and finally an image of awesome. This last part is similar to a prize the box of cereal, encouraging anyone viewing the email to open it and ideally read the full thing.
Constructive. This one is the toughest because it requires the most judgment. The best heuristic I have found for meeting the criteria of constructive is to make my communication actionable. If it is good news, don’t just say, “nice work” instead, communicate how to apply the success again in the future or how to use that success to address other problems. If it is bad news or more often critical feedback needed for a team member, again, make it actionable. What is the behavior that is required or expected? Build your communication around how a person or team can take action towards improvement.
This one is so key to building trust on a team I am surprised it is not discussed more often. It is the simple act of taking the implicit and making it explicit. On any given project, multiple times a day you will be confronted by the opportunity to calibrate with your team, building trust each time you apply this rule. Examples:
Approvals. As a leader, you are often asked for your approval on something. It could be a process, designs, budgets, etc., but instead of merely giving yes or no answers, (if possible), take the time to make an explicit calibration. This means saying something to the effect of, “This looks great and in the future any cost expenditures in this range, related to this aspect, you can go ahead and automatically approve.” This one simple change can dramatically improve a team’s operational speed. It is not always as clear-cut as my example, but take the time to ask yourself, can I calibrate on this or not?
Opinions. Similar to approvals, but more subjective, take the time to set a calibration marker for your team. For example, you are shown a wireframe mock-up of a new UI, instead of just offering your subjective opinion, try to find pieces that you can isolate and set calibration on. It can be based on existing UX patterns, brand colors, key art or characters that should be used, etc. The point is to set a loose standard or heuristic, that a team member can use to make future decisions about without checking in every time.
This can encompass all sorts of things that are often brought up when discussing building trust. Things like, “Listen First,” “Admit your mistakes and acknowledge your limitations,” “Ask for feedback,” “Put the success of the team before your own,” etc. For me, I wrap all of the above into the umbrella of humility.
In the short term, it is easy to trust a braggart who claims to know all the answers and attempts to remove all doubt about direction or purpose, but never have I seen people like this create a sustainable future. The world is way too complex and ever-changing for any singular person to be right 100% of the time. Building trust in your team is also trusting them that they may know something you don’t or have a better way of doing something. You are building trust twice as fast when you allow the team an open opportunity to shape the future of the project, process or vision.
In no way do I believe the above is an exhaustive or a fully comprehensive list, but it should be a good start, with real actions you can take today to improve trust in your teams. Implementing just a few of these practices will go a long ways toward improving your team’s speed and productivity regardless of the type of work you are doing. As Matthew Inman from The Oatmeal sums up, ...