What are the magic words in this scenario
June 16, 2022 1:35 PM   Subscribe

I keep experiencing a troubling interaction pattern at work. Today I had another one. I had to take almost the whole rest of the day off just to process this. Because usually when I think about something for a few minutes I start to understand it. But I keep thinking about this and no answers are occurring. So that's when I usually hit up AskMe.

Using the conventional "teapot" metaphor to explain what I'm doing. Somebody will come to me and say "The market demands a new kind of teapot that has x special feature. So design the specs for the teapot we will sell that does x." So I think about what is the best way for our teapot user to do x task and I will draw a storyboard and specifications. Then I present them to the interdisciplinary team that will be manufacturing and selling the teapots to make sure this design will suffice. This is a regular and normal part of my role and I've been doing this for more than a decade. But for some reason this part never gets easier.

Because what will inevitably happen is this:
Me: So here are our plans for how we will accomodate x feature. First, the teapot user will do this. Then they will do this other thing.
Someone in the team: Um, actually,-
- And then they'll proceed to make a laundry list of all the ways this design is either missing requirements, mis-interpreting requirements, all with a strong implication in choice of words and tone that what is on display is an ignorance or willful and inexplicable disregard (or both) of standard teapot conventions that of course they are much more well-versed in than I am (a teapot designer of over a decade).
- Most of the time, everything they're saying is usually correct about missing or mis-interpreted requirements, but I honestly just hate the comments that imply that I know less about my own profession than someone who does something else for a living. I don't think it's fair to talk to other people like that especially in a setting where they aren't free to respond in the same brazen manner they're addressed in.
- Therefore at this point I don't see how I can continue presenting something now that I've completely lost support of the crowd.
- So I will say something like OK well in light of these comments the rest of my designs don't really make any sense so I think I should just end this here and do some rework.
-But this is interpreted as "taking my ball and going home" and "taking it personally" and they'll urge me to continue, which I will do but obviously uncomfortably.

But it's really just like, I just can't keep going with the wind knocked out of my sails. I know a true professional would just steadfastly continue and I guess gracefully move on, like a big boat. But instead I'm in fight-or-flight mode and since I can't "flight" I will resort to "fight". Not in a bad way but I will tend to defend my choices when it would be more polite not to.

So I guess my question is, what is the magic words I can say to myself to remind myself the right thing that i should do when this happens? This is a meeting that takes place twice a week every week and it's starting to wear me down.
posted by bleep to Human Relations (47 answers total) 13 users marked this as a favorite
 
"it's infinitely easier to critique a draft of something than to create a draft from nothing."

Depending on who it is who's doing this, there may even be a way to express this observation out loud.
posted by fingersandtoes at 1:38 PM on June 16, 2022 [13 favorites]


I participate in this kind of meeting fairly regularly, usually as a member of the team but sometimes as the presenter.

In my professional world, these kinds of presentations are not there to say "This is the design for the new teapot." They're there to iterate or improve upon a draft design. The thing that's presented is assumed to be incomplete and flawed. Often, it's intentionally presented as a "sketch" that looks very different from a more final design, to help the audience understand that it's an in-progress thing, not a final proposal.

One thing that also helps me is making sure that before work begins, I at least have a handle on (most, if not all) the requirements. My teammates do not begin teapot design right away, they have lots of informal discussions with me and my fellow teapot-makers and tepot-managers, and often they make it "our problem" if they can't proceed. 'Hi, I've been asked to make the new Ultra-fast boiling teapot design. I need to understand the material constraints for teapot heat and the legal requirements to not burn people in order to begin."

(This is also separate from... I think your teammates might not always be great at giving feedback? This is it self a skill and often one that's poorly done, especially cross-discipline.)
posted by Tomorrowful at 1:44 PM on June 16, 2022 [39 favorites]


I think it's often easier to present my work as a total rough draft (no matter how much time I've spent on it, or how "finished" I actually think it is) and specifically say I'm looking for feedback about what I'm missing, what won't work, etc., so that I can start incorporating those elements early and easily rather than later and less-easily.

So the presentation becomes less, "Here's what I've designed" and more "Here's a starting place and I'd love to hear what I'm missing or misinterpreting, because y'all know stuff I don't." Collaboration rather than presentation, I guess.
posted by lapis at 1:45 PM on June 16, 2022 [41 favorites]


Could you think of this as a minimum-input prototype and the following-up collaboration as something that puts more meat on the bones/contributes added dimensions?

It may be that All The Ideas are needed as a brainstorm, and if you foreclose an option that has your experienced insight, something else significant within your thought process might be missed.
posted by childofTethys at 1:49 PM on June 16, 2022 [1 favorite]


