LTC#02 - EM Returning from Vacation

Hi, this is a mini newsletter for engineers thinking about management.

I’m Péter Szász, writing about my decades of engineering leadership experience on my blog, and mentoring aspiring and first-time Engineering Managers on this path. See more about what I can offer to you at leadtime.tech.

In this newsletter, I pose a weekly EM challenge and leave it as a puzzle for you to think about before the next issue, where I share my approach, one possible solution amongst many.

This being the second issue, let’s start with my “solution” to last week’s challenge.

Last Week’s Challenge

In the first issue, I shared a hypothetical situation where Alice, the EM of a team returns from her vacation finding things didn’t exactly go as planned. Check the context here if you missed it.

Before explaining my approach to this situation, a quick heads up. There are more than one good solutions for a challenge, and there’s definitely a lot of context missing, which can make or break an idea. My purpose is not to deem one solution as the only good one, but instead brainstorm ideas and show an approach that I would take in situations like this.

In this case, my goal is to balance accountability with empathy.

I want to maintain a safe space to candidly discuss bad decisions without blame, but still make sure that the consequences of these decisions are clear. We had one half-done project last week; now we have two, so we didn’t deliver anything to our users. Added to that, the context switch didn’t help developers’ focus, and the whole situation probably decreased how our stakeholders perceive our predictability and performance.

Knowing that I have only one hour to prepare for the week-start meeting, I can't do much deep discovery, and just want to cover the basics: understanding the motivations of the team to switch course of action. So, before the call, I would ping the Product Manager on the team to see if she has any context on this prioritization decision. While waiting for her answer, I’d check regular team communication channels, standup memos if there are any, etc., and browse through company Slack to see if there’s any info I should know about this new project. Note that I’m not trying to find who can I blame, I’m gathering information to better understand the context.

During the weekstarter call, I would start with a curious approach, to understand the point of view of the team. The risk I want to avoid is jumping to conclusions before understanding the entire context. If the discrepancy between planned and done work doesn’t come up (which would be strange!), I would ask directly what progress was done on the newsletter feature and what is the seasonal promo page project about.

Maintaining two ongoing projects is inefficient and costly, so going forward, depending on completeness and urgency, I would focus the entire team on one of the tasks and prioritize finishing it, so we can move on to shipping the other one too. My hope is that we’re close enough to wrapping up one of the two so that a few pair- or mob-programming sessions can help us reach a point where we can deliver something. Note that this meeting is for alignment and planning, so I would not go into any process changes.

During our next retrospective or similar self-improvement discussion, I would underline that reacting immediately to a new need shows a great service attitude in the short term — but in the long term, it backfires when we fail deliveries. Also, having a high number of Work in Progress items burns us out and decreases our predictability. Finally, the reason for documenting every major development is to make the work visible, to be able to measure and adjust how we spend our time, and to make similar conflicting situations easier to avoid in the future. If we can’t rely on stakeholders to create tickets for tasks, we should do it for ourselves. I would look for team alignment on these values and then discuss how we can adapt our processes to better live up to them next time.

Note that I didn’t spend much time on who decided to abandon the plans. First, I think it’s more important to focus on the future, and second, I don’t think it’s that important — regardless of the person, the whole team needs to know why and how we’re doing what we’re doing.

This Week’s Challenge

Let’s move on to another exercise!

Bob, a junior developer who joined the team six months ago submitted a PR that quickly received a rejection from Cecile, a Senior Engineer on the team, with the following comment:

“The test coverage is incomplete, and the algorithmic approach deviates from standard practices. Please fix.”

You are the EM on the team, who just had a 1:1 with Cecile where she vented about how she feels like being the only person caring about the code health on the product. You encouraged her, saying that she’s the most experienced on the team, and should assume the role of a guardian who keeps our standards high. The team desperately needs to improve in these because we are frequently fighting incidents related to various tech debt issues.

What do you do now?

Think about the various aspects of this situation, and how you would react seeing this PR message. I’ll share how I would approach this situation in the next issue. Make sure you’ll get it in your inbox when it’s out by subscribing now:

Until next week, a small piece of inspiration:

See you then,

Péter