Why Your Project Team Sucks: Part 1 The Trust Gap

There I am, sitting at my desk Tuesday morning. I have a meeting with a prospective client; a company that is looking to build a functioning project team to handle its internal systems. The owner states that for a long time, the company had paid a couple of high school students to create their software. If they were to grow beyond their small regional company, they would need to focus on getting this whole project organization right.

There’s a single line in the email that stands out that is leaving me a bit distressed: “I can’t seem to get the developers to do what I want them to do.”

I can only rationalize that they are building a Lego: A Clockwork Orange game and the owner thinks that genre is played out, and would rather them build him a sales/CRM system instead.

The meeting starts, the Cliff’s Notes version is:

• The owner paid high school students to build a sales/CRM system, but it was slow and was limited to about a thousand entries before it started to have issues

• He hires a group of professional developers to build a proper sales/CRM system

• The pandemic hits, and everyone starts working from home

• Cycle time takes a serious hit, and productivity metrics plummet

• Thinking the workers are now stealing time, he doubles their workload

• When things don’t change, he fires the lead developer to establish dominance (something he claims to have learned from CEO magazine)

I then reached out to the developers, to get their side of the story:

• While in the office, the work being completed was all cosmetic, so deployments came fast and frequent, but since then, application core and backend work is being completed, which takes longer

• The work being done is updating code from Java to JavaScript, which poses unique issues that are slowing down the work

• The existing code is “an angel’s breath away from catastrophic failure”, which is requiring extensive work to get even the simplest code out the door.

• The dev with the most tenure has only been on the team for about three months (the owner did not know this, he thought he had the same people since the beginning (three years prior)

The owner’s response was to call them liars, manipulators, gas lighters, and thieves. So, there’s clearly a breakdown in trust.

Discussing this with fellow PMs, the consensus is that you can’t just let a dev team off the leash and trust that they’ll actually do the work needed. Trust, after all, is earned, not given.

This old adage is bullshit.

You’re not being asked to immediately trust your employees to house-sit while you are touring ghost towns throughout the US, so you'll need them to take care of your diabetic tortoise that requires you to sing Sheryl Crow’s “All I Wanna Do” every night in a minor key or it’ll die. You’re just being asked to trust that the person you hired isn’t a total flake.

The first reason why your project team sucks: your lack of trust and insistence on micromanaging your team.

Yes. Yes you are.

Extremely simplified, there are two competing philosophies in regard to trust: the rational view, which is inherently self-centered/a way of protecting interests, and the social perspective, which views trust as a vehicle that establishes commitment by way of moral duty. There are nuances in these philosophies that I won’t explore them since it involves discussion of what amounts to rap-battles of angry academics (“your research is so old, it was performed when the Dead Sea was just getting sick,” “your sample population is such a mess, even Fix-It Felix said he couldn’t fix it”).

Even though neither philosophy expressly states it, they both suggest that trust is something that is built over time and is dyadic in nature.

This… is… bullshit.

There is enough research that suggests that when formed, project teams demonstrate high levels of trust at the outset; suggesting that trust isn’t something that is built, but something that is lost. Most attempts to discredit this research center around redefining what trust is, but again, we’re not talking about trusting the 16-year-old new hire with your brand-new Mustang California edition, we’re talking about allowing the person who (ideally) was vetted during the hiring process to do their job.

So, team members begin their membership with a level of trust, and managers begin with a lack of trust? What gives? I believe that the reason is narcissism. From the perspective of a team member, there is a belief that the other team members will be as qualified, if not better than they are (since it follows that if they were selected for the team, and clearly qualified, others also know what they are doing). Whereas the manager sees the team as being subordinate, and therefore of questionable merit.

So, it’s hopeless? Thanks for coming to my Ted-Rant.

Not quite.

Here is my clickbaity solution. Five ways to increase project team trust (number four should be common fucking sense)!

1) Take time at the beginning of the project to encourage socializing among all team members. How does this relate to manager/team member trust? This socialization builds team cohesiveness and should be the focus of a project team from the outset. During this “getting to know you” session, team members learn who has expertise in what area, it breaks down the walls that would limit member-to-member communication and sets a foundation for a team that is comfortable working with each other. The best part? The PM is central to this process, allowing them to see the strengths within the team, and put their mind at ease when it comes to potential gaps in knowledge. It further provides a fertile time to establish the norms/ideologies that are part of your team, and the objectives set before them.

While we’re talking about encouraging socializing…