Can you set an expectation that feedback needs to be held until the end? That way you can at least get through presenting the entirety of the thing?
posted by purple_bird at 1:53 PM on June 16, 2022 [20 favorites]


If it's always or usually the same Someone, well... every team seems to have that person and everyone else in the room knows they are an asshole and they aren't judging you for it. So being able to catch the eyes of a colleague and send a silent "this one, again?" can forestall the fight or flight response.

If it seems to be different Someones every time, well, I wonder if you are getting buy in from the right people before the meeting? I've learned to try really hard not to blindside any department in an interdisciplinary meeting by having more casual 1:1 check ins through the process so they feel like they've already had their input by the time the review rolls around. Not like a full design review with each person but just "hey I'm working on this new teapot" and let them tell you what is going to be important to them.
posted by muddgirl at 1:55 PM on June 16, 2022 [11 favorites]


Most of the time, everything they're saying is usually correct about missing or mis-interpreted requirements, but I honestly just hate the comments that imply that I know less about my own profession than someone who does something else for a living.

Good comments above, but...why does this keep happening? If I'm understanding you correctly, they're correcting you on standards in your, not their, area of expertise, but...they're correct? And it's fairly objective? In addition to the already given suggestions, I would try preventing being put in this situation by reducing, if not eliminating, the opportunities for it to happen. Are you not being given enough time to produce good work? Are you not working carefully enough? Is there some interaction between your expertise and the rest of the necessary knowledge base that isn't happening? These all require different solutions, but I don't quite understand why someone with a decade of experience would be routinely presenting designs that don't meet requirements.
posted by praemunire at 1:55 PM on June 16, 2022 [8 favorites]


Response by poster: They meet the requirements I'm given and they follow all standards. There's just always stuff I didn't know about that comes up. Which is fine. But it's never said neutrally or in a helpful way, it's always said in like "Well why isn't this stuff here?" "Well because I'm just hearing about it now."
posted by bleep at 1:57 PM on June 16, 2022 [1 favorite]


If it's a regular occurrence across meetings with many different people, then I do think it's a culture thing you need to work on.

However if there is one particular person you notice who every single time needs to make a negative comment out of some pathological need to perform control? Well...

I used to work with someone like that and I got to the point where I'd put "something for Steve" on every project. Just something that was so glaringly obviously stupid and wrong that only a complete jackass would run with it. Then Steve could say "take that thing off" and I could be like "oh praise be to Steve" and he'd be satisfied that he had contributed and one-upped but nothing I actually cared about would get picked at.
posted by phunniemee at 1:58 PM on June 16, 2022 [21 favorites]


So you do a bunch of work and then they reject it and you have to start over? I'd take a page from the Agile methodology and break the approval part into much smaller steps wherever possible so you can stop going down the wrong path or force them to be more clear about which path they want. Then the team needs to approve each step as it goes so nothing is misinterpreted.

How are the requirements being missed - are they not providing them, are you forgetting them, or are the priorities not clear? Maybe the intake process needs help as well so you get time to ask follow up questions and gain clarity. Are these same people rude in other communications or are they in some kind of hyper-critical show off mode? Is this how they react to other projects or just your own? The early design phase is the time to poke holes and brainstorm about problems because this is all on paper and not in production yet. If that is how all of these projects work, then it might just be your reaction and you can recognize that and work on it. If no one else's work is torn down this way, you might be singled out or looked at poorly. Do you want to stay somewhere that has cast you in this role?
posted by soelo at 1:58 PM on June 16, 2022 [6 favorites]


Just a quick question: are you a woman or female-presenting person?

Because if you are, unfortunately, the correct answer is probably: don't be.
posted by jacquilynne at 2:00 PM on June 16, 2022 [27 favorites]


There's just always stuff I didn't know about that comes up. Which is fine.

Well, it's not fine, if you're being critiqued for not knowing things that you needed to be told to do your job right. I would start thinking about how to push for a more detailed brief so that you get that information up-front, not after you've already done a ton of work. I'd do this even if the specific problem in the group is a "Steve." Why should you have to re-do your designs to incorporate information you should have been given in the first place?
posted by praemunire at 2:05 PM on June 16, 2022 [15 favorites]


To yourself: Welp time for the nerd show off show I guess.

Out loud: ok let’s enumerate and discuss your concerns. Why are you concerned about spout size again? (Aka ball in their court aka The Make Them Work For It strategy; once I make them explain in detail their high level questions they crumble pretty quickly out of that talk down stance)
posted by St. Peepsburg at 2:15 PM on June 16, 2022 [11 favorites]


Is there a way to cast these meetings as:
. "I have prepared a draft as a starting point for everyone's input" rather than
. "the company has hired a multi-disciplinary team with a wide array of expertise, but for some reason I'm supposed to have the complete and perfect answer right out of the gate"?

