Lead Time Crunch #6

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

I’m Péter Szász, writing about my decades of engineering leadership experience on my blog, and training aspiring and first-time Engineering Managers on this path. See more about what I can offer 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 thoughts on it.

Last Week’s Challenge

Last week I brought up a situation where the newly hired engineer is eager to make radical changes in the team’s tech stack. You can read the details here before I jump into my approach.

Goals

I need to carefully balance my actions on the three pillars of Engineering Management:

• Execution: I should follow a pragmatic approach balancing technical investments with product developments appropriately; and validate Frank’s ideas technically.

• Personal: I have to make sure Frank stays motivated and increases his knowledge of our context.

• Team: I should set equal and fair standards ensuring that the team is aligned on priorities.

Risks

Outcomes I want to avoid:

• Execution: Investing in the wrong areas makes us less efficient: either ignoring the tech health or only improving that is a bad extreme.

• Personal: I hire people to increase diversity with new perspectives. Sending a message to shut up and do as we’ve always been doing would be catastrophic for Frank’s morale and engagement - and we’d miss out on using his experience and ideas.

• Team: Acting differently than the last time these ideas were suggested can break trust with the team. Radical direction switches without deeper explanation also cause uncertainty and increase the risk of burnout (see my Developer Experience notes from the latest DORA report.)

5 Questions

NOTE: This week I’m experimenting with a different format, based on a useful feedback I received. Instead of sharing what I would do, I’ll list five questions that would be the most efficient to get the critical context to inform my decisions. Regardless of the specific stories, every company, team, person, product and tech stack is different, and it can be more helpful to share my thinking instead of just the results of it. Do let me know by reaching out or commenting which format you prefer and why!

1. Frank’s proposals are essentially addressing tech debt. But how does this tech debt concretely hurt the business? Are his ideas “nice-to-have”s or concrete improvements to real problems? Are we bleeding on areas he’s proposing to improve? Are these changes answering current issues or future problems? The latter can easily lead to premature optimization or overengineering, eventually adding to tech debt.

2. Did Frank and I have a chance to ensure we’re sharing each other’s context? Does he understand the current and historical context of our tech stack? Did we explain to him why we chose not to address these issues when they came up? Do I understand what motivates him to suggest these changes? Are these solid technical solutions to concrete problems, or the signs of a new colleague fighting internal Impostor Syndrome, trying to prove their value in a new environment?

3. If we choose to implement something from his ideas, how can we slice up the improvements into small, iterative experiments? Because we don’t know the future, we need continuous feedback to ensure we’re on the right path. Rewriting a full service from scratch is rarely a good first step — taking one piece of it, isolating, and refactoring it gives faster feedback and informs us on how to continue the work. What first step would the team choose?

4. Similarly, we cannot afford to halt feature development entirely. How can we pair the product work with tech improvements? If we have to touch an area because of product needs, what changes can we make that improve code health at the same time? How would we implement this feature if the whole team can work on it, and have 2 more weeks to deliver? Would it be a worthy investment to fight for? How can I include the Product Manager in these talks so she can participate in finding the opportunities these tech improvements would bring us in the future?

5. Did I make it clear for the team why are we choosing not to do most of the good ideas, in order to be able to focus on the ones that are most impactful now? Are we aligned on the vision, the next steps, and the metrics to ensure we’re on the right path to get there? What can I do to ensure this is a mutual context for the team, including Frank?

Do you agree with my priorities? What questions would you ask to increase your confidence in making the right decision in this situation? Let me know!

This Week’s Challenge

But now, let’s move on to a new exercise for the week!

You open your inbox and find a short email from George, the Staff engineer from another team about the most senior engineer on your team. It says:

”Hey, I wanted to give a quick feedback about Hailey. Sorry for being blunt, but I need to make sure you’re aware of the problems. It’s extremely challenging to work with her, it’s been three weeks since we’ve been trying to agree on the API design between our services, and she keeps on coming up with new requirements and doesn’t listen when I explain the complexities she’s trying to push on us. Please do something about it because if it continues we’ll miss another deadline. Thanks!”

What do you do next?

Think about what your goal would be and what risks you’d like to avoid in this challenge. I’ll share my approach, probably in the form of a few questions I’d ask, next week. If you don’t want to miss it, sign up here to receive that, and similar weekly Engineering Management brain-teasers in the future:

Until then, a small piece of inspiration to match last week’s challenge:

source

See you next week,

Péter