[kelnos]

> What can't really happen is for a junior to suggest work.

Junior engineers should feel welcome to suggest work. They should also be ok with having that suggestion rejected or put on the back burner because it's not pertinent to the current product/business goals.

Depending on how the company is run, the senior can make the call, or involve a product owner, as to whether the junior's suggestion is something that they should be working on or not. But I think the OP's point about tone is important: being dismissive about it is demoralizing and isn't helping the junior grow. Explaining why (to borrow the example from the article) it might be ok to lose a week's worth of data, or even why they just currently have bigger fish to fry, but will revisit the idea later... that shows respect for the junior's desire to grow and establish ownership while giving them a taste of knowledge and experience that you have but they don't.

[NamTaf]

Agreed. When I first started at my company, our graduate programme involved a ‘showcase project’ where we had to think up a problem to solve within the business.

It certainly wasn’t effective in allocating effort - most groups did a month of research only to find out why it wouldn’t work, and those ideas that were pursued were 90% dropped after the showcase presentation. However, failure had important lessons in learning about the business (10k+ people on size) and how to explore it for info.

In a few specific cases, they became genuinely useful ideas that were implemented. Mine, for example, was because it involved us as grads identifying a missing capability in one arm of the business that had been solved elsewhere, however the two arms never talked. The net result was a significant safety mechanism improvement.

In the overwhelming majority of cases, juniors lack the business understanding to vet ideas for those that may work. But I genuinely believe that giving them some rope to go and find out why their ideas don’t work, as opposed to just saying so, can be very valuable for a variety of reasons beyond just learning to logic through problems.

[duncanawoods]

Yep, poorly expressed on my part. I meant it more that we can't really expect juniors to choose their own work and work off the own view of priorities. The discussion itself can be valuable but more often than not can't happen.

The pathological case is the newbie who fights every request to complete high priority work in preference to their own ideas when they don't have enough understanding of the business to have such strong opinions. They slow everything down and the continuous resistance can make them toxic to work with.

[PakG1]

These are excellent opportunities to sit down with the junior engineer and explain how organizations are complex, incomprehensible decisions are often made from a birds eye view with a longer-term view (in good organizations), and that we all need to be patient and teachable to grow. I've seen too many older people who have never gone through this mentorship, and they still can't understand why nobody listens to them or promotes them. They just become very angry toxic people. Nip it in the bud when they're young to help them get the right attitude of wanting to learn and wanting to collaborate with others; that could be the difference between someone becoming a productive and successful person later in life and someone becoming a bitter and unsuccessful person.

Yes, there are some young people who can't be helped. But I imagine most can be helped. I used to be young and arrogant too.

[duncanawoods]

I think quite a few successful founders fit in the "can't be helped" category so its not the end of the road. Those born to be the tip of a spear can be nearly unemployable as juniors.

[sprafa]

Feel like I struggle with exactly this - I had to get fired to get my attitude to change and I'm still working hard at it. Would definitely benefit from mentorship.

[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?

[dennisgorelik]

> Junior engineers should feel welcome to suggest work.

Of course. Senior developer should welcome Junior's feedback and then deliver detailed critique on the suggestion.

Junior developer should learn from it and try to make his future suggestions better.

Rinse and repeat until Junior would come up with something useful.