Because this feels like a very "Crucial Conversations"-style "Pool of Shared Meaning" thing. If they're offering feedback when they should just be saying "yep, got it, we'll configure the teapot extruder to your specs", then somebody in their management chain needs to remind them of that. But if they're offering feedback because they see a different side of the issue/process, then this might just be step 2 in a k >=2 step process to providing the best dang ol' teapots that your customers ever did see.

So, if their feedback is unnecessary, it might be worth asking your boss how to approach this kind of cross-team hiccup. If their feedback is valuable/necessary/part-of-the-process, can you interpret it as them saying "thank you for the information you have placed in our Pool of Shared Meaning. Allow me to reciprocate" instead of interpreting it as "bleep, how could you design a teapot that fails to get FM radio?" like that was something you should've thought of.

(This is very easy to type all the way over here in internet-land. It's slightly more challenging to do in real life, but Crucial Conversations was very helpful.)
posted by adekllny at 2:16 PM on June 16, 2022 [5 favorites]


If you're perpetually finding out about requirements you didn't know about beforehand, in these meetings, that is a problem I'd address on its own. Whether it's a problem for you, or your manager, or their manager...

"I keep doing work and only later finding out about requirements from Person X or Person Y. I need to know about these requirements beforehand; as it is, I'm wasting a ton of time working without all of the information. How do we make sure I'm not only partially informed before I begin work?"
posted by Tomorrowful at 2:20 PM on June 16, 2022 [43 favorites]


Can you talk to some of those people individually well before the meeting happens, so that you can get some feedback in advance?
posted by akk2014 at 2:23 PM on June 16, 2022 [6 favorites]


1. They must tell you everything which is not working about the standing design. All complaints, consequences, over cost, etc. Before you start working. If this info is submitted by a few people, collate it, send it back out as a group email, ask "Is this everything?" Wait for all replies.

2. Send out your report, now the teapot looks like this? Any comments? Do not proceed to set up a meeting until you have all replies and suggestions. Collate these, send them out, so everyone sees everything.

3. Have your meeting, explain right up front, you will be giving a demo, you will have the floor, then open to discussion, with a team member taking notes that all can see.

4. You will all discuss point to point, mark off closed issues. Reach agreement while everyone is in the room.

5. Don't take any of it personally. Everyone has an ass, not everyone is an ass, most days. Make it clear the meeting is for creative and expert collaboration, not woodworking, grind axes on your own time, and leave them in your cubbies.
posted by Oyéah at 2:29 PM on June 16, 2022 [5 favorites]


I think people are alluding to this but just to spell it out more clearly: If you need this feedback/info from these particular people, it sounds like you/your system may need to design the process so that you get it earlier. You shouldn't be doing a ton of work that feels fairly final to you without that input, if that information is vital to the project. Maybe it's presenting a rougher-draft earlier, maybe it's a bunch of conversations before you start designing, maybe it's a bit of both.

If you don't need their input and they're just being show-offs, then you/your system, as others have said, need to shut down their input. (It doesn't sound like this is the case, but including it just in case it is!)
posted by lapis at 2:36 PM on June 16, 2022 [11 favorites]


If this is more than just That Asshole Steve, then yeah, this sounds like a process that’s setting you up to fail. You’re getting requirements from the higher ups who don’t know how things actually work, but not being given a window to get input from the actual team that has the right expertise. If there is any way to start off the process with “hey, team, here’s the request, here are my very initial thoughts on it, can we spend half an hour debriefing on any major issues you see before I go off and whip up a whole set of specs?” I would do that. If not, I’d see how much you can recast these meetings as an early check in, as others have suggested.

Potentially you could also cut some of this off by casting this as a high level session. The goal isn’t “list twenty ways X is wrong”, it’s “flag that X has some practical issues, stick that on a list, tell bleep that Roger is the expert on that so bleep can catch up with Roger later about the details, and move on.”

But also it just sounds like one or more people are being shitty. You can point out that someone got the brief wrong without maligning their competence or expertise. They’re being jerks and depending on the politics and personalities involved, you might consider talking to the manager of that group about how bad the vibes of these meetings are and ask if, knowing their team better than you do, they have any ideas for getting things back on track or reining in their people.
posted by Stacey at 2:40 PM on June 16, 2022 [6 favorites]


A person I once worked with always talked about “the meeting before the meeting,” which is to say the smaller, lower-stakes checkin with some crucial person to preview and incorporate their feedback before the larger, higher-stakes meeting where the real feedback is delivered. If you set these up well, you’ll be entering the big meetings with everyone already informed or consulted as appropriate. Large groups are no place for surprising or new information. Use them for confirmation of things agreed to beforehand. This has the added benefit of making your work more “agile” as mentioned above and gives lots of people a smaller venue in which to feel grateful to have been specifically consulted for their input.

Big review sessions should ideally be a rubber stamp with all real communication and decisions having taken place before.
posted by migurski at 2:45 PM on June 16, 2022 [33 favorites]


So as it stands, you're gonna be working in prototype mode and you know that you're receiving incomplete specs as a matter of course. First is not to do so much work up front. A sketch and a user story, save the storyboards for later. Then, go back to the person who gave you the spec and show them what you have. Give them a chance to fill you in on all the stuff they usually beat you up with later. (As an aside: are these salespeople?) Lastly, break the pattern of the meetings: don't let them interrupt your presentation. "Please save all comments and questions until the end" and make them give you the 5-15 minutes to finish the dang story.

Then you can say "OK, let the whipping begin!" Take the high road, but have fun with it and know that they're projecting their own inadequacies onto you, which you don't have to internalize. Start calling one of them "T-Bone" or something.
posted by rhizome at 2:48 PM on June 16, 2022 [3 favorites]


I don't think there are magic words but I think there are better processes that out the extra requirements before you go off and do a bunch of work that gets torn apart. I am a stakeholder and participate in design workshops fairly often. The person running them brings together a small group of stakeholders, we work on a list of ideas, features, requirements, use cases, whatever make sense. Depending on the task, we generate ideas together or brainstorm separately. We often then vote on the most appealing/ important ideas and needs. It sounds like you're putting a lot of solo work in before you have all the information and that's no fair to you and not efficient. If you've got some people who generally like to tear stuff apart, maybe they need to be part of the initial sessions, or at least you can do a quick pass with them before you present to a larger group.
posted by vunder at 2:48 PM on June 16, 2022 [1 favorite]


A couple of things to think about in addition to the advice you've been given.

Can you incorporate some informal user research into your process where you conduct a few short interviews/conversations to tease out more information about the requirements from colleagues within the org. That way you can anticipate issues and address them before these meetings and you can also preface your presentation with, " This proposal incorporates input from A, B & C."

I also recommend learning about Liz Lerman's critical response process. She teaches a highly structured way of giving feedback to creative professionals.
posted by brookeb at 2:53 PM on June 16, 2022


If the critiques are accurate, then it sounds like you need to break the various elements into smaller chunks and get more feedback as you go rather than spending a bunch of time on work that can never be used because of factors that no one told you about. This comes up a lot, because people who are immersed in any kind of environment have a lot of shared knowledge that someone from outside doesn't and regularly forget that other people don't have that shared knowledge.

I think "workshopping" the design ahead of time with 1 or 2 key members of the team who can be relied on to give actionable input will also be helpful in terms of ironing out key details, like "no one told you that the spout must be at 45 degrees" or "for federal compliance reasons, this teapot must be made of vulcanized rubber" or "a key user demographic here is going to be churchgoing ladies between 60-68 years old".
posted by The Elusive Architeuthis at 3:01 PM on June 16, 2022 [1 favorite]


it's always said in like "Well why isn't this stuff here?" "Well because I'm just hearing about it now."

The correct response would be “Those items were not in the design request so-and-so provided” When it’s being implied that you are at fault, it’s always ok to push the actual one at fault under the bus.
posted by Thorzdad at 3:07 PM on June 16, 2022 [47 favorites]


It sounds like you need to get feedback earlier on in the process.
posted by number9dream at 3:22 PM on June 16, 2022 [5 favorites]


You could try splitting the single meeting into two meetings. The first one can only contain positive contributions, zero critical feedback. The stated goal is to have unconstrained brainstorming to find all possible positive things you could do to have the most amazing teapot that solves x. Unstated goal is to get everyone in the room really excited and invested in the problem and possible solutions.

The second meeting is where everyone gets to play devils advocate and critique the solutions from the first meeting. This isn't just to bash things for fun, but to thoughtfully identify any issues that should either modify or cancel some of the previous meeting's ideas. There are no hurt feelings if someone's previous good idea gets ruled out.

At the end of the meetings, you should have a pretty exhaustive set of alternative solutions and restrictions that must be kept in mind.

If negative things get said during the first meeting, quickly cut it off and remind them that they shouldn't be worrying about that right now, that's for the second meeting. Don't even "parking lot" the negative feedback, as it may not be relevant by the end of the first meeting.
posted by Diddly at 3:51 PM on June 16, 2022 [1 favorite]


I think there's a lot of good advice in this thread about modifying the process to avoid this result.

Two additional things you can do:
1) consider whether some of what seems like a condescending or aggressive tone might just be how that person sounds when they're giving feedback to anyone and they don't mean anything personal by it. That's obviously not going to be true for everyone, but it is the case for some people. I know that I often have to work hard to not just be like "X should be like this and we're missing Y and this thing Z here is a terrible idea, why would you not do Q instead, nobody should ever do Z, Z is insane" -- that's just my flow of thoughts and isn't actually reflective of what I think of the people on the receiving end at all. (How they react to criticism does color what I think of them though.) I know that I need to be much more diplomatic than that, couching things better and sandwiching them properly and watching my tone, but it's a lot of extra effort and I don't always manage or remember 100%. Some people are worse than me. (Also in case you're dealing with a multicultural crowd - some cultures value straightforwardness over tact.)

2) regardless of whether their intentions are positive, negative, or neutral, you can treat them as though they're positive. Stephen asks why you didn't do Z? "Nice catch, writing it down. What else?" You forgot X and Y and how did you manage to forget W? "Great, that's exactly the kind of feedback I was hoping for. Lemme ask some questions about X. Tell me about Y. I'm thinking we should do V about W -- see any drawbacks to that?" or "Good point. Let me run that by [relevant person]." Nod to show you approve and write things down. Make them feel like you appreciate their input (this reflects well on you because you understand it and can see what they mean) and the fact that they care about the product (because you care about the product). This is less about being a teapot pro and more about being a people-management pro, getting wind in your sails from fielding feedback like you wanted it and expected it and everything's going to plan.

