Performance and Growth

helping people do their best work

Learning Objectives

Before

Tahia had been submitting pull requests with commit messages like "fix stuff" and "more changes". Jess had been meaning to raise it for two months. She kept not doing it because it felt awkward and because the code itself was fine.

The problem with postponing is that it compounds. By the time Jess did have the conversation, Tahia had a backlog of sixty commits with useless messages, and Jess had two months of low-grade frustration coloring how she interpreted everything else Tahia did. What would have been a two-minute conversation in week one had turned into an uncomfortable one in week nine.

Feedback

Vague feedback like "your communication needs work" sends someone away with nothing they can act on; specific feedback gives them a target. The SBI format makes difficult conversations more manageable by forcing you to be specific:

Use the same format for positive feedback: "In last week's code review, you caught the edge case in the parser before it was merged, which saved us from a bug that would have affected every user of the wildlife dataset."

When you give negative feedback, do it in a one-to-one meeting. Ambushing someone in a group setting turns the conversation into a status competition rather than a discussion about improvement.

Giving feedback is uncomfortable in both directions. The first time Jess used the SBI format with Tahia, she rehearsed it three times before the meeting. Tahia's response was, "Oh, I didn't know that was a problem. I'll fix it." The conversation Jess had been dreading for two months took four minutes. The discomfort before the conversation is almost always worse than the conversation itself.

Performance Reviews

Annual performance reviews are often described as a management best practice. In practice, most of them are a compliance exercise: a form gets filled out, a box gets checked, and nobody's behavior changes. The review that actually helps someone is the one that surprises them with nothing.

That means the one-to-one meeting has to do the real work. A weekly or biweekly one-to-one with a three-part agenda (what did you do, what are you planning, what is blocking you) gives you and the person you manage a shared record of expectations and progress. When the annual review arrives, you are summarizing a conversation that has been happening all year, not reconstructing one from memory.

A few things that make reviews more useful and less painful:

If you are not sure whether a performance issue is serious enough to document formally, ask yourself: if this person were fired in six months, would I be able to explain to HR why it wasn't a surprise? If the answer is no, start writing things down now.

Training and Skill Development

Research software teams tend to underspend on training for the same reason they underspend on documentation: the return is diffuse and delayed, and the immediate cost is visible. The result is that people learn on the job in ways that are slow, uneven, and occasionally expensive.

A more deliberate approach starts with identifying the gap between what someone can do and what the project needs them to be able to do—not in the abstract, but for specific tasks coming up in the next quarter. Training that connects to near-term work is more likely to stick than training that feels like a general self-improvement exercise.

Training can take several forms:

Whatever you budget, be consistent. If one person on a two-person team gets professional development funding and the other does not, you have created a grievance regardless of the reason.

Career Development Conversations

Most managers wait for staff to bring up career goals. Most staff are nervous to do this because they do not want to seem like they are angling for something or planning to leave. The result is that career conversations do not happen until someone has already decided to go somewhere else.

The conversation is simpler if you make it a standing item rather than a special occasion. "Where do you want to be in two years, and what would we need to be true for you to get there?" is not a threatening question if you ask it every six months. To make the discussion productive:

Career development for research software engineers is complicated by the fact that RSE is still not a standard career track at most institutions. The people you manage may be trying to navigate toward a research position, a staff engineering role, or something that does not have a name yet. Be honest about the limits of what you can offer, and about what you have seen work elsewhere.

Exercises

Feedback Role-Play (8 min)

Prompt the LLM with this:

Play the role of a junior programmer on my research software team. I'm going to give you feedback about a real situation. Respond in character: push back if the feedback is vague, accept it if it's specific and fair. Here's the situation: [describe a real or plausible scenario where you needed to give someone feedback but found it difficult].

Have the feedback conversation using the SBI format. If the LLM accepts your first attempt without pushback, your feedback was too vague, so try prompting it with more specifics.

Career Conversation (7 min)

Think of someone on your team or someone you manage in a volunteer project. Write answers to these two questions as if you were that person:

Then switch perspective: write one thing the project could offer that would help them move toward that goal, and one honest constraint you would need to name.