I'm looking for a new job and I've recognized a pattern at some of my previous places that I'd like to correct. I usually don't gain enough trust to influence process in a positive and lasting way. I've found most companies are very focused on business priorities, and for good reason. Many of these issues are or could quickly become existential issues. It's also a complex system with people with various goals and constant change.

I've learned what I want. I want a good, hopefully interesting job, where the people are nice and reasonably competent, and I make a decent wage. Then I want to go home. I have hobbies/health/interests to maintain and explore, and demands on my time will only increase. I'm happy to work extra in case of emergency, but I see no reason to work like I'm in a startup when I'm not being compensated that way nor was that part of the original agreement.


I'm looking for strategies to:

  • Gain trust in a new environment so I can maintain quality and avoid unnecessary emergencies
  • Set boundaries so I can only work extra when there are real emergencies, instead of each time there's something new to learn, some arbitrary deadline no one agreed upon, or something else we could've planned for


How do you gain trust in a new environment? I've seen other developers do it by working extra hard for the first couple of months to deliver things faster or fix languishing issues other developers haven't had time allocated to fix. I'm generally against this approach but I've seen it used effectively (though usually as a springboard to new projects/promotions). It sets a bad precedent and makes it harder to set boundaries in the future. Otherwise I like it, and if it was temporary I'd be all for it.

The only other way I can think of is learning more about people (learn their names quickly, their interests, and listen to them). I personally prefer to interact with people through good and interesting work, but hobbies are cool too. This approach also seems very slow.

Looking for more ideas to gain trust with management (as well as co-workers, but I usually don't have issues there).


Onto the second (related) question. How do you set (and when do you reinforce) boundaries at work? I've heard of a couple strategies that I'll list below... but the closest I've gotten is just pointing out issues in the process (this ticket doesn't have AC, if I need to track down AC that takes more time. I'm happy to do it, but it obviously takes extra time that hasn't been allocated). Doing this is not a recipe for setting boundaries, it's a recipe for isolation. You get labeled as a complainer, rather than someone who's trying to do 2w of work in 2w, or someone who's trying to increase the health of the systems within/on which you work. Second closest was burning out a little. I'm looking for new ideas.

Quick other strategies I've heard of and flaws I can see:

  • List your tasks and ask your boss to prioritize them, pointing out that you don't have enough time
    • This seems a bit confrontational to me, like it would damage the long-term relationship if you don't do it carefully
  • Simply saying no
    • Also seems confrontational/damaging
    • Very vague... when do you say no? to what? how?
    • This also requires Business-Analyst + PO type work: you need to evaluate/get high-level estimates for incoming work and always know your current capacity so you can successfully back up your "no", or tell when you'll be able start on the new work.
  • Conditional "no"s (similar to the above bullet), where you say "I can do that, but I'd need X training first, or I'd need some current project delegated)
    • Similar issues to above-- you really need to be on top of personal planning, rather than relying on the people who usually do that (POs/PMs/etc). This is mostly fine (especially as you get to more senior levels), but as always, takes more time and reduces the amount you can do when you're not planning

I want to have a good professional relationship with the people that I work with, but not at the expense of my time outside work or my personal and professional goals. I need to be able to (at the bare minimum) keep work at work. Ideally I'd keep the software/processes I work on/in maintainable and even fun to work with!

Thanks so much for reading and I'm hopeful to lean on your wisdom to create a more sustainable work life for myself so I can grow, accomplish more, and have a happy work/home life.

  • "List your tasks and ask your boss to prioritize them, pointing out that you don't have enough time" If your business is using Agile, this should just be a part of the process; it's a key part of how Agile is supposed to work.
    – nick012000
    Commented Jun 13, 2021 at 23:43
  • Why not apply for govt positions?
    – Kilisi
    Commented Jun 13, 2021 at 23:44
  • 1
    Sorry, I'm unsure what the connection is between trust and boundaries? Are you saying that by having the trust of management, boundaries won't be stepped over? Commented Jun 14, 2021 at 6:17
  • 1
    @mattfreake I believe the OP's reasoning is "I can gain trust by volunteering to do things I wasn't asked to do, but that goes against setting boundaries for what I am expected to do without being asked."
    – B. Ithica
    Commented Jun 14, 2021 at 8:50
  • 1
    @B.Ithica exactly. I need to gain trust to be able to refine the systems we use to build software so that they work for everyone involved, not just the business, even if the business is the main focus and some sacrifice is expected. I also need trust to set and reinforce boundaries. Like I mentioned there are real emergencies and I'm happy to be a team player, but regular unplanned OT (IMO) should be reserved for those with equity that matches their commitment to the project (regular being an important word here). Commented Jun 14, 2021 at 16:18

