I'm not talking about annual reviews (which are stupid). I'm talking about how you work as a client for a project that needs to make something.

It might be an internal team developing a website or it might be an outside designer working on a logo. Regardless of the team's make up, as their client, you walk a fine line. On one hand, you want their best, most creative insight, delivered with passion. On the other, you want the people you represent (your boss, the customers) to be happy with what gets made.

Which leads to the feedback part. (Not criticism, feedback).

What do you do when the work that comes in is no good? When it's off target or needs tweaking or even an overhaul?

In my experience, there are three different ways to structure the project. Each leads to a very different feedback loop.

1. The goal of the team is to please you.

2. The goal of the team is to make a product that they love and are proud of building.

3. The goal of the team is to build a great product.

There's more difference between #2 and #3 than it appears.

The first scenario is quite common. It leads to mindreader syndrome, in which alert team members work hard to get you to tell them what you want. If they can read your mind, they'll be successful (and done) that much sooner. The real problem with this approach is that the team has rarely bought in to the project. They don't take ownership because, after all, the goal is to make you happy. They won't give you more than you expect, because they're trying so hard to give you exactly what you expect. This is especially problematic when the team thinks you're an erratic, egomaniacal nutcase with little or no real world chops.

The second scenario is common with well-known freelance help, or agencies or other creatives that bring ego to the table. In this situation, anything you say about the project appears to be a personal attack. That's because, in the eyes of the person that came to you saying, "here is our work," it is a personal attack. If you don't like my logo or strategy or code, well, of course I'm going to be defensive.

You can work with people like this successfully, but to do so involves giving them a clean sheet of paper, not being part of the development process.

The third scenario is the one in which all sides want the best possible project and the team believes that you have valuable insight on how to make that happen. This only works if there's mutual respect around the table. They have to hold you in esteem and trust your judgment (not organizational judgment, but judgment about what makes the project great). That means that, "because I said so," is not effective feedback.

I've seen all three work. The first scenario is really efficient if you are truly in charge, you know what you want and you don't have a lot of time. The second scenario works if you absolutely trust the team and want them to push the envelope. And the third scenario works when you have mature people, a dedicated team and enough time and mutual respect to work it through.

How do you develop the trust and esteem you need in the third example? Sit with the team and jointly criticize other work. Before you start developing, spend time giviing feedback on how someone else could have done a better job (on a design, on the foley in a movie, on a logo). By earning the right to give feedback externally, you make it more likely you've got the right to do it internally.