(All of this of course is dependent on the individual personalities involved and ymmv)
posted by trig at 3:57 PM on June 16, 2022 [4 favorites]


I've been presenting designs internally my whole career and this is very familiar to me.

Agree with everybody who says #1 glaring issue here is one of process and expectations. It sounds like your expectations for what you're presenting and the feedbackers' expectations aren't in alignment — I'm hearing in the feedback an expectation that the work will have already included certain use cases, wheras your expectation is that, well, how could you have included that if you didn't know it?? Getting aligned on what people are expecting you to bring to the meeting is crucial.

(It's possible that expectations are aligned, however: there are contexts in which some kind of initial design is desired in order to elicit the needed reflection and response. In UX for instance you'll often get a better conversation with a user if they have something to react to, vs musing abstractly about their needs. In that case … more on that below)

Regardless, it feels like you're coming up against a core issue in design: creating good design with a team is a skill, and it's both an organizational and individual skill (for all the people involved, not just the designer). And in an organiztion that isn't design focused, usually the only people who think about it are the designers. I've had to push for good process that helps me do my best work at most places I've worked. That includes pushing for a good requirements process, or just making it happen by ie scheduling meetings myself with folks who I know had valuable input; structuring meetings in specific ways to guide the team to have productive conversations and give feedback in helpful ways, including 'questions but no feedback until the feedback phase' rules, intro slides where I give the context to what I'm presenting (ie 'here's the requirements I had' before even looking at a design) and more.

There's an idea I found on the net a while back (can't dig up the link) around design presentations, that it helps to frame a design as 20% or 80% complete. The idea being that at 20%, you need all ideas and input while at 80% you're close to finished and need polish input. I haven't implemented this but I think it's a helpful frame to think about your own work: when you're presenting, how finished do you think it is? How much uncertainty? If you can get the others in your meeting aligned on that you can have am much more productive conversation.

