"So, does anyone have anything they want to share with the team?" The room stays silent. You let it sit long enough that people start to squirm, but no one jumps in. This is the second meeting in a row where this happened. You know people are moving forward in their projects, so it is odd that no one wants to share any positive updates. Of course, you have lots to share with the team. So, you begin telling them about the big contract that the company landed last week and how it will shape the roadmap moving forward. Heads are nodding, but the energy seems off. Was there an issue you missed? You'll have to do some digging after the meeting. You run through the rest of your agenda and the meeting adjourns.
As you reach your office, Dave follows you in. "Mike is leaving," he says bluntly. He spends the next 10 minutes explaining what Mike has said and why he thinks he is leaving. He ends by slipping in "The team is feeling very stifled, and that is something Mike brought up too." You thank him for his candidness and give him the direction he needs to keep the team moving forward. Is this why no one wanted to speak up this morning? What about last week? Something is going seriously wrong and you need to find out why. Most engineering leaders in this situation will try to look for answers in the team dynamics. They might look at the manager and see if anything he or she is doing has caused this feeling of being stifled. They might chalk it up to the fact that the team is firefighting more often than they would like to admit. These are all important areas to investigate. However, there is often a deeper problem: you don't value truth telling. Or at a minimum, you don't act like you value it.
You are too worried about your reputation. You are too worried about what the board will think if engineers speak freely. You are too worried about others having visibility into the gaps in the system. You are scared of what will happen if the truth gets out. You might have tried to work against this instinct. And good for you for doing so. That means something. You ask the team to freely communicate their issues. You make sure they are all doing retrospectives at the end of the sprint cycle. You have defined and regularly reference your OKRs, so that the team knows exactly what you expect of them. But even if these policies are in place, stating you value truth telling is often not enough. On top of this, your actions might also be contradicting your words.
Every time you push hard to get a new feature done, but neglect testing, you are saying truth telling doesn't matter. Whether you forgot, underestimated, or actively chose to forgo sufficient testing and validation, you are pushing the narrative that finding out the truth of how the system works isn't important to you. Testing and validation are truth-seeking activities. The people who do them the best are truth tellers by nature. How you hire for this trait, and how you promote their viewpoints in the business, says a lot about how much you value truth seeking.
Ever have an engineer throw a very outside-the-box idea to the team? Of course, sometimes it isn't a very good one, and shouldn't be moved forward. However, sometimes it is a very good idea that reveals a truth. The truth may be that you didn't think of it and now you're upset about it. The truth might be that you like it, but it lies in opposition to the company's stated values. The truth could be that your internal models are antiquated. Either way, how you handle these ideas is going to set a culture for how the team thinks about solutions. If this engineer is dismissed and it is a genuinely good idea, you may never hear from that engineer again. Other team members will hear about how it was handled and stop sharing insights too.
Some engineering leaders like to control how their engineers behave in front of customers, sometimes to the point of not letting engineers join sales or customer calls. That right there shows a lack of trust. And that concern is almost always rooted in the idea that the engineer might tell the truth about your product or service. If you are worried you will have to reprimand your team for stating limitations of your system to customers, you are sending a very big signal that you don't value truthful interactions between the people who build your system and the people who use it.
I've seen organizations where the team has created dashboards to better observe the system or the business. However, the access to it is limited to only certain engineers or stakeholders. This instills a sentiment in your team that they aren't trusted. It tells them you fear that they will find out the truth about the system or business, and share it. It breeds a culture of omission and lying that will inevitably spread across the organization.
Solid performance criteria and career growth paths can facilitate a culture of open and honest communication. The absence of these leaves your team with a sense that truth isn't at the heart of evaluating performance. I mean, why else would you make the criteria vague? Employees can only naturally infer that this is so you can hide the truth behind vague feedback and criteria, whether that was your intention or not. If your intention was to use this to shield employees from critical feedback, you are demonstrating you don't value the truth. If you are using vagueness to shield the company from giving the raises and promotions the employees are due, you are also not holding the truth paramount.
The problem is that the truth will always come out. Stifling people may slow it down, but eventually it will come out in ways that are more damaging. The last thing you want as a leader is to be viewed as a barrier to the truth. It will destroy the trust and credibility that you worked so hard to build.
So, hire truth tellers. Give them professional guardrails, and let them speak freely. Because every time you make truth telling unsafe, you don't stop the truth. You delay it. And it doesn't come back quietly. It shows up in an outage, a resignation letter, or a question from the board you can't answer.