4 Answers 4


Okay, there's a lot to unpack in your question.

First up, you're conflating two separate things here:

How do you gain trust in a new environment? I've seen other developers do it by working extra hard for the first couple of months to deliver things faster or fix languishing issues other developers haven't had time allocated to fix.

The developers are not earning trust because they're 'working extra hard'. They're earning trust because they're achieving results. This isn't a meaningless distinction. I've seen people go overboard and work 10 hour days and they aren't trusted any more than before - because the 10 hours didn't actually achieve solid results. And I've seen people put in fewer hour than their contracted time, but are still greatly trusted - because they're getting good results.

If you want to be trusted, focus on:

  • Being transparent
  • Not letting small problems turn into larger ones
  • Not causing problems in the first place

Second, this really highlights what might be causing the issue:

List your tasks and ask your boss to prioritize them, pointing out that you don't have enough time - This seems a bit confrontational to me, like it would damage the long-term relationship if you don't do it carefully

You're not supposed to have a 100% harmonious relationship with your boss. That might sound bad/wrong, but think of it this way:

  • Your boss has a boss of their own; that higher level boss wants something to happen by such-and-such a date. It's important!
  • Your boss has subordinates who feel that the date isn't realistic/ahievable/whatever.

This is a faultline, and a lot of corporate scheduling involves resolving this dissonance. Maybe the boss is right, and the issue is that lower priority stuff is causing the problem - and that by doing reprioritization and restructuring, the date can actually be hit. Or maybe the subordinates are right, and there isn't a good way of hitting the date. Figuring out the path forward involves pushback from both groups.

But that's where you're failing - and why you're getting hit by burnout. Because you're not doing your part in the picture!

If the boss says, "We need XYZ by the end of 2021" and you don't feel that's achievable, you need to tell them that. If they contest it, you need to lay out the reasons why you won't hit the deadline.

In other words, you're responsible for being the other part of that faultline. And if you decide not to? Then management pushes more and more aggressive schedules (why not? nobody is telling them that their schedule won't work!) and the people trying to achieve them are getting burnt out.

Sound familiar?

In short, what you wrote in your "This doesn't work" section is actually exactly what you should be doing:

List your tasks and ask your boss to prioritize them

... and estimate how many hours you think the tasks will take. It actually is your boss' job to prioritize your work. It's your boss' job to determine which deadlines will get missed.


OP, I see you're getting tied up in the mechanics - jira vs whatever.

This really doesn't have anything to do with whether you use Jira or notecards or animal entrails. The important part is being upfront, transparent, and confrontational about a schedule dissonance.

Let's take your "2 weeks plus maintenance" example. Here's how the conversation with the boss should go:

  • "How many hours will the task take?"
  • "About 80."
  • "So you'll be done in two weeks."
  • "No. Maintenance typically takes up about 15 hours per week, and I'm tasked with doing the urgent report for the finance group, which will take another 10. So a tentative date, assuming nothing else comes up, would be about 4 weeks."
  • "Four weeks! It's only an 80 hour task."
  • "... and I could get it done in two, but only if someone else handles maintenance and the finance report - and nothing new comes along."

... do you see what's happening? You're letting the boss know: hey, as-is, this task won't be done in 2 weeks like you want. If it absolutely needs to be done in 2 weeks, there is a path forward - but it all depends on whether maintenance and the finance report are okay getting bumped until after the task.

