Hacker News Reader

Comment by justin_oaks | Hacker News Reader

> 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.

View on HN

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.

> 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.

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.

> 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!"

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.

> they have failed to run the company successfully.

And yet they're still making money :/

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?

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.

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.

This is conditioned on both parties having that level of maturity and good faith.

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.

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.

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.

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.

Aka the "Scotty principle"

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

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

It's called expectation management.

Reply on news.ycombinator.com