[nkjoep]

> They should also be ok with having that suggestion rejected

I agree at one condition: explain them why their suggestions are not appropriate (out of context, lack of resources, not a priority etc...).

That way you simply teach them more about the team/company business and will help them to step up their decisional skills.

[avh02]

I agree but have to be careful with this one. I'm relatively junior and we had a lot of "it's not the time for this right now" when I believed it was... You have to win somebody over with your arguments rather than a unilateral explanation IMO. (edit: what I'm saying is - prove your explanation and convince the person of the business priorities, you can't say "it's confidential" or "we can't talk about why" or "the decision was made above our head".)

Also when your team has many priorities and are tackling many fronts and one of your frustrations - as a team - is your rarely addressed tech debt (due to business/monetisation priorities), then the team is up for demotivation.

[kelnos]

> I'm relatively junior and we had a lot of "it's not the time for this right now" when I believed it was... You have to win somebody over with your arguments rather than a unilateral explanation IMO.

Yes and no. I think the best kind of rejection is the kind that convinces the rejectee that the rejection is well and proper, certainly. But at the end of the day I want to see some measure of humility in a junior engineer. Blind trust is a bit much, to be sure, but the junior should have some grasp on the idea that they don't know everything, can't know everything, may not have all the context (context which they do not always need to do their job), and they should just accept it and move on. Some battles are worth fighting, but many are not.

Put another way: a company is not a democracy. Consensus is nice, but if we had to build consensus around literally everything we did, we'd get a lot less done. Sometimes it's absolutely fine and proper to say "we're not doing that right now, and I don't have the time to get into the nuts and bolts of why".

> (edit: what I'm saying is - prove your explanation and convince the person of the business priorities, you can't say "it's confidential" or "we can't talk about why" or "the decision was made above our head".)

Agreed, those are crappy, insulting, disrespectful explanations.

[avh02]

oh yeah, i'm definitely not expecting an on the spot explanations of every single thing, but eventually i'd like an insight in to why something was rejected (if it's a major thing), 'tis all. That can be later on in the week or when appropriate, or after fires are out or whatever.

Not saying there needs to be consensus (i.e: I agree), I don't necessarily have to agree with every single thing I've been asked to do in order to do it, sometimes a job's a job.

When I was composing that post I was thinking at a relatively coarse level of a previous experience (which to be fair is at a different level to the original article).

[kelnos]

Yes, did you miss where I flat-out say that you have to do that in my post?