How to negotiate the non-sexy stuff at work
I've read a few books over the years on the art of negotiation.
The good thing? I picked up lots of cool "tricks."
For example:
- There's one where you use a "late night, radio DJ voice" to disarm the other side and put them at ease
- There's one where you use the other side's own rules against them ("You said you value customer loyalty; I've been a customer for five years...")
- There's also the classic BATNA framework ("Best Alternative to a Negotiated Agreement") that helps determine your walk-away point
The less good thing, however? It's that I never found a way to actually apply these "tricks" at work.
Why? Because these tactics feel like they're designed for people who actually negotiate million-dollar deals.
Meanwhile, it's not that I don't negotiate at work.
It's just that I find myself "negotiating" slightly more mundane things, such as:
- Deadlines for an upcoming deliverable
- The scope of a new project I'm tasked with
- The amount of product support I want
- Roles & responsibilities amongst a group
- How much support I commit to a project
None of these really qualify as high-stakes interactions. But they pop up at work almost every single day.
And unfortunately, what the books taught me simply felt too fancy and impractical.
I needed something that could actually help me in my day-to-day grind.
π Join 5000+ readers and subscribe to Herng's Newsletter for free:
Negotiating in real life
I'm not saying that those timeless classics on negotiation techniques aren't helpful.
I'm saying that for most of us? We need something that's much more practical and down-to-earth.
Put differently: most of us don't need to learn how to establish our BATNA, how to polish our late-night radio DJ voice, or how to "expand the pie."
But all of us need to know how to negotiate against demanding requests, how to ask for resourcing support (and get it), or how to deal with pushy stakeholders.
We're negotiating at work all the time β even if we don't realize it.
And today, we'll cover 3 practical principles that can help us negotiate better in these somewhat mundane situations. They are as follows:
- "Is it no, or not now?"
- Embrace precision
- Ringfence, explicitly
"Is it no, or not now?"
Let's look at an example.
For some people, their strategy is to just try again next quarter with the same pitch.
They think that if they repeat the drumbeat enough (and/or dial up the intensity of the pitch) β then their request will eventually make it to the top of the stack.
Sometimes this works. But sometimes, it's more productive to ask:
"Is this a categorical no (and if so, why)? Or is just simply not now?"
Because:
- If it's a categorical "no" β what are the guiding principles behind the decision? What would have to be true to turn the answer into "yes?" Is it revenue impact, ease of execution, contribution to an org priority, or something else?
- And if it's a "not now" β how is the prioritization determined? What would have to be true for a request to "cut the queue?" What factors matter the most to the decision-makers?
While asking these questions doesn't guarantee you'll get what you want β you become much more informed when you do decide to re-engage.
After all, there's nothing worse than thinking you're being told "not now" β when the answer was a categorical "no" all along, due to guiding principles that you were too lazy to clarify.
(You'll simply frustrate the other side and waste everyone's time.)
Similarly, if you're in a "not now" scenario? Don't mistake it for a categorical "no" and think that your only options are to give up or escalate.
After all, if you ask the right follow-up questions? You might realize that you have more levers to pull than you think.
Embrace precision
Let's look at another example.
A common mistake in these scenarios? It's when you create false dilemmas for yourself.
It's when you think that there are only binary outcomes, i.e. you either provide data support β or you don't. And there's nothing in between.
You then agonize over the (false) dilemma of choosing between either saying yes (at the expense of your own bandwidth) β or saying no (at the risk of upsetting others).
In these situations? Remind yourself that there's a whole spectrum of options between yes and no.
Specifically, you want to ask precise and granular follow-up questions so you can properly deconstruct what exactly it means to "provide data support."
For example, you might ask:
- "What type of data support is required exactly? Is it building data pipelines from scratch, setting up dashboards, extracting insights, or all of the above?"
- "If we had to prioritize, which tasks are most critical? Is it preparing insights for the exec forum, or is it building dashboards for the working team?"
- "Which tasks require the fastest turnaround time, and which ones are less time-sensitive?"
- "Which metrics require the most granular cuts β and which ones are you OK with only top-level / aggregated / directional insight?"
- "Which parts of the data analysis can be driven by other people? Where is my subject matter expertise most needed?"
What you'll then realize is this:
- When you embrace precision and get really specific? All of a sudden, you're not playing a one-dimensional game with only binary outcomes.
- Instead, you end up deconstructing the problem statement into many more concrete pieces. You can then say yes to some β and no to others.
- In fact, if you ask the right questions? It might feel less like pushing back, and a lot more like co-ideation.
Needless to say, embracing precision as an approach works both ways.
Because if you're the one asking for support? You can increase your chances by ringfencing your asks properly.
Specifically, you want to deconstruct your request into specific, precise, and even tactical components.
That way, you can figure out which tasks are low-effort for the other side, yet high-value for yourself.

You'll then be more likely to walk away with something useful.
π Subscribe for free to get Herng's newsletter directly in your inbox.
Ringfence, explicitly
Let's look at one more example.
Sometimes, you're not just negotiating over the here and now. You're also implicitly negotiating over implications for the future.
Because for certain tasks where ownership is blurry? People tend to wonder about the following:
- "If I take on this task β does it set a bad precedent for the future? Does it set wrong expectations and accidentally create scope-creep?"
- "If I provide data analysis support now β am I on the hook to drive all data analyses going forward? Am I walking into a trap?"
- "If I say yes today β it'll be hard for me to say no in the future for similar requests. Should I push back this time just to be safe?"
In other words: it's one thing to take on a one-off task. It's another thing if that also means altering expectations for the future.
And these (sometimes unspoken) concerns can end up becoming big bottlenecks in negotiations.
Therefore, regardless of which side you're on in these situations? It is always helpful to explicitly clarify what the implications are for the future.
For example, in this hypothetical scenario, you might say:
- "I understand that your team is short-staffed currently, although my team generally doesn't support these types of projects..." (Acknowledging the situation, but establishing your principles clearly)
- "That being said, given that I do have extra bandwidth this week, and given the importance of this forum β I'm happy to step in and play a leading role this time." (Highlighting that this is a one-off situation, and isn't intended to set a precedent going forward)
- "How about this β I can help drive initial storyboarding and get the content to 80% readiness, before passing it onto your team to take the final pen..." (See point above on embracing precision and breaking things down into specific tasks)
- "I'll drive as much progress as I can this week β and then I can play a consultative role thereafter and provide feedback whenever needed. Would that work?" (Ringfencing your time and effort commitment even further by being extra precise)
This works if you're on the other side as well.
Becuase if you're asking for a favor and sensing reluctance? Precedent-setting might be the unspoken concern for the other side.
In these situations, try being incredibly explicit in ringfencing what you're asking for.
For example:
- "I'm hoping to get one-off support from your team to publish these 3 metrics in the dashboard; please note that no ongoing maintenance is required, as we'll debug ourselves if anything breaks after this week..."
You'll then have a better chance of getting to "yes."
π Join 5000+ readers and subscribe to Herng's Newsletter for free:
Key takeaways
Whether you're trying to get support from others, or trying to protect your own time: you're always negotiating.
In such situations, consider applying the following principles:
- Figure out if you're in a "no" or "not now" situation. Then ask good questions to clarify the underlying principles.
- Embrace precision. Avoid talking in generalities; focus instead on specific tasks to identify low-effort yet high-impact opportunities.
- Ringfence explicitly. If you're asking for a favor β make clear if it's a one-off request. And if you're on the other side β find a way to say yes without setting a bad precedent for the future.
Want more like this?
- Was this email forwarded to you? Subscribe (it's free)
- Grab my slide science playbook for free
- Learn about the masterclass that I'm building