4 ms·

I may have oversimplified it. There were certainly other factors at play in the boss's mind. The other part of it was to not do extra work for the third-party

I may have oversimplified it. There were certainly other factors at play in the boss's mind. The other part of it was to not do extra work for the third-party when that work wasn't specified in the contract. If you do extra work every time you're asked then it'll quickly be abused. You don't want to seem like a contract stickler, but you also don't want to bend over backwards either. It's something to keep in mind.

WendyTheWillow 3y ago
That's a maladaptive approach to the problem, is the point. You should have the communication skills to do additional work when you can and firmly say no when you can't. That's how an adult handles that situation rather than through deception and avoidance. Of course, there are external reasons that may make this more difficult, but IMO 2/3rds of the reasons people cite for doing things like this are solvable with proper communication. 1/3rd isn't, though.
- winwang 3y ago
  This is conditioned on both parties having that level of maturity and good faith.
  - WendyTheWillow 3y ago
    Not necessarily; only in the worst cases would a coworker actively harm you for not helping them once you've established that you can. I've worked with fairly immature people who can still be guided by my maturity. Of course, you're ultimately right. Some people just can't operate professionally, but I find those people to be rarer than they may initially appear. It's far more common to write someone off too early.
- throw555chip 3y ago
  I understand their position, I recently had a chat with a guy in DevOps, I'd made a request I knew would take at most, 5 minutes. He said he'd try to get to it by the end of the week. That would potentially have caused my story to carry over to the next week. I opened a Teams chat and asked about it. He said his manager told them to manage expectations. He said he'd cut me a break since I was technical and would understand and got it done in 2 minutes.
  - WendyTheWillow 3y ago
    A classic book called The Phoenix Project talks about ways to manage this. If I recall correctly, teams can fall into a vicious cycle where they only respond to immediate problems and, therefore, cannot schedule and prioritize their work. By maintaining a work backlog that gets prioritized and saying no to everything else, the team can ensure their work capacity gets respected and not get flooded with more than they can handle. So, in this way, your DevOps coworker is right. However, I don't think it's true when a team isn't at capacity, which is the scenario I envisioned when I replied. In the case where it costs little to nothing to quickly meet another team's request, the mature thing, IMO, would be to either a) do that thing or at least b) engage in good faith to put the task into your work backlog and prioritize it based on the larger impact of the overall project to the company as a whole. When a team isn't at capacity, the work would be done immediately while simultaneously reinforcing the value of the process to protect your work capacity and prioritization ability. Everybody wins. I suppose this is what I mean by "maturity"; teams have established processes to protect the team, but if the process allows for additional work, it's maladaptive to gum up the works just to keep expectations low. ...but that response is the "full PM" treatment; that's what I'd tell my boss or answer in an interview. In reality, I think of process as a "backstop" of sorts. You invoke process only when you're reaching some kind of capacity or limitation. If it's no sweat, just do it.
    - reactordev 3y ago
      This is the way. If you aren’t at capacity then the manager can step in and say “yeah, we can do that, let me get a ticket/issue/record of it so we can track it” and then proceed to work on it. This works in Kanban really well. If you are at capacity or have planned a sprint already and are midway through the run, it’s ok to say no and get it prioritized in the backlog. If you’re DevOps and the Ops part of the role requires you to respond to tickets in a timely manner then this breaks down. What we are saying though is that having a plan is a good thing. Protecting the plan is a good thing. Adopting work and helping others is a good thing. The work being adopted needs to be planned and prioritized though. If it’s a small task (like the OP said, it was a 5 minute thing) than opening a chat with them about it after creating the necessary record is fine. The fact they agreed (regardless of classification that they were technical so they would understand) shows there’s hope in your org for empathy. What you shouldn’t do is say no to adopting the work while you sit back and play wordle until you feel the person has waited the necessary amount of time. Also, don’t write systems that require 14 approvals and a shaman and waiting 48 hours for a status change before you can begin work.

WendyTheWillow 3y ago

That's a maladaptive approach to the problem, is the point. You should have the communication skills to do additional work when you can and firmly say no when you can't. That's how an adult handles that situation rather than through deception and avoidance. Of course, there are external reasons that may make this more difficult, but IMO 2/3rds of the reasons people cite for doing things like this are solvable with proper communication. 1/3rd isn't, though.

winwang 3y ago
This is conditioned on both parties having that level of maturity and good faith.
- WendyTheWillow 3y ago
  Not necessarily; only in the worst cases would a coworker actively harm you for not helping them once you've established that you can. I've worked with fairly immature people who can still be guided by my maturity. Of course, you're ultimately right. Some people just can't operate professionally, but I find those people to be rarer than they may initially appear. It's far more common to write someone off too early.
throw555chip 3y ago
I understand their position, I recently had a chat with a guy in DevOps, I'd made a request I knew would take at most, 5 minutes. He said he'd try to get to it by the end of the week. That would potentially have caused my story to carry over to the next week. I opened a Teams chat and asked about it. He said his manager told them to manage expectations. He said he'd cut me a break since I was technical and would understand and got it done in 2 minutes.
- WendyTheWillow 3y ago
  A classic book called The Phoenix Project talks about ways to manage this. If I recall correctly, teams can fall into a vicious cycle where they only respond to immediate problems and, therefore, cannot schedule and prioritize their work. By maintaining a work backlog that gets prioritized and saying no to everything else, the team can ensure their work capacity gets respected and not get flooded with more than they can handle. So, in this way, your DevOps coworker is right. However, I don't think it's true when a team isn't at capacity, which is the scenario I envisioned when I replied. In the case where it costs little to nothing to quickly meet another team's request, the mature thing, IMO, would be to either a) do that thing or at least b) engage in good faith to put the task into your work backlog and prioritize it based on the larger impact of the overall project to the company as a whole. When a team isn't at capacity, the work would be done immediately while simultaneously reinforcing the value of the process to protect your work capacity and prioritization ability. Everybody wins. I suppose this is what I mean by "maturity"; teams have established processes to protect the team, but if the process allows for additional work, it's maladaptive to gum up the works just to keep expectations low. ...but that response is the "full PM" treatment; that's what I'd tell my boss or answer in an interview. In reality, I think of process as a "backstop" of sorts. You invoke process only when you're reaching some kind of capacity or limitation. If it's no sweat, just do it.
  - reactordev 3y ago
    This is the way. If you aren’t at capacity then the manager can step in and say “yeah, we can do that, let me get a ticket/issue/record of it so we can track it” and then proceed to work on it. This works in Kanban really well. If you are at capacity or have planned a sprint already and are midway through the run, it’s ok to say no and get it prioritized in the backlog. If you’re DevOps and the Ops part of the role requires you to respond to tickets in a timely manner then this breaks down. What we are saying though is that having a plan is a good thing. Protecting the plan is a good thing. Adopting work and helping others is a good thing. The work being adopted needs to be planned and prioritized though. If it’s a small task (like the OP said, it was a 5 minute thing) than opening a chat with them about it after creating the necessary record is fine. The fact they agreed (regardless of classification that they were technical so they would understand) shows there’s hope in your org for empathy. What you shouldn’t do is say no to adopting the work while you sit back and play wordle until you feel the person has waited the necessary amount of time. Also, don’t write systems that require 14 approvals and a shaman and waiting 48 hours for a status change before you can begin work.