Lead Time Crunch #5

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 do 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.

Last Week’s Challenge

The previous week I described a scenario, where an Engineering Manager is doing her first skip level one on one meeting with the boss of her manager, the VP of Engineering. This is usually an important meeting, in some sense, this is the first impression she can make on the head of a department. Read the details if you missed it here before I continue with my approach.

Goals

The main goal of skip-level one-on-one meetings is to help information flow within the organization. I summarized the benefits of these various information exchanges for the respective participants:

Keep these in mind when preparing for the meeting.

Added to the above, you want to be your best self. The goal is not to give the image of everything going well, but that you’re on top of the issues, handling problems and keeping an eye on opportunities. The department head wants to walk away from the meeting reassured that you’re capable of running your team, regardless of challenges. If things go well, these skip-level discussions can be important tools in building your career within the organization.

Finally, you’re talking with an experienced, seasoned engineering leader. Pick their brain and enjoy the discussion!

Risks and things to avoid

First and foremost, you don’t want to be unprepared and send the wrong image about you and your team. Don’t treat this as a random chat, even if the invitation suggested that. Prepare.

The other end can be a small risk too; if you come overprepared and want to control every minute of the discussion, then there will be less chance for spontaneity and connection building. Make sure that regardless of the stakes, there’s some comfortable casualness in your discussion.

One of the cornerstones of managing up is “never surprise your boss”, and this is even more true with the manager of your manager, because if you surprise them, it’ll backfire on your boss too. So, unless you had no way of discussing something with your direct manager first, don’t bring up new things to their boss.

Finally, you don’t want to play politics. Don’t say anything about someone you wouldn’t say to their face, and especially don’t do this to their manager. How you’re perceived by your colleagues is more important in the long term than any current conflict. There’s one exception to this rule, but it’s rare: if you have problems with your manager that you can’t discuss with them directly for some reason. If that’s the case, be very transparent in sharing what approaches you took to address this issue before bringing it up here and what made you avoid discussing it directly.

Ahead of the meeting

Like regular one-on-ones, skip levels are also mainly for the employee. Write an agenda with the topics you want to discuss and send it to the VP of Engineering ahead of the call. This avoids surprises, gives them a better chance to prepare, and shows that you’re taking the opportunity seriously. Bring up topics that you want to have the big picture view on, and select the ones from your context that you want to share. No need to turn this into an overarching status meeting, that’s not the point — select the few most impactful topics.

Be ready to answer their questions. Focus on the big picture in preparation. Quarterly goals of the team, vision, long-term strategy. Health of your code and infra. Career goals and engagement of the people on your team. Foreseeable needs. Team health. Staffing. Budget. Most of these topics are also good for getting an executive’s opinion on, regardless of reporting lines. Where does the engineering organization move towards in technology, staffing, and product development? How do they see the overall code and infra health? Where is our budget spent? What are the priorities on their level now?

Consider bringing in your personal aspect, especially if you’re working towards a promotion with your manager. How do they see your performance? What are the main scope, responsibility, and behavior expectation differences between your current title and the one you’re aiming for? Who do they think could be a good role model for you in the organization? Any mentorship suggestions? Again, rely on your pre-existing work with your manager, this is not the time to share your ambitions first!

Since this is the first time you talk with the VP of Engineering, dust off your original 30/60/90 plan or similar onboarding document. Was there anything left over for later to do? They are probably familiar with the template of these documents, so they might ask about your opinion on it and the entire onboarding process. Refresh your first weeks’ memories.

The elephant on the table: your manager. Don’t put it on the agenda unless you have something concrete, but do prepare your thoughts about how supported you feel by your boss. The topic will most probably come up, and you don’t want to start thinking about how to frame your opinion in a sensitive, constructive, efficient way under the spotlight.

During the meeting

Just like in any other 1:1 meeting, don’t jump directly into the agenda, building a human connection makes everything smoother after. That being said, be respectful of time, show up punctual, and don’t ramble.

Take notes, but keep the discussion interactive; this is not a lecture.

Don’t panic if you receive a question you can’t answer; just commit to follow up (and deliver as soon as possible).

Don’t say yes to every request just because there’s pressure and you want to avoid a conflict with an executive. It’s OK to say you’ll think about something or that you need to discuss it with a few people to plan your approach. You also want to avoid a situation where you promise something to the manager of your manager without keeping your boss in the loop. Just note explicitly that you heard that this project is important for the VP of Engineering, and you’ll let them know how you plan to approach it.

The topic of your manager’s performance can come up directly or indirectly. Even if you have a less-than-ideal relationship, focus on the support you give them to succeed. (For example, if your manager is struggling to give you clear goals, you can mention that you wish to have more career development guidance, and that you’re regularly working together to confirm priorities to ensure there’s no misalignment. Of course, don’t mention this if you haven’t talked about it with your boss yet - again, avoid surprises.) Don’t give generic praises either; instead, mention specifically if there’s something concrete your manager did that you appreciated. It’s going to get back to your boss and it’s the best kind of reinforcing feedback.

After the meeting, share your notes and commitments you’ve made, and follow up on them on time. Make sure you get back to your notes the next time you’re preparing for a skip level 1:1 with this VP to ensure you haven’t dropped the ball on something.

How do you prepare for skip level meetings? Was there something you’ve learned after a failed one? Do you remember a particular realization that helped you after? Did I miss something from my approach above?

Let me know in the comments!

This Week’s Challenge

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

You recently hired Frank, a senior engineer, to your team. It’s been 3 months, and his onboarding went pretty well. Frank got up to speed fast, committed to production on his first week, and the team seems to enjoy working with him. However, there’s one pattern you noticed: he’s quite critical to the stack and code state and tries to push new things that he either worked with or read good things about. These are not just small improvements but radical changes, like refactoring the routing component of the application or introducing a new observability tool to replace the current one. He’s an experienced engineer, and similar suggestions came up earlier in the team — but at the same time, you have product delivery deadlines, and it seems unrealistic to make these radical changes now.

How do you approach Frank’s innovation ideas?

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

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

See you next week,

Péter