Aka: the boss assigns the priorities, but you're ultimately responsible for pushing back if there's an unrealistic date (which there would be, if you needed to do all three ASAP.) And if anything new comes up, it's once again up to the boss on what gets the priority: the 80 hour task or the new one.

  • "It's your boss' job to determine which deadlines will get missed." — this is a good one. "It actually is your boss' job to prioritize your work." — this I would correct. Hearing about the boss literally prioritizing brings me into bad shivers. The boss likely has less technical understanding of the issues at hand, and is definitely not as aware of dependencies as OP is. So I would re-word it as: The boss should attach a value to each deliverable, and then OP could offer various itineraries on to how to get there. Then the boss could pick the one they favor best.
    – Levente
    Commented Jun 14, 2021 at 20:00
  • Yeah, this. I have no problem with people telling me: "IF we want to do this, then we have to postpone this and assign X or Y to this". I do get ticked off by people complaining about "not enough time" and "that's not possible". Time is a limited resource, given to everyone in equal measure. 24 hours every single day, of which 8 are set off for this. How should we spend it, in order to maximize the probability of reaching our goals? I am presenting a target state, it's my oompa loompa's job to see how we can get there. Hypotheses are accepted!
    – Stian
    Commented Jun 15, 2021 at 5:52
  • re achieving results... the point I was trying to make is that new developers to a project come in unencumbered and are usually able to take on some more "clean up" tasks (pay down some tech debt). this gets them points with management, who's not scheduling time to do that work, which is slowing the rest of us down (though the rest of us still need to review these refactors and make sure they don't introduce new issues, so there's a cost there too, depending on how review happens at your company and how junior the new person is) Commented Jun 15, 2021 at 13:21
  • @StianYttervik what if you do the math (as a developer) and things aren't going to add up, and you tell your boss, and they just say "do your best" and don't move deadlines? Just keep communicating but avoid working extra? Commented Jun 15, 2021 at 13:22
  • re harmonious relationships with management: I think this is where most of my confusion comes from. I get that as an IC I miss lots of the telephone game above me. As I've gotten a bit more senior I've become aware of more of this. I still don't really understand it. We have these (agile) systems we use to build software, but we refuse to refine them any further. e.g. I've been on teams that add a task for us to track support work if we have internal users. I've also been on teams that refuse to do things like that... but still want us to do support work and 2w of feature work... Commented Jun 15, 2021 at 13:24

I feel like you're relating two unrelated things. But they're each quite easily answered independently.


You gain trust by being good at your job, delivering results on time and in budget, and by, when asked for your opinion on something, being right. This can be done quickly or slowly depending on your role and activity level (I guess?), but this is how it is done.

  • You cannot gain trust by working hard
  • You cannot gain trust (except in the most antifunctional organizations) by knowing peoples' names or sharing hobbies or anything else personal

You gain trust by being reliably effective and effectively reliable. End.


You set and enforce clear boundaries by setting, and enforcing, clear boundaries. Most of what you've written under this heading in your Q just... doesn't deal squarely with realities of work as I've experienced it, so I can't reply directly. It sounds like you may have some bad habits that you'll need to let go of. For instance, 'pointing out issues in the process' is utterly irrelevant to setting boundaries for work-life balance.

Much about how this works when the rubber hits the road will be dependent upon the method used to assign/track work, the cadence of your connection with superiors regarding workload, and other specifics. But, broadly speaking, don't work outside work hours. Do as much good work as you can in the time you're being paid to work. Communicate openly with whomever you report to about priorities and workload.

In your communications on this subject, you should:

  • Be honest
  • Be proactive
  • Have a productive focus
  • If you have questions, ask them.
  • If you have blockers, discuss them.
  • If anything is unclear, clarify it.

You really don't have to make things complicated.

  • Thanks for your answer :). The reason I see them as related is they both sort of break down when it gets harder to get things done... and it gets harder to get things done when there's more pressure, as we accumulate tech debt (this is sort of what I meant by "inefficiencies in the system", if we can't regularly address tech debt... then the system becomes increasingly inefficient and it's harder to do things). This comment has more of a summary: workplace.stackexchange.com/questions/173612/… Commented Jun 15, 2021 at 13:08
  • I guess that's what I mean, though - what does tech debt have to do with "trust" or "boundaries"? It doesn't. You're making "boundaries" seem really difficult by incorporating process improvement, technical debt, scope creep... these are all issues impacting development, for sure, but that has nothing to do with work life balance!
    – Alex M
    Commented Jun 16, 2021 at 18:13
  • For me they seem to because if I don't push back against little intrusions into regular agile process, then they become more frequent and take up more time, which either comes out of my free time, or causes work to roll over (making me look bad/lose trust). If I do push back each time one of these happens, then I'm the nit-picker. The in-between state is evaluating each request as it comes in, estimating it on the fly, and pushing back against large out-of-band requests (or pushing them back into the agile process). Commented Jun 16, 2021 at 19:53
  • If something consistently isn't working with the tech, we're supposed to bring it up and evaluate the risk/fix. If something isn't working with the process, but it only causes pain for devs, then it's this uphill battle where you weigh your reputation against how much you want to have a good environment to work in or how much free time you want to spend doing extra work. Commented Jun 16, 2021 at 19:54
  • OK, now I think you do have a fine question, it's just the opposite of what you think it is. You have a difficult problem here to do with a poorly managed work environment, but that's still entirely separate from 'how to build trust' and 'how to maintain boundaries on work life balance'. Those are not the problems - the inefficiencies and endless process creep are your real problems.
    – Alex M
    Commented Jun 16, 2021 at 22:39

