4 ms·

> Because if you promise to deliver it by Tuesday and you run into some problems, you won't be able to fulfill the promise. Instead, if you accept Friday as a d

> Because if you promise to deliver it by Tuesday and you run into some problems, you won't be able to fulfill the promise. Instead, if you accept Friday as a deadline, and you finish it by Wednesday, you can deliver it 2 days earlier. Or you can deliver it on Friday. I once had a boss that taught me an important lesson. Some other party (business unit or company, I can't remember) asked for some work to be done. He said for me to not work on it right away. I said I could get it done in a couple hours, so why not do it right away? He said it was to manage expectations and not give the other party everything they want right away or they'll come to expect it. Edit: I also wasn't to start it right away because the work may not get done at all. Some of it was to delay to determine whether the work was even necessary. And some of it was to push back to ensure that we're not ALWAYS giving in to every demand.

reactordev 3y ago
If you're reading this, this is what not to do. Plan your work, expectations of delivery should be on those milestones of sprint releases or whatever yard-stick you are using for planning. Simply doing work as fast as it comes in is a sign that you have no planning. No road map. No future outlook of feature sets. You are flying by the seat of your pants. This isn't a lesson to learn, it's an anti-lesson. Yes, don't work on things right away and deliver right away as your "customers" will expect it, but why is that a bad thing? Why can't you easily deliver features when they are ready? Why is this boss giving you such bad advice?
- deleted 3y ago
  [deleted]
- justin_oaks 3y ago
  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.
deleted 3y ago
[deleted]
batty_alex 3y ago
Not sure I agree with not starting work on it right away so you don’t finish early but, I’ve learned that constantly delivering earlier than you say can make people not believe your estimates - ditto for always being late
WendyTheWillow 3y ago
Yeah, that's... awful. The real problem isn't that you do this, per se, but that you're not incentivized to improve the business. You should want to hop on this and deliver it in a couple of hours; it's up to the business to make that something you directly benefit from.
- matheusmoreira 3y ago
  > it's up to the business to make that something you directly benefit from They never do though. People's reward for "improving the business" by being efficient is more work, not more money.
- LMYahooTFY 3y ago
  Agreed, but as someone doing software work for a non-tech company with tech-illiterate leadership, it doesn't happen. Which forces you to play this game, or you'll find yourself drowning in impossible demands because the business side doesn't understand why things they want to do are so often pivoting around their technical staff.
- pavel_lishin 3y ago
  > The real problem isn't that you do this, per se, but that you're not incentivized to improve the business But I'm not. It's not my business. I have almost never worked at a place where there were incentives to go above and beyond; few places reward that behavior with anything except more work and a cost of living raise. Having said that, I've definitely been incentivized by the relationships I've built with people: I've jumped in to fix a problem for another team because we're friendly with each other, and I've prioritized fixing some bugs because they were impacting users (and given my employer, I like our users as a class of people and want to do right by them). But I've never once thought to myself, "This nameless group of people working seven states away that I've never met or spoken to asks something of us, I should definitely prioritize it!"
  - WendyTheWillow 3y ago
    A company is nothing more than the people that compose it. If the people in the company who want you to do work don't build a relationship with you, they have failed to run the company successfully.
snarfy 3y ago
Aka the "Scotty principle" https://tinyhydra.com/the-scotty-principle/#what-is-the-scotty-principle https://tinyhydra.com/the-scotty-principle/#what-is-the-scot...
trash_cat 3y ago
It's called expectation management.

reactordev 3y ago

If you're reading this, this is what not to do. Plan your work, expectations of delivery should be on those milestones of sprint releases or whatever yard-stick you are using for planning. Simply doing work as fast as it comes in is a sign that you have no planning. No road map. No future outlook of feature sets. You are flying by the seat of your pants. This isn't a lesson to learn, it's an anti-lesson. Yes, don't work on things right away and deliver right away as your "customers" will expect it, but why is that a bad thing? Why can't you easily deliver features when they are ready? Why is this boss giving you such bad advice?

deleted 3y ago
[deleted]
justin_oaks 3y ago
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.

deleted 3y ago

[deleted]

batty_alex 3y ago

Not sure I agree with not starting work on it right away so you don’t finish early but, I’ve learned that constantly delivering earlier than you say can make people not believe your estimates - ditto for always being late

WendyTheWillow 3y ago

Yeah, that's... awful. The real problem isn't that you do this, per se, but that you're not incentivized to improve the business. You should want to hop on this and deliver it in a couple of hours; it's up to the business to make that something you directly benefit from.

matheusmoreira 3y ago
> it's up to the business to make that something you directly benefit from They never do though. People's reward for "improving the business" by being efficient is more work, not more money.
LMYahooTFY 3y ago
Agreed, but as someone doing software work for a non-tech company with tech-illiterate leadership, it doesn't happen. Which forces you to play this game, or you'll find yourself drowning in impossible demands because the business side doesn't understand why things they want to do are so often pivoting around their technical staff.
pavel_lishin 3y ago
> The real problem isn't that you do this, per se, but that you're not incentivized to improve the business But I'm not. It's not my business. I have almost never worked at a place where there were incentives to go above and beyond; few places reward that behavior with anything except more work and a cost of living raise. Having said that, I've definitely been incentivized by the relationships I've built with people: I've jumped in to fix a problem for another team because we're friendly with each other, and I've prioritized fixing some bugs because they were impacting users (and given my employer, I like our users as a class of people and want to do right by them). But I've never once thought to myself, "This nameless group of people working seven states away that I've never met or spoken to asks something of us, I should definitely prioritize it!"
- WendyTheWillow 3y ago
  A company is nothing more than the people that compose it. If the people in the company who want you to do work don't build a relationship with you, they have failed to run the company successfully.

snarfy 3y ago

Aka the "Scotty principle" https://tinyhydra.com/the-scotty-principle/#what-is-the-scotty-principle https://tinyhydra.com/the-scotty-principle/#what-is-the-scot...

trash_cat 3y ago

It's called expectation management.