moonpompey

Ah. kragniz must be the Damien Conway of Python.

I'm going to take a different tact here, because while the top-voted posts ("don't be a jerk then") are probably good advice, it's not the easiest message for anyone to receive.

Consider this: most people will like working for a lead who gives them a lot of value. This isn't necessarily an "education" -- that's not a really tangible thing that directly improves their situation, and it feels bad.

What a team lead can do, that does improve their situation, is allocate work that gives people the opportunity to grow. Work allocation is one of best ways to mentor a junior engineer, if you give them the right work. Andy Grove touches on this a little, when he describes "task-relevant maturity." Beyond that, engineers need projects they can point to, that show off the upper ranges of their abilities, in order to experience career growth.

Beyond that, the usual team-lead skillset applies: providing cover to do good work (redirecting bullshit), long-range vision and planning, and reducing uncertainty. Hope this helps.

One of your long-term responsibilities is to grow your team so everyone is more effective in the future. To elaborate a little more on #1, the primary tool at your disposal is the ability to allocate work. It's important to allocate work in ways that are both achievable and meaningful to your team's growth. This means two things:

(1) Breaking projects into small enough chunks that they can be taken on by a single engineer.

(2) Coalescing small tickets into bigger projects so that they can be taken off in a larger chunk.

It's tempting to give all the small tickets to junior engineers, especially close to a release, but occasionally giving people projects that at the 90th percentile of their capabilities both gives them skill growth and gives them something to point to as an accomplishment come performance review-time.