When I first made the transition to engineering management around five years ago, I had been warned of the New Manager Death Spiral. I had the choice to delegate most of the technical work to my team or attempt to balance time between manager and project responsibilities.

I had been put in a position where learning the right choice here came easily. In the span of a few years, I switched from iOS to Android development before transitioning to managing engineers for both platforms. My teammates on iOS were more knowledgeable than I had ever been on that platform. With hardly any time to focus on Android development, those engineers became the ones keeping me up to speed on a quickly changing ecosystem. It was easy for me to step back and accept my role as a coach whose biggest impact was made outside the codebase.

What was harder for me was figuring out how to provide the coaching that my team needed. I still saw myself as a peer and a sounding board. The difference now was that I was directly responsible for the team’s output. When a junior engineer on my team came to me with an idea for a major architecture improvement, I immediately pointed out the complexity.

This is an interesting direction, but let’s dig into the details. Have you thought about how the migration will work? This is going to be a lot of work. Convince me that this is worth doing.

The critic in me jumped out immediately to help shore up his idea. After all, my job was to guard the team’s time and keep a high bar for our work. I had more decision power now and didn’t take that lightly. Pushing him harder was going to help him improve. I underestimated what it felt like to hear your manager immediately poke holes in your idea upon sharing it.

It surprised me when my manager gave me feedback about this at my next review. It was the first time I realized that what I said carried more weight than before, and I needed to consider how my teammates perceive my feedback.

Reframing Feedback with Gratitude

These days when an engineer on my team proposes an ambitious or creative solution to a problem, I offer something instead of criticism—gratitude. The last thing I want to be for my team is a decision bottleneck. If most ideas for improving our features or infrastructure are coming from me, our team is in trouble. When someone comes forward with an idea without my prompting, I want them to know that I’m grateful that they’re thinking beyond their current project. I want to reinforce that this is something to continue doing.

Once someone describes their idea, I ask probing questions. The important distinction from my first year of leading a team is that the questions come from a place of curiosity rather than criticism. Here are some questions I ask instead, along with my motivation for asking them.

“What’s the problem you’re trying to solve here? Why is this problem worth solving?”

This helps me understand their perspective better. Maybe I’ve underestimated a particular pain point for them. Maybe I’ve been putting too much weight on other team challenges that aren’t as pressing.

“What are the consequences of not doing this? How much effort do you expect this to take?”

In some cases, an engineer might fixate on an overly complex solution to a minor problem. Forcing them to think deeply about whether this is worth doing and how costly it’ll be can help them think about how to weigh trade-offs.

“What are some other approaches you’ve considered?”

If an engineer can only see a single solution to a complex problem, that tells me that they have blinders on and could benefit from pairing with someone—usually a more experienced engineer—to get exposure to possibilities they haven’t considered.

“How long would it take to put together a proposal to hammer out the details and start getting feedback?”

The answer here tells me whether I need to have a conversation about trade-offs. If the answer is a short amount of time, it should be manageable to write a proposal without needing to set aside time. While sometimes aspirational, I try to budget time for the team to work on initiatives outside of project work, and it’s up to them to decide how to use that time. If the answer is a longer period of time, I need to do more digging, either to figure out how to reduce scope for any investigation or to start discussing whether this is worthwhile to do right now.

Thinking Beyond the Moment

With all these questions, I still have the same end goal as I did in my early management days of ensuring the team is working on the right things and is maintaining a high bar for quality and technical excellence. What’s different now is how I use these moments to lay a foundation for someone’s growth. I want my teammates to build trust that they can think beyond what’s on our roadmap and to develop the skills needed to craft a clear and convincing proposal. Those are skills that take time and repetition to hone.

Even though I’m encouraging my teammates to refine their ideas more, I still have to say “no” to ideas. It can be frustrating to invest time in a proposal, only to have it put aside. This puts more pressure on me to explain why we’re not moving forward with it. There are lots of reasons why a project doesn’t get time carved out for it. Sometimes it’s a good solution but not the right time for it. The toughest conversation though is when a proposal isn’t strong enough or doesn’t have the support it needs. It’s an important learning moment and requires being direct. Although it can be disappointing at the moment, it makes it so much more satisfying when the same person comes forward with a great idea later that does get buy-in.

Lattice has a handful of experienced engineering managers who bring lessons they’ve learned from across the industry. At a fast-paced startup, it’s been invaluable for me to discuss approaches like this and practices with other managers who care deeply about their teams and bring thoughtful approaches on how they lead them. If you’re a manager looking for a new opportunity or want support from someone great, you should come work here!

‍