We often hear requests for private issues or comments. However, for most teams the underlying reasons that private issues sound handy are the very reasons private issues are problematic. We usually hear three reasons teams want private issues:

1. So that clients don’t unnecessarily see “mistakes”.
2. To help focus clients by shielding them from technical bits.
3. To create an internal backchannel.

Let’s dive deeper into how these goals can backfire and harm a project more than they help.

Hiding “Mistakes”

Some teems feel that bugs that they discover internally make them look sloppy or error-prone if viewed by clients and prefer to hide these from clients entirely. However, the idea that presenting a nice clean front will convince the client your team is a flawless machine is like trying to make unicorns out of rhinos.

The more likely outcome is that clients can’t see much of what you’re working on and end up feeling like you aren’t actually working. Or they might think you’re simply ignoring the issues that they’ve reported. If your highest priority work is all in private issues the client is cut off from the development process and will never get the bigger picture view. This can lead to a variety of communication and expectation problems.

Remember that the work isn’t about your image, it’s about the client and what they want. Assuming you’re ultimately doing quality work, your image isn’t going to suffer just because you’re doing that work in front of the client, warts and all. Rhinos have one huge evolutionary advantage over unicorns – they’re real.

Keeping issues private to protect your image ends up skewing expectations the wrong way and can easily end up doing far more damage to your reputation with the client than showing them a few more bugs in the software you’re developing.

Shielding Clients from Technical Bits

Another reason some teams want private issues is related, but slightly different–they want to shield the client from the technical stuff so they don’t get distracted from the bigger picture.

This is indeed tempting, especially with the sort of client that likes to be involved in every step of the development process whether their input is needed or not. It’s tempting, when faced with this sort of client, to resort to using private issues as a way of avoiding conflict or confusion.

However, as noted above, using private issues to make your development process partly or wholly opaque to the client is just as likely to make your client want to step in and micromanage as it is to prevent them from being able to do so.

The problem is that you’re trying to solve a human problem with software, and that’s never going to work. If your client is “in the way” then it’s best to help them understand what they’re doing and how they can do it better. If they’re not participating because issue tracking feels too technical, then a better solution is to invest time in helping your clients understand issue tracking.

Even with clients that don’t micromanage it can be tempting to use private issue to shield the client from technical details you don’t want to explain. But clients don’t have to (and aren’t interested in) digging into things not assigned to or related to them. People are great at tuning things out and they will if you give them the chance.

An Internal Backchannel

The third purpose that we’ve seen driving requests for private issues is that they serve as a kind of internal backchannel, a place your developers can discuss things without worrying that the client is watching. This is the most potentially disastrous way to use private issues. If the history of the internet has taught us anything it’s that “private” is rarely actually private.

Backchannels backfire. Private conversations end up public. Clients get to see what your developers are saying in private and the results are often ugly. Backchannels also undermine a sense of collaboration by creating an environment in which not all speech is equal. The client has no say in the backchannel and never gets a chance to contribute to that portion of the project. This further creates a divide or an Us. vs. Them mentality. Even if private conversations are never accidentally made public, it can undermine the collaborative spirit of projects.

It’s important to involve clients in the big picture and let them get as involved as they want to be. Private issues subvert this from the outset by setting up an us vs. them mentality that percolates out into other areas of development as well. The real challenge is not keeping clients separate, but getting them involved, and setting up fences and other tactics to prevent them from being fully integrated into the project hinders collaboration and produces sub-par work.