Ultimately the most productive (and soft on my ego :) conversations come when it feels like a collaboration. Collaboration requires being aligned on goals and questions, so that is always my first step.

All that said, I have very much had that feeling of "why do they talk to me like they're the expert?" a lot in my career. I think part of it is that at least in my world of UX and graphic design a lot of folks have a kind of intuitive feeling that they get it, that their daily experience (which is meaningful!) has given them the same kind of knowledge and insight that I have. It's really annoying. It has been reduced as I get better at structuring my process and the meetings, though. I think even just taking charge of the framing of the design presentation ("here's my requirements, I'll present, then feedback" kinda stuff) can put people in the needed mindset.

There's a lot of things that the above analysis leaves out, notably any kind of power analysis: if you're not in a position to guide the meetings or to captain your own process outside of the meetings, then all of that above doesn't mean much. Some organizations are going to be toxic and conitnue to result in situations like the ones you experience regardless of what you try.
posted by wemayfreeze at 4:02 PM on June 16, 2022 [7 favorites]


"Well because I'm just hearing about it now."

I am a tech writer for engineers who are busy inventing things, and I say this to them every. single. day. Instead of being looked down upon for being (mildly) combative, I am instead respected for being a team player.

And yeah, it sounds like the others just don’t know how to be polite sometimes. Don’t take any of it personally.
posted by Melismata at 4:58 PM on June 16, 2022 [4 favorites]


I feel your pain! There is a lot of goodness here! The way a fellow mefite taught me to think about it: frame the process as rapid prototyping.

This process is needed specifically because the specs are not all identified up front, and sometimes stakeholders need iteration to fully realize their needs.

So you become the facilitator for pulling out whatever else is needed. You are conjuring the specs, and should get credit for that by announcing that as a goal for the meeting: to help them identify the holes.

But it works either way! They don’t have to buy into it, feel free to repeat your intentions and act that role out.

Inthe meeting when Steve says ‘well, it is teapot 101 that X should be there when I Y’ you can say: “Thank you Steve, I was hoping someone would bring that up. It didn’t sit right with me either, but I thought there might be a good reason - does anyone here have a reason not to include this? Or “right Steve! the problem is the team asked for a drip groove where the whistle normally goes, can we all talk about that?”
posted by drowsy at 5:01 PM on June 16, 2022


Response by poster: ^ this is actually describing my typical strategy, but the helpful discussion here is helping me understand (because I started thinking wait, IS every meeting like this? Some of them do go better than this... what are they like?) that it seems like something is making my thinking brain switch off and my regular strategies for managing this become temporarily unavailable. Maybe something I can work on is consciously trying to get back into that gear when I feel like I've been jolted out. Thank you for all of these answers I really appreciate it.
posted by bleep at 5:09 PM on June 16, 2022 [6 favorites]


I don't know what your teapots are; my experience is in software design, and the best company I've worked for had a dedicated team of designers. I learned a lot from them about design, how to handle meetings, and what challenges designers face.

* You can have professional designers, as we did, and yet a presented design was not a finished thing, a one-way info dump from designers to users/implementers. It's a stage in the process. Sometimes a design was clearly insufficient and had to go back for rework. It was never redesigned in the meeting: meetings are for finding problems and building consensus, not for actual design.

* Anyone involved may have good ideas, and not necessarily in their assigned area. Try to dismiss the idea "this person is not a teapot designer".

* Some people just don't know what they need before reacting to a design or prototype. Frustrating, but you want to squeeze out those droplets of knowledge that they didn't think of before. Humans remember things in context, while designers (and programmers) think in terms of a complete set of requirements up front.

* It's a constant challenge to get requirements as early as you can. This is partly on you and partly on your co-workers. Can you get some of that key info informally, before the meeting? Can you get your boss(es) to emphasize that requirements have to be explicitly stated as early as possible?
posted by zompist at 5:10 PM on June 16, 2022 [3 favorites]


It sounds like you’re designing in a vacuum and then doing a big reveal. In my experience that’s a mistake. Circulating drafts and getting buy-in needs to be part of your process.

It makes the process smoother, but perhaps most importantly to you it gives you a ready response: “I passed around these documents, why are you just commenting now?” The implication being that they not only wasted your time but also that of everyone else in the meeting.
posted by Tell Me No Lies at 6:14 PM on June 16, 2022 [3 favorites]


