If I’m honest, I (like many of us) have spent way too much of my personal and professional life worrying about being “found out.” I’ll bet you have experienced it yourself. There are countless examples that come to mind.

“I got a bad grade on a test.”

“I forgot to take the dog out.”

“I didn’t get that promotion.”

“I made a mess of the software I designed.”

“I’m on track to overrun my budget.”

“I made a hiring mistake and haven’t had the courage to resolve the problems it has created.”

The list goes on. We all face these issues in our lives — and they don’t only impact us. They impact our teams. Most of us collaborate each day, and we depend on our colleagues in countless ways. When an issue arises as part of a team, it’s a shared problem, even if you’re the only one who knows about it. And if we all share in the problem, then maybe others have the key to help us resolve it. In the very least, we all need to be on the same page about what our biggest issues are, so we can collectively focus on solving those “big, hairy problems.”

Unfortunately, it doesn’t always seem to work that way. It’s all too common for us to be afraid to admit we’re facing a problem with a project. We fear revealing that we are less than perfect.  We fear that admitting to the issue will negatively impact our review, compensation, or promotion. In short, better to not talk about it.

The net result is that things almost always get worse. We’ve all heard the old adage that “Bad news doesn’t get better with age.” I have learned throughout my career that software and system development problems don’t solve themselves. Things on a bad trend tend to accelerate more often than they resolve themselves.

This culture of not sharing bad news can permeate an organization quickly. If left to fester, it can impact the organization’s ability to adapt as new issues present themselves. It prevents us from seeing the key issues, and it prevents us from leveraging the organization’s collective expertise to solve the problem. It can also severely damage the reputation of the organization when the truth finally comes out and the project must slip. The later we wait, the worse the damage is. The worst case occurs when a massive schedule slip happens just before the ship date. In this case, the customers and stakeholders have made plans that depend on the product being available, and everyone wonders about the quality of an organization that couldn’t see the slip coming earlier.

The close cousin to holding back on raising issues (which also happens way too often) is deflecting the problem to someone else. A release is delayed because we were waiting on specs or feature prioritizations from the stakeholder. A subsystem isn’t performing because we successfully pass the required data to another subsystem, and nothing comes back. A crash isn’t our fault because we traced it to a piece of code that we don’t own, and we alerted the team about their bug. What we forget is that the details don’t matter — we have a problem as a team, and we need to solve it as a team. If we truly operate as a team, these are all “our” problems, not “their” problems.

At VA, we’ve adopted a mantra of “Embrace the Red.” This means that rather than hide issues from the rest of the team, we encourage people to bring them forward, so we can solve them together. Alan Mulally, the retired CEO of Ford Motor Company and former Senior Vice President of Boeing, talks often about how this was a critical part of the culture transformation when he took the helm at Ford.

While it’s a simple concept, it can be hard in practice. All of us must feel confident that we aren’t going to be unfairly penalized for bringing forward a problem. It’s practically become a cliché by now that great organizations “embrace” or “tolerate” failure, but it’s true — without the psychological safety to make mistakes, we risk the greater danger of not taking action.

So how does this play out in our organization?

  • If we mess up, we own it, and we’re not concerned to tell others that we did. We say things like “we did this one to ourselves” or “we have some process work to do here.”  We acknowledge the error and move immediately to a discussion about how we remediate the problem and ensure it doesn’t happen in the future.
  • We’re constantly looking for places where we don’t seem to be tracking against our plans, and we flag those for our teams and for leadership, so we can figure out what we need to do to get back on track. We figure out how to best communicate the issue to our stakeholders and work with them to adjust their plans as needed.
  • As leaders, we don’t judge people for bringing up a difficult issue. We praise the transparency.
  • Everyone involved in an issue takes ownership for the whole problem, even if our particular responsibility is more limited. We reach out to others when we think we can help to solve the problem. We don’t consider our work on the problem to be done when we point to another person as responsible. In the end, all that matters is that the problem is solved, and problems are most often best solved as a team.
  • We have the same expectations of our contractors. We expect them to build plans that minimize risks, but we also expect them to be constantly vigilant in looking for places where our work is off course and to alert people to these issues. We evaluate contractors based on the overall sum of their work with us, not a particular incident.  Incidents will happen. What matters is what gets accomplished — and at what cost.

It’s important to remember that this way of working doesn’t end when the product or project leaves our hands. We must ensure that we don’t let it drop when it leaves our shop. Just as we have embraced the red within our organization, we should encourage others to do the same. By taking responsibility, practicing empathy, and creating the conditions in which this way of working becomes our cultural norm, we can foster a culture of transparency, collaboration, and continuous improvement.

Let’s embrace the red together and create an environment where we can openly address challenges, learn from our mistakes, and collectively work towards solutions. Together, we can build a stronger, more resilient organization that thrives on shared problem-solving and growth.

Part 8. Our teams are, by nature, part full-time government employees and part contractors.
Part 10 – The Case Against “Rip and Replace”

Continue reading