The Boundaries Nobody Taught You to Set at Work
Why the categories that protect your personal life are the same ones quietly collapsing in your professional one
A few months ago a colleague forwarded me a screenshot of a Slack message her director had sent her at [9:47pm on a Sunday]. It said: “no rush.” Three paragraphs followed. She asked me whether she was being unreasonable for finding it stressful.
I think about that “no rush” a lot. It’s the sentence that does the work of pretending a boundary is being respected while quietly relocating one. The director isn’t asking for a response tonight, but the message exists, and now it’s in her head, and the cost of carrying it until Monday morning lands on her, not him. By the time she sits down at her desk on Monday, he’s already gotten the benefit of having offloaded the thought.
Engineers can usually tell you exactly where their systems break. They’ve drawn the dependency graph. They know which queue backs up first when traffic spikes, which alert fires before the customer-facing one, which on-call playbook is wrong but hasn’t been fixed because nobody’s had the calendar room to fix it. They know all of this in granular detail.
Ask the same engineers where their own limits are and the answer gets vaguer. Most of them have only located their limits retroactively, by exceeding them. The first signal was burnout, or an incident, or the resignation letter they composed in their head during a retrospective and didn’t send.
There’s a list of personal-boundary categories that is commonly referred to in therapy contexts (time, emotional, intellectual, material, financial, and a few others). I’m not going to march through them, because the marching-through is part of how this kind of thinking gets made useless. What I want to do is talk about two of them, because they’re the two I see violated most often in engineering organizations and almost never named.
The first one is time
The on-call rotation that doesn’t end when you go off-call because a system you own is acting up and the new on-call doesn’t know it as well as you do, and you can’t quite let it go. The sprint that’s been at “120% for one more quarter” for the last four quarters. The Slack message at 10pm that says “no rush.” None of these is a single dramatic event. Each is the small ongoing erosion of the assumption that your time off is yours.
The thing that keeps these violations going is that they’re never planned and almost always rationalized. Nobody decides on Monday morning that the team will work nights this quarter. What happens is a series of individually defensible choices (we have to ship this, the customer is escalating, Marcus is out so somebody needs to cover), and the cumulative effect is that the team’s time has quietly become unbounded without anyone naming the policy. I wrote a while back about what happens when organizations treat human capacity as if it has no burn rate; this is what that looks like in the daily texture of a job. The cost is borne by individuals. The benefits accrue to the org chart.
When somebody finally does name it, the response usually isn’t “you’re right, we have a planning problem.” It’s “we’re a high-performing team” or “this is what shipping looks like,” which are narrative covers for the fact that nobody wants to do the harder work of actually scoping down. A real planning conversation would mean telling someone, whether a customer, a VP, or another team, that their thing isn’t going to happen on the timeline they wanted. The unbounded-time policy is what you adopt when you don’t want to have that conversation.
The second one is harder to see
The other category I want to talk about is intellectual: whether your thinking gets engaged with or dismissed. This is harder to see because the violation often looks polite.
The version I see most often goes like this. There’s a design review. Someone presents a proposal. Two senior people in the room have already talked about it offline and have a view. The presentation happens. Someone raises a real concern, not a stylistic one but a real structural problem with the design. The two senior people exchange a look, one of them says “that’s a good point, let’s take it offline,” and the meeting moves on. The decision was made before the meeting. The meeting was a performance of deliberation.
This is the same dynamic I wrote about in the bike-shedding piece, just dressed up. The Law of Triviality describes meetings that spend forty minutes on the color of a button and fifteen seconds on the database migration. What’s underneath that pattern is the same thing that’s underneath the design-review theater: the room engages with what feels safe to engage with, and routes around what doesn’t.
The person who raised the concern leaves knowing they were not engaged with. They might not articulate it that cleanly. What they’ll say if you ask is something like “I don’t know, the meeting was fine, I guess.” But next time, they’ll think twice about whether to raise the concern at all. Multiply this across a team and a year, and you have an organization that’s stopped getting its early-warning information, not because nobody has the information but because the people who have it have learned that surfacing it costs more than swallowing it.
I’m wary of the word psychological safety here because it’s been worn smooth by overuse, but the underlying observation is right: a team where reasoning gets engaged with on its merits surfaces problems weeks earlier than a team where reasoning gets routed through politics. Weeks earlier is the difference between a fix and an incident. My ACT-based piece gets at the version of this that operates emotionally rather than intellectually. The principle is the same: the information your team isn’t surfacing is information you’re acting without.
So what do you actually do
I want to be careful here, because this is the part where this kind of essay usually goes wrong by getting tactical and bossy. The honest answer is that most of the moves available to an individual contributor are small, partial, and don’t fix the system. They just give you a slightly better position inside it.
The one move that has held up for me is this: you can only describe your own behavior, not other people’s. “You need to stop paging me at 10pm” is a request that the other person can refuse, and most of the time they will, by ignoring it or by labeling you difficult. “I check Slack at 8am and 5pm. For anything that needs me sooner, page me through the on-call system” is a description of what you’ll do, and what you won’t, and how to actually reach you when it matters. The framing change is small but the difference in how it lands is not.
The same thing applies to the design-review case. “You need to engage with my ideas” is a complaint. “I’m going to put my analysis in a doc 24 hours before the meeting and ask for written reactions to specific questions” is a process change you can actually make. It doesn’t fix the underlying dynamic, since the senior people may still ignore the doc, but it puts the dismissal on the record, which changes what you know about the organization.
There’s a related point I made in my creative-procrastination piece that I think applies here: when ownership over something is uncertain, the rational response is to limit the depth of your investment in it. You don’t build a house on land you might not own next quarter. The same logic operates in reverse on boundary-setting. Until you’ve defined what you’ll protect, you can’t really invest in protecting it, which is why people who have never named their limits often don’t experience them as having been violated until well after the damage is done.
And that’s the part of this I keep coming back to. Naming a limit isn’t really about getting the limit respected. Most organizations won’t, at least not the first time, and not without friction. The reason to name it anyway is that the response, whether the limit gets treated as legitimate or as inconvenient, is the most reliable signal you’ll ever get about whether you’re somewhere worth staying.