Coming off some annual management training, I realize that I need to write some of these learnings down, in order to actually internalize them. This is mostly a reference for me.
Most of time, engineers in particular are easy to delegate to. Often they know more than you do about their technical area, and they are intrinsically motivated to produce. But if one of those assumptions is not true, it's your job to set them up for success.
If your engineer has all the technical proficiency to pull off their project, as well as the wisdom of experience to do it well, then they are set up for success in the "skill" dimension. If this is not the case, they may need explicit coaching, usually in the form of 1:1 pairing, more vigorous code review, and more real-time feedback on their solutions.
If the engineer is excited to actually do the work because they find it fun, are motivated by the impact it will have, or are actively working towards a career development goal, then they probably are set up for success on the "will" dimension. If not, see Motivation and career conversations.
If they are firing on all cylinders in terms of skill and will, make sure you're not micromanaging their work - give them space to execute.
Feedback should ideally be real-time, but private. If you're in a meeting and you have some feedback for a team member, try to give it to them in person, privately, right after the meeting. In general, praise can be public, but constructive criticism should be in private. Never criticize in front of others.
One on ones are a great catch-all for any feedback that you did not give in real-time. See my previous blog post for more.
Some people actually do not like positive feedback. It can make them uncomfortable. That's fine, but you should still find a way to give it. One strategy is to call out that you know they don't like getting positive feedback, but that you want to make sure they know what their strengths are. Another tactic is to ask them to identify what they are doing well - and call out when you agree with them.
Similarly, some people will prefer totally direct and frank feedback, even if it's constructive. That's down to knowing the person well.
Whatever the scenario, you want to seek to understand the other person's point of view, not just make sure you cover your own talking points. They should talk more than you do. Also, keep notes on what topics you cover - if only to remind yourself later.
Motivation can either be intrinsic or extrinsic. Engineers will be intrinsically motivated if they find the work fun or if they know that it will be high impact. Extrinsic motivation could be compensation, or working towards a career goal. But it's important to realize that extrinsic motivation is fleeting - it's not sustainable if engineers are motivated primarily by monetary rewards or promotions. Those are great, and we should maximize those, but they also need to be intrinsically motivated.
How do you know what motivates someone? You can ask them, but often people will not be that self-aware. One good tactic is to ask them "What was the highlight of that last quarter/project for you"? Take notes on their responses over time, some patterns will become apparent. Retrospectives are also a great source of data here.
In terms of career conversations, you want to focus on helping the person maximize their strengths. You want them to be aware of their weaknesses, but we typically do not need to turn those into strengths - we just need to get them to an acceptable level where they are not interfering with the work.
Some opportunities for growth are new responsibilities, special projects, setting aside time for explicit learning, and having them teach others.
An inevitable part of being a manager is giving negative feedback. Maybe an engineer is really not performing up to the bar. You want to address those early - not wait until a performance review. Performance reviews should never be surprises.
You want to begin by asking open ended questions. Truly give them space to identify the problem, give their perspective and offer solutions.
Often you will need to highlight the problem. Put it in the context of the impact that it's having. If you have feedback from other people on the team, one way to phrase it is "when you do this, it can be perceived like this". Again, provide the space for the engineer themselves to come up with a solution.
If it's not happening, reset and try to at least come to consensus that there is a problem. Then be straightforward in saying that this is something we need to fix. Either way, make sure you have clear next steps and commitment, and follow up during one on ones.
You need to be aware of when people are having primordial, lizard brain subconscious reactions during meeting and conversations. I definitely notice this in myself. Try to identify what topics tend to elicit emotional reactions in yourself. The safest course of action when you realize that it's happening is to table the conversation for later. Alternatively, you can call out that this is triggering you. That may defuse the situation.