I'm looking for strategies to:

  • Gain trust in a new environment so I can maintain quality and avoid unnecessary emergencies
  • Set boundaries so I can only work extra when there are real emergencies, instead of each time there's something new to learn, some arbitrary deadline no one agreed upon, or something else we could've planned for

You're looking for a utopia. I'm not convinced that this exists, but if you happen to find it, be sure to share the coordinates with the rest of us, would you?

Most kidding aside, you are dismissing the biggest fact of work: the only constant is change. To suggest that you only want to be called in when there are actual emergencies versus perceived emergencies assumes that everyone agrees on what an "emergency" is, and to dismiss deadlines as arbitrary is to dismiss the concerns of others and their own timelines out-of-hand, which is beyond your pay grade to do so.

To step back a bit, let's talk about trust. Others have mentioned this before, but the only way you gain trust is to be depended upon and consistently deliver when asked, no matter the circumstances. This is not easy as it means that there could be long days in the office (physical or virtual), and it could also mean that you don't get to go home until it's dark because production is on fire.

But the trustworthy ones are called in because they can be trusted to do what it takes to put the fire out, as well as plan ahead or raise concerns with the environment such that certain fires can be mitigated. To be blunt, you don't know what your problems are until you encounter them, and one or two long nights at work give you that perfect opportunity to accurately identify them as well as come up with a plan to eliminate them.

You're not implicitly trusted when you show up, and just doing stuff doesn't automatically earn trust. So I would recommend that you take the approach of being a team player and being flexible enough to work when necessary for the good of the team or company as opposed to viciously guarding your work-life balance as absolute or non-negotiable. Some companies are more understanding if you have dependents or other obligations outside of work that you can't stick around for, but if you're just going to go for a bike ride afterwards, don't expect a whole lot of sympathy there.

This isn't to say that you should be beholden to your job at their every beckon and call, especially if you're not on-call. You should be able to have conversations with the team and your leadership in regards to situations like that, which usually go something like, "We're starting to spend a lot of time fixing these issues on the weekend. Would it be possible to dedicate some cycles this upcoming sprint/week/month to address the root causes of that?"

To that point...

You need to have courage to talk about your own deadlines and priorities. A situation like this is actually pretty common:

...[T]his ticket doesn't have AC, if I need to track down AC that takes more time. I'm happy to do it, but it obviously takes extra time that hasn't been allocated.

The big thing that comes out of this statement is that you are taking in a question/ticket and you "need to do X". Having an attitude or mentality where you "need to do X" and it'll be longer is already setting you up for burnout, because it puts you in the mindset that somehow, doing X isn't what you're here to do, and it takes you out of your normal work flow.

There is absolutely nothing wrong with guarding your time and your 40 hours/week. I do it all the time, and I'm a dev team lead who opines on occasion about wanting to get a little more done on a lazy Sunday afternoon (but doesn't). However, the idea is that this is a trade-off, and most companies have a clause built-in that mandates that you work when you ask them to even if you're not paid for it.

Instead of framing it so rigidly, you're going to have to be flexible and say that you're willing to help out if production is on fire or there's an emergency. There's no need to quantify what those mean, and it gets you that level of trust you seek if you do hop on to address issues when called upon.