I'm so sorry you're having this recurring experience which sounds very stressful. There are some great ideas upthread for how to manage this practically (soliciting feedback earlier, setting up "meetings before the meeting"), but I also have some thoughts about a different part of the dynamic, which is your understanding/interpretation of the feedback. I'm a woman (which I do think contributes to this, so if you are also a woman, yes it's normal unfortunately), and I have had many meetings like this where I felt super discouraged and criticized and disrespected and was also told not to take it personally. And that would piss me off, because it is super hard to "not take things personally" when they feel so personal!
But with some distance from those situations, I can recognize that at least half of the issue was that I was taking things personally and interpreting any and all feedback as criticism rather than as feedback. There is a key difference. Criticism doesn't go anywhere, it isn't valid/accurate/productive, and it is personal (usually an attack on your character). But feedback, even when delivered poorly, is about a shared goal: making the thing and making it well and to the customers' specs/requirements.
I have had to work very hard to distinguish between criticism and feedback and I'm still not great at it. What helped was thinking about times when I have received helpful feedback, specifically a dance teacher I once had who gave great feedback. In her class, receiving feedback made me feel special and noticed and like she respected what I was doing but also cared enough to help me improve. Others didn't see it that way; they would come to class once and then never come back (they took it personally). So now, when I get feedback - even though my impulse is to think "they think I'm stupid" and "they don't respect my experience and talent" and "why didn't they tell me sooner what they wanted?" - I try really hard to think of my old dance teacher and change the narrative in my head to "they're giving me feedback because they do think I'm smart/capable and they know I can make these changes/improvements." And "their feedback is a sign that they care about this product/project." And "if they didn't like me/thought I couldn't handle this, they wouldn't bother giving me this feedback, they'd just assign this task to someone else." So maybe re-framing some of these instances in your head would help, along with giving feedback to your colleagues about how they give feedback (even just a, "can we start with 2-3 things that are working/that you like about the presentation before diving into the critique?" It's OK to ask for this!).

I hope some of this resonates, and I apologize if it doesn't. Good luck!
posted by sleepingwithcats at 6:51 PM on June 16, 2022 [7 favorites]


I would start by saying, “To contextualize this draft, I wanted to share a quick review of the brief that the Tea Strainer team provided, thanks team! (Show a slide of their request) The design was intended to have A B C and D.

Now, I’ll take you through the drawing, and afterwards we can do comments.

(Slides) Here you see Feature A, and I chose to use titanium here for these 3 reasons. Feature B has a — oh excuse me Steve, if you don’t mind I’ll ask you to hold your questions to the end, thank you. As I was saying, B has a leather tassel. C has a serrated edge here for this reason, and finally D, as requested in the brief, has a tail. All of these elements exceed the relevant code requirements, as always. And I’d like to thank the Tea Stainer team for sharing that brief with your requirements. Does anyone have any questions that I can help clarify?”

“You’d like Feature Z? Oh interesting, was that included in the brief? Ah. In that case my recommendation would be to include a Z made of glass. It would be helpful to have had that requirement ahead of time, as it makes more sense to design D and Z as a matched pair. Are there other requirements that aren’t in the brief?”
posted by nouvelle-personne at 7:27 PM on June 16, 2022 [7 favorites]


… this is a great thread! The specific emotional reaction you’re talking about sounds similar to Rejection Sensitive Dysphoria to me, and you might be able to find some tools with that as a search term.
posted by sixswitch at 8:01 PM on June 16, 2022 [3 favorites]


Simple but possibly helpful when referencing the brief: Attach a PDF of the brief with the calendar invitation. That way, everyone has it. Nobody can claim they don't know what's in it.
posted by yellowcandy at 9:17 PM on June 16, 2022 [1 favorite]


And then they'll proceed to make a laundry list of all the ways…
As a quick, practical measure, you can interrupt this by immediately (but slightly slowly) writing down each thing they say.

“Okay, first of all, why would you put the handle on the back? This is for the side-handle market! And the-”

“Whoa, sorry, just one sec. This is for the side-handle market? Got it, thanks. So, (writing) handle should be on the right side. Okay, what was the next thing you had?”

This is emotionally helpful (for me, at least) because it keeps you clearly in control of the meeting and doesn’t let the person build up a bunch of momentum criticizing you. Asking clarifying questions both makes it clear to everyone what you didn’t know and gives the interaction a collaborative feel. And it lets you be a little passive-aggressive if you need to stick it to Steve - make him repeat himself, put him on his back foot a bit. Serves you right, Steve.
posted by pocams at 10:19 PM on June 16, 2022 [2 favorites]


Nthing nouvelle-personne and yellow candy.

In an ideal world: Attach the brief to the invite, but assume no-one will read it. Re-structure meetings to begin with a quick review of priority requirements - you could list the 5 most important, you could give the room the first 5 min of the meeting to review the brief. Invite them to write (sticky notes?) any missing requirements they identify in this first pass and during your presentation. Let the team know that you’re going to review the whole design before any feedback, and that you are going to need the team’s help in identifying design choices that meet the brief AND those that don’t AS WELL AS *crucial* requirements that were left out of the brief. The whole team’s time is valuable, and you want to make best use of their input to get to the right design in the shortest amount of time. Once you get to the end of your teapot demo, use a quick, structured review similar to After Action review. What meets needs about this design? What doesn’t? Can this design be moved forward, or are there *crucial* requirements that were missing from the brief that will require re-design? Nice-to-haves go on a big post-it or collected for you to review, but time is money, and remind them that this type of meeting is a first pass: it is not the right time to discuss feedback on the material of the teapot handle when the brief as provided didn’t ask for a spout.

I am rooting for you!
posted by rrrrrrrrrt at 10:41 PM on June 16, 2022 [2 favorites]


Use these phrases:
1. "This is an initial draft" at the opening and "let's hold comments and questions for the end" at the opening and through out.
2. At the end when getting comments/questions: "Interesting point, I'll write it down," then write it down.
3. If there ends up being a lot of feedback, "this sounds like more feedback than I had expected. Maybe I should connect separately with [feedback person] outside of this meeting to get more details." This is good because, [feedback person] isn't interested in giving useful feedback and won't want to meet with you when they can't show off.
4. Also break out "this is a nice to have" vs. "this sounds like something we need to move forward".
posted by Toddles at 10:55 PM on June 16, 2022 [2 favorites]


Since you’ve noted that this isn’t a feeling you experience in every one of these presentations I’m going to suggest a sort of sideways approach.

First - is is possible that it’s harder to manage your emotions sometimes because these meetings are happening right before lunch, on days you’re extra tired, or something else biological or environmental is making it harder to regulate your emotions?

Second, is it possible that you are a privileged person (white/cis/male/middle to upper class) and the person whose questions upset you so much is in some way less privileged than you (not white/Not male/not cis/language use that gets looked down on as “uneducated”)?

I ask this second question as a cis white woman who finds some white men get tell their or my managers that I have been unprofessional when I ask questions about a process I was not involved in initiating (I have the spec list and they haven’t showed me the list they received, I ask to compare what they received to what I am aware of, for example, and that’s considered “bossy.”) it is, perhaps, possible that receiving feedback from folks society enforces as “other” to you feels like an attack. This is not a criticism of you personally if it’s happening, but it is a well documented phenomenon.

Third, it is very possible, as someone suggested above, that you are a marginalized person and the the people doing the criticism are privileged and feel entitled to speak down at you rather than collaboratively.
posted by bilabial at 3:05 AM on June 17, 2022 [6 favorites]


Bilabial’s question about identity is super important!!

Race, gender, appearance, accent, ability, education, age, seniority, etc, all make HUGE differences in perceived status, and humans are highly attuned and bothered when there are disturbances in status.

Interrogate that interpersonal dynamic because it is for sure at play to some degree, it always is.
posted by nouvelle-personne at 7:43 AM on June 17, 2022 [4 favorites]


“You’d like Feature Z? Oh interesting, was that included in the brief? Ah. In that case my recommendation would be to include a Z made of glass. It would be helpful to have had that requirement ahead of time, as it makes more sense to design D and Z as a matched pair. Are there other requirements that aren’t in the brief?”

...I wouldn't do this unless you want Steve as an enemy. Now, you may not care at this point, or it may be that Steve is undermining you in front of higher-ups and you really need to make the point, but otherwise this is turning the conversation into a confrontation. It isn't fair that you have to worry about this and Steve isn't worried about making you an enemy, but you have to decide whether it's worth it.
posted by praemunire at 7:47 AM on June 17, 2022 [3 favorites]


So I'm someone who doesn't do well with criticism, even if it's constructive, even if it's accurate, even if it's helpful. It's not something I'm proud of, it's something I'm constantly working on, but it's still an issue. I do have a tendency to respond like you do: fight or flight mode, I can get defensive, I push back when it's not the most diplomatic approach at the time.

One of the very simple, helpful habits I've tried to train myself in is when someone provides one of these critiques, I try my best to as sincerely as possible thank them for the feedback. For example:

Steve says: "Teapot with X is missing Z feature and the end user should be utilizing Y protocol"
You: "Thanks for bringing this to my attention! That's very helpful feedback, and I'll be sure to incorporate it in the redesign."

And if you do want to do a polite clarification, you could change the second sentence to something like: "This is very helpful feedback, especially since that wasn't included in the original specifications. Now that I'm aware of this, I'll be sure to go back in and incorporate it.

Or if it's not necessarily something you need to incorporate, you could go with, "Thanks for suggesting that! When I'm incorporating some of this other feedback, I'll look into whether this is something that we can add in."

A lot of the key to carrying this off is less about what you say, but more in your tone, and it is one of those things that takes practice. But it gets easier! And I find over time, responding like this actually can help shift my mindset. It's sort of "fake it til you make it".

This is one of those things where it can be helpful to sit down and write out a few standard variations, and actually practice them in front of a mirror. That way, if your brain goes blank in the fight or flight, it will be easier to reflexively fall back on this.
posted by litera scripta manet at 9:05 AM on June 17, 2022 [2 favorites]


> Are there other requirements that aren’t in the brief?”
> …I wouldn't do this unless you want Steve as an enemy.


Steve has already decided to be an enemy. This tactic is designed to let him know that it’s time to stop being a bully.
posted by nouvelle-personne at 11:10 AM on June 17, 2022 [2 favorites]


For these kind of review meetings, I like handing out post-its / sharpies at the beginning and asking everyone to write down questions / feedback and holding on to them for discussion at the end.

If people still interrupt, I say "good question, write that down" (with a smile).

At the end, I make the time to discuss the items that were written down. In many cases, the conversation ends up not being required because I ended up addressing it.

And if it is an issue, I ask for the post-it, and keep it for my follow-up notes.
posted by kaefer at 12:53 PM on June 20, 2022 [1 favorite]


« Older Cat vs chair! Emergency-lite edition (well ok...   |   Tibetan Healing Ritual/practice Newer »
This thread is closed to new comments.