2) Continually encourage socializing. You spend all this time at the beginning to build cohesiveness, why would you let it die out? You have to maintain that shit. The rule of thumb that was taught to me, was the 80/20 rule. 80% of your workday should be work and 20% socializing.

I can hear you now… “but… but… that’s time theft!”

Look, socializing at work creates a more relaxed environment where employees feel less like they are just “at work”, builds comfort and trust among coworkers, and (most importantly) allows team members to get distracting thoughts out of their heads. The way I see it, eight hours a week dedicated to maintaining your team’s mental health in a way that also makes them more productive is a lot cheaper than paying to replace them (especially when considering the learning curve that is inevitable when bringing in new members).

How does this relate to trust? Well, it counters the attitude that my potential client had; productivity falls, better increase the workload to ensure they always have something to do. It’s a small step that demonstrates to your team that you trust them enough to get their work done, while still feeling respected in their role.

3) Decentralize decision-making. I can’t believe this has to be said, nor that it is controversial in many PM circles. Allow me to express how incredibly stupid not following this is. You’re a PM. You have detailed knowledge about all things Agile, EVM, WBS, AoA vs AoN, CCS, IMP, IMS, IRR, SLAs, KPIs, holy shit-snacks you are one knowledgeable son-of-a-bitch (argh, I should have said SoB and continued with the initialism trend). Why wouldn’t you dictate what your developers do, even though you have no clue what the difference between a for and a while loop, why bit and bool are different (or what that even means), and why using a negative condition in your IF loop is a bad practice… but you still feel like you should be the central, dictatorial decision maker. Do you hear how dumb that sounds? What’s worse, is your team members are selected because of their specialized knowledge, but you don’t trust them enough to make decisions when needed.

Again, you aren’t being asked to trust them with deciding on the name of your firstborn child, you’re being asked to trust that they will act in the best way possible, based on their specialized knowledge.

4) Create a psychologically safe environment. My favorite definition of a psychologically safe environment comes from H. Lee’s article about changes in the workplace, Lee states that “psychological safety is a freedom of self-expression without fear of negative consequences to self-image, status, or career, which lead to higher feelings of autonomy and a source of pride.” This isn’t about establishing an open-door policy (open-door policies are never truly open doors and are frequently poorly implemented/bad policies).

This is establishing an environment that encourages informal, honest, innovative communication, it increases autonomy, and trust, and produces a team who feels less stressed, less anxious, and less like they are disposable. This means not firing someone to establish dominance, Kevin!

It should be noted that this is the first time that we’re discussing the nature of trust being a two-way street. We are creating a safe space for informal communication so that we can encourage the team members to trust us. Which would you rather have:

• A team that is so afraid of you that they blindly follow what you say, even if that means lying about progress or concerns that have arisen during the work or

• A team that is comfortable enough to express the issues that are slowing down progress, therefore providing you with a clearer and more robust idea of the progress of the project.

Should be a no-brainer, right? Unfortunately, it isn’t, and the reason relates to:

5) Power distance and perceived proximity. Power distance relates to the perception of the power distribution of a team. High power distance is more accepting of an unequal distribution of power, whereas low power distance will readily question the distribution of authority, and tend to expect to participate in decisions that affect the team.

This is very much cultural.

Decreasing power distance isn’t about making all decisions democratic. It’s about taking the time to ask for the insight of your team members. It’s about giving those who need a seat at the table space to offer input. It allows for an organizational culture that encourages one to speak their mind in a productive and safe way (back to creating a psychologically safe environment). You have to trust that your dev saying you’re being dumb by ignoring the potential risks and that they aren’t doing it because they have a grudge against you.

I also mention perceived proximity. Perceived proximity is a concept that applies to dispersed teams, it is the view of how close or far an individual is from others (one could be continents apart, but still feel close in proximity, weird, right?). In my experience, managers use team dispersion as a way to increase power distance. They encourage team members to isolate themselves so that power can be centralized, such that, team members are not comfortable speaking up when concerns arise, and decisions aren’t questioned.

A low power distance and high perceived proximity are the results of a healthy trusting relationship between manager and team member. It is the result of the previous four points made.

How does this apply to my potential client? Well… I would like to be positive and think that he has the ability to turn around this team and build a productive relationship with his dev team. However, it goes back to the belief that trust is earned. He’s destroyed any trust that might have existed among his staff, and now he has to earn it back.

But it didn’t have to be this way. By capitalizing on the initial trust that is found among newly formed teams, and doing everything possible to maintain and build it, he wouldn’t have to be worried that they are finalizing the Lego version of the Korova Milk Bar.