Ultimately this is a mindset change, not a "what do I say" kind of thing. You're going to need to start thinking more like a team player and more about the benefit of everyone, and when you get the trust of being able to consider others, then you get the positive/bright side of being able to assert your own boundaries and wishes. Working with others gets a lot easier if you work with them as opposed to aggressively staking your claim.

  • Excellent answer! I think the way you're wording this is definitely part of the puzzle I want to solve. I think "results" are a big part of it (from another answer as well), and I think where I get hung up is in two different places: 1. The "need to do X" part of your question. I'm trying to say the only planning time allocated in my schedule are agile meetings, so if I have to do ad-hoc planning I can either take longer and do a good job (especially if it involves AC), or I can give a quick estimate that may need to be revised later (causing frustration on their end), or may be missed Commented Jun 16, 2021 at 1:02
  • 2. This also applies to (1). I did what you're suggesting, and it burnt me out. I was always ready to help. I wasn't perfect with the estimates (especially after burnout), which definitely lost me some trust. Even before missing estimates though, I got things done, and I did little extra things where needed, often at the expense of my free time. I really don't want this to be a "you only get 40 hours" type relationship... but this is why I'm asking the question. When and how do I push back to both avoid being the "only 40h" guy, or "we need to strictly follow agile" guy... Commented Jun 16, 2021 at 1:06
  • Without allowing myself to be taken advantage of? I feel like trust is earned, and if one party is more about getting as much from the other as possible... then you sort of need to set up systems to prevent that. I'd much prefer a cordial relationship. Commented Jun 16, 2021 at 1:07
  • I feel like I've succinctly answered your question; ultimately, you should stop thinking about the clock and estimates (even the Agile manifesto favors individuals and interactions over processes and tools) and start focusing heavily on your contributions to the team. Trust is not something that can be simply achieved; it must be earned. Everything else follows from that.
    – Makoto
    Commented Jun 16, 2021 at 2:11
  • I guess I'm still unsure what to do when I act in good faith and pick up as much as I can and get regular results (even if they aren't perfect). After doing all that I expect to be able to have some say in the process (injecting more stability in terms of maintenance or hours), but if/when it's decided that our priorities haven't change... then I feel like I need to assert myself and give better estimates, keep JIRA very up-to-date (rather than relying on AC/work from PMs), and be very conscious of my capacity. I'm asking how to do that, because the previous approach... Commented Jun 16, 2021 at 2:19

You may be wildly overthinking this

  1. When you are asked to do something, reply with these seven words: "Great, that should take about N days." That's the whole thing. There's nothing more to it than that. There is nothing else to think about, worry about, or be concerned about. As a programmer, that's the only thing you ever have to say in your whole career.

  2. You make a number of comments such as "List tasks and ask your boss to..." and "need training..." In programming: never, ever ask your boss to do anything. It's the number one no-no in software. The entire, total, nature of programming is that you are every minute solving problems yourself. Anyone who goes around asking for help tends to not make it.

Say you're already doing something, and someone comes and asks you to do X. Simply say (as you now know!) "Great that will take about 12 days..." and then add "at the moment I'm working on sql [use ONLY a one-word description, do NOT expand in ANY way] for Steve [state the person's name]"

  • do not concern yourself with priorities or what should come first. keep that out of your mind

  • simply state "at the moment I am working on sql for Steve" and then look blankly at the person. do not think more about the issue or say more about the issue. just state that fact - that's it

  • if someone senior to you says "stop doing X and do Y then - you guessed it - stop doing X and do Y.

Consider a football game (think of American-style football).

The company shareholders are like the quarterback. Management is like the line. Team leads are like the backs.

If you're a programmer, you're like the football.

  1. Do exactly what you're told

  2. Essentially: think and say nothing, ever

  3. Take the incredibly high pay, work 38.00 hours only, and go home. Every year get even more spectacularly high pay

If you do 1, 2, 3 everyone will love you and you will get massive raises everytime you change jobs (ie, once per year) and life will be a breeze. It's really that easy.

Note, if as a programmer you can't (indeed, immediately, with no hesitation) guess N for any given task, realistically you can not work in the field. It would be like saying "I'm a guitarist but I can't tune a guitar". If you are "bad at" estimating time, take a reasonable guess, immediately with no hesitation. NEVER, EVER, EVER dither about guessing "N" for a task. It's the "only mortal sin" a programmer can make.

  • 2
    There's a really good answer in here, hidden amongst some crazy bits. Commented Jun 14, 2021 at 13:55
  • 1
    cool - put in an answer, @mattfreake
    – Fattie
    Commented Jun 14, 2021 at 14:08
  • Fair enough. I struggled to clarify what the OP wanted, so fair play for putting an answer together Commented Jun 14, 2021 at 14:33
  • 1
    matt - we rock !
    – Fattie
    Commented Jun 14, 2021 at 14:33
  • 1
    hi @Throwaway1929394 - you are wildly overthinking it. as you a programmer you have to be able to guess how long something will take, based on your experience of working in that system. just take a guess your comment about systems, feedback etc are truly not relevant. nobody wants to hear anything like that from a programmer. don't involve yourself with such issues. just state your estimate in days, with a smile, and move on
    – Fattie
    Commented Jun 14, 2021 at 17:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .