Weekly Check-Ins

The methods for conducting a 1-on-1 with the engineer are not meant to be discussed here. However, a few important notes should be made.

Even though all members of the management team are in the channel, only 1 of them conducts the meeting. This allows for easily transitioning to another member of the management team if needed, as well as providing a way for everyone to better understand the needs of the both the individual and the team at large.

Check-ins are not intended for status updates on individual tickets
GitHub Projects serves that purpose.

Engineers need to come to every check-in with something to discuss
Failure to do so might indicate that the engineer is not as engaged as they should be. It is okay to occasionally not have anything to discuss but it should not be a habit.

Speaking of habits, a great resource for managers to utilize for these 1-on-1: The Coaching Habit

Use questions to help guide the engineer to find the answer on their own
When an engineer asks a question, answering that question with another question is a great way to help steer them towards answer that they are looking for on their own.

This also exemplifies our explanation of effective communication. Cutting through the mist of pleasantries to get to the meat of the sentence is critical when utilizing the whole hour given in the Check-In.

Here is a slightly modified real life example of how asking the engineer questions helps them to understand something new:

Engineer: Why do we have 3 repos?

Manager: What benefit would we gain from only having 1 repo?

Engineer: Reduces the overhead of managing dependencies. Centralization. Easy to get used to the code base

Manager: Any disadvantages to having only 1 site that you can think of?

Engineer: We need to give everyone access to the repo where they may never have to work since they are only focused on one of those sites. Long build time too.

Manager: Any other disadvantages?

Engineer: Maybe performance too. Scalability could be an issue.

Manager: What happens if we have a site breaking bug?

Engineer: It brings down the whole site! I didn't think of that!

Manager: It’s tempting to put everything into one repo. Monorepos serve that purpose. For some organizations, That makes sense. But when you have a large repo, you have other problems. Keeping things small allows us to better focus when working on those repos.

Engineer: I understand

Instead of immediately answering the engineer's question, we help the engineer answer the question on their own while also following up with additional context to help that understanding.

There is no such thing as "too much context". It is important to enforce this habit upon the engineer when they are discussing obstacles that were in their way during a project's development or their own personal development.

Remember that this is a chance to pull in anything that you have observed in their behavior in the previous week that enforces or contradicts their goals in this meeting.

Here are some example prompts you can use:

What's on your mind?

Do you feel supported?

What do you think you need to improve on this next week?