Be Clear With Your Ask

Have you ever been in a conversation where someone voices a complaint but offers no solution? Sometimes you know exactly how to address their issue. Other times, it just leaves you confused.

Let’s consider a common scenario: a restaurant customer orders food, but it either arrives late, is incorrect, or has some other issue. The customer complains to the server. What should the server do?

Fortunately, situations like this are so common that there’s an established cultural playbook. The server typically offers to either replace the meal or take it off the bill. Simple enough.

But what happens when a clear resolution isn’t obvious?

Communication in Software Development

This lack of clarity often surfaces in software development teams. Engineers review each other’s code before it gets merged into the larger codebase. Imagine application code as a giant Word document. Code reviews are akin to proposing edits—adding, removing, or modifying paragraphs—while other engineers provide feedback before finalizing the document.

Extending this metaphor, imagine receiving vague comments such as, “Do you think there are other words we can use here?” or “Maybe we should consider a different sentence structure.” These remarks leave the author guessing. They may try various alternatives, but there’s no guarantee the reviewer will be satisfied.

A skilled reviewer goes a step further. Instead of posing open-ended questions, they offer actionable suggestions: “What about using the word Y instead of X?” or “Here’s a possible alternative sentence structure.” When the reviewer holds authority—whether due to expertise or role—they may even give direct instructions like: “Change this to Z because of X reason.”

The Downside of Open-Ended Feedback

In engineering culture, pedanticism often rears its head. Engineers can become overly fixated on details, losing sight of the broader product context or the team’s capacity. Not every team has the skills or resources to execute code perfectly, and that’s okay. Challenges can be addressed iteratively.

However, some engineers hinder progress by asking overly broad "why" questions that drain the team’s energy. While there’s value in discussion, a reviewer should aim to provide actionable suggestions during the review process. Comments left open to interpretation should be framed as optional considerations, not demands.

The Broader Lesson: Ask with Clarity

This principle extends far beyond engineering. If you have an issue with someone or something they’ve done, consider what you actually want. Make a clear request. If you don’t want anything, state that explicitly. Don’t offload the work of figuring it out onto someone else.

If you have a complaint, accompany it with a clear ask. If your meal is unsatisfactory, request a replacement or ask for it to be comped. Don’t leave it to the server to decide. Clarity in your ask not only helps you but also benefits others—even if they’re unwilling or unable to fulfill your request. Your ask becomes a mechanism for alignment.