You are taking questions after a talk and a developer says your API's error handling is a mess and cost their team two weeks. They are partly right, and the fix is not yours to promise. What do you say, and what do you do afterwards?

Short answer

Concede the accurate part specifically and immediately, separate the part you disagree with and argue it on facts, commit only to what you personally control - carrying it to the owning team and reporting back - and never invent a roadmap date to end the moment.

Use developer relations as the thread through the responding to public criticism of your explanation: name the signal, then say what changes when it moves.

Concede the true part first, and concede it specifically

The instinct in the moment is to reach for a defence, and it is the wrong instinct, because everyone in the room has already decided whether the complaint sounds plausible. If part of it is accurate, name that part out loud before you say anything else, and name it precisely enough that it is clearly not a reflex. "You are right that a 400 from us does not distinguish a malformed body from a failed validation rule, and you have to parse the message string to tell them apart" earns you the rest of the exchange. "I hear your frustration" does not, because it concedes nothing and everyone can tell.

Specificity is the whole mechanism here. A vague acknowledgement reads as a technique, and developers are unusually good at detecting a technique. A precise one demonstrates that you understand the failure they hit, which is the only thing that makes the subsequent disagreement worth listening to.

Then separate the parts. A complaint that cost someone two weeks is usually a bundle: one thing that is genuinely broken, one thing that is documented badly, and one thing where they made a reasonable but wrong assumption. Those need different responses and it is fair to say so, as long as you do the conceding before the disaggregating rather than using the disaggregation to avoid conceding.

Commit only to what you personally control

The pressure in the room is towards a promise, because a promise ends the discomfort. Resist it. You very likely control the documentation, a sample, a follow-up post, and your own access to the team that owns the endpoint. You do not control whether that endpoint changes, and you almost never control when.

Say the boundary out loud rather than blurring it. Something close to: "I cannot tell you this will change, because I do not own that call and I would be guessing. What I will do is write this up with your exact case, take it to the team that owns the errors this week, and come back to you either way — including if the answer is that it is not changing." That is a smaller commitment than the room wants and a much larger one than most advocates actually keep, and it is the version that still holds up in six weeks.

The reason to be strict about this is that an invented date is a debt with a due date. If you say "that is on the roadmap for the next quarter" to end an awkward two minutes, you have created a public expectation that someone else will fail, in front of an audience who will remember that you said it and who will attribute the failure to your company rather than to your improvisation. The awkwardness of saying "I do not know" lasts about ten seconds. The cost of the invented date lands on the next advocate who stands in front of that community.

What happens after the room empties

The response in the moment is the smaller half of this question, and an interviewer who is any good will push straight to the follow-through, because that is where the answer stops being about composure and starts being about whether you function as a feedback channel.

flowchart TD
    A[Criticism raised<br/>in public] --> B[Concede the<br/>accurate part]
    B --> C[Write it up with<br/>the developer's case]
    C --> D[Take it to the<br/>owning team]
    D --> E{Team accepts<br/>the problem}
    E -- Yes --> F[Report the decision<br/>back publicly]
    E -- No --> G[Report the reasoning<br/>back anyway]

The two exits both lead to a report back, and that symmetry is the part candidates leave out. Closing the loop when the answer is yes is easy and everybody does it. Closing it when the answer is no is what establishes that you are a real channel rather than a suggestion box, and it is also the harder conversation internally, because you have to extract an explanation that is honest enough to repeat in public.

The write-up matters more than it sounds. Feedback that reaches an engineering team as "developers at the conference said error handling is bad" gets nowhere, and rightly so. Feedback that arrives as a specific request, a specific response, the assumption the developer made and the two weeks it cost them has a shape an engineer can act on. Turning a complaint into that artefact is the actual skill being tested, and it is a writing skill more than a speaking one.

One thing worth saying explicitly if the criticism came with hostility: do not answer the hostility. Not because you should absorb rudeness as a matter of principle, but because in a room the substance and the tone are separable and only one of them is on the record in a way that matters. Answer the substance completely and let the tone go unremarked. If it is sustained and aimed at you personally rather than the product, ending the exchange by offering to continue it afterwards is legitimate and reads as control rather than retreat.

The trust you are trading on is that you will report back when the answer is no; anyone can relay good news, and the community already knows that.

© 2026 Preptima. Originally published at preptima.com.