Well, that depends on how you run the critique sessions, or if you run them at all.

The past few critique sessions I’ve been involved in have been more of a Q&A. Before the critique starts, you set a few rules... The main one being this: you are only allowed to ask questions about the design, not make statements or offer solutions. This eliminates the risk of someone saying ‘I don’t like blue’ or ‘you should do this’ and instead opens a discussion around specific parts of the design.

The fact we have to answer the questions means the person giving critique either needs to hear the rationale, understand it, and accept it, or we need to admit defeat because we have no rationale for that specific decision.

It sounds pie-in-the-sky, but it works so well, and feels more collaborative than the throw it over the fence technique I see used far too often.

The shit-eating grin on the right-most guy is hilarious.

And you didn't put it into your contract that "we don't do design by committee?" For shame, sir.

Okay, so you can make this work for you. The key is that you have to insist you be involved in the design meetings: call in if you have to. If the boss objects, say "So I can be sure to really understand the suggestions being made, and get a chance to ask the right questions while ideas are still fresh." Make it about increasing your utility and value.

Your best friend in these discussions is the question: "Why?"

Whenever someone suggests something that seems off, ask them why. Make them explain the idea. Compare it to their goals, delay if you need to do research. Talk in terms of tradeoffs instead of "good vs. bad". They might be totally crazy, or they might understand their customers in a way you don't.

When suggestions come up, control the situation. When there are good ideas, embrace them. When they have neat ideas that aren't practical, challenge them to find a way to accomplish the same thing under real-world constraints. Offer to work with them because their idea is good. Treat them like smart problem-solving people.

If you treat them as smart and engage them, they'll actually contribute value. If you treat them as dumb, you'll have to fight them.

Only a nightmare if you make it one! I suggest you read 'design is a job' if you haven't already, there are a lot of good pointers on this exact predicament. http://www.abookapart.com/products/design-is-a-job!

Here I thought it was, "You do HTML Emails right?".

Actually it is proven that co-creation/ideation workshops with the client helps achieving a way better user/consumer centered approach and overall better design and experience solutions. Not to mention, that involving the client in the process on early stages but still in a "capped" way, makes your client increase the "trust factor", which really helps for not having the client on your neck all the time.

If by saying "participating in the design process" you actually talk about a stubborn client scheduling design review for every icon you create, than this is a part you have to anchor in the contract in advance.

It is crucial scheduling the design review, internal ones and external ones, on critical points in design process, in order to foresee upcoming obstacles or challenges.

Wow, I wish I worked in a company where everyone was interested in a design process.

I actually ran through some design exercises with a whole team of VPs and "non-creatives" (Ugh, I cringed as I wrote that) a couple months ago as we were working on rebranding. I used this post by Brad Frost as a guide. It was incredibly helpful, everyone enjoyed it and felt like they were a part of the process.

Ultimately it's up to you being an expert in the field, but that doesn't mean you're the only one with good ideas. It doesn't mean you have to follow what comes out from it, but I don't think it's ever bad to get other perspectives. The sooner you can get buy in from other people, the easier the job is going to be in the end.

One great way to control this process is to involve those dozens or hundreds of stakeholders in your research process to help you mine crucial information that will aid the design process. This information doesn't have to dictate it though.

We involve hundreds of stakeholders in our research processes sometimes, and it actually serves us well since we're constraining our research process to a few activities and site visits. However, the core stakeholders follow us all along the way and provide us with excellent feedback through wireframing and visual design phases.

I'm sure there are ways you can convince executive management within said companies to limit the amount of people who are directly involved and make them feel like they contributed something valuable.

It's a fine line, and there's nothing wrong with gracefully defending the design process you and your team works best with. After all, you're the experts.

Decision maker.

In your contract, add a clause about the decision maker. Make one person be in charge of all communication to you and responsible for making decisions. Nobody else. Also, define the maximum number of people who are allowed to work on the team.

Obviously this advice is in retrospect. For the current moment if it's still possible, don't be afraid to be aggressive about saying "I'll only work with two of you." You're being hired as a professional, not a babysitter. Define how many people you need to get your job done and cap it at that. Control the relationship.

Here's a pep talk from cap'n Steve on how Paul Rand handled him: https://www.youtube.com/watch?v=xb8idEf-Iak.

Edit: I should say that you don't want to be mean about it. What you're looking for is a friend within the company that you can develop a relationship with. Someone who can be your advocate to the whole company. Set it up so that you make this person look awesome in front of everyone else and they'll take care of the noise for you.

umm that sound like a year or two's worth of billable hours... FTW!