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 described a situation that might seem weird to some of you on the opposite end of the busyness spectrum: How to behave when you’re suspecting you’re not doing enough as a newly promoted Engineering Manager? Read the details here if you missed it.

This challenge was inspired by a now-deleted Reddit post.

I'll approach this question with my usual Goals - Risks - Questions structure:

Goals to Achieve

Switch from reactive to proactive mode: The main theme here is that you need to stop waiting for work to come to you and start creating value. This is the fundamental shift from IC to EM thinking. You are expected to do a lot of stuff that is not explicitly asked.

Build trust with your manager: You're new in the role, in a fully remote company - both factors make trust building harder. You need to ensure that your manager sees you as someone who's autonomous and capable, not someone who needs constant direction or approval. Similarly, you can probably increase trust with your team for the same reasons.

Reframe team independence as success, not failure: A team that doesn't need much intervention is actually a success metric for an EM, not a sign that you're redundant. The goal is to optimize execution, not to be constantly busy.

Grow your impact beyond your immediate team: Since you have bandwidth, look for areas where you can prove (and grow) your expertise: mentoring, cross-team initiatives, or just learning more about the business side of your organization that you were not familiar with.

Develop personally in this new role: Use this time to understand what success looks like for an EM at this company, and build the skills you'll need as the organization grows.

Risks to Avoid

Mistaking impostor syndrome for real problems: The feeling that you should be constantly busy to prove your worth is classic new manager impostor syndrome. Your value often comes from preventing problems, not just solving them, and that work is largely invisible.

Related: I wrote extensively about Impostor Syndrome felt by new Engineering Managers.

Overwhelming your bottleneck boss: The owner who "needs to think about everything" is a classic scaling bottleneck. This is where you need to start “managing up”. Rather than flooding him with more proposals, you need to make your requests easier to approve and build more trust first.

Missing implicit expectations: There might be expectations that you're not aware of, and failing to meet them. Small companies often don't have clear EM role definitions. Work on getting explicit feedback from your manager about your performance.

Assuming team quietness equals high performance: Your team being highly independent and rarely reaching out is generally a good thing, but in some cases, it might signal that they don't believe you can help them, or worse, that they're quietly disengaged. "Performing well without intervention" might be a red flag, not a green one.

Related: I had a full podcast episode about Quiet Quitting with Jeremy Brown.

Creating busy work instead of value: Don't fall into the trap of finding things to do just to feel productive. Focus on what would actually make a difference.

5 Questions

What are the explicit expectations of an engineering manager at this company? This is a small company, so they might not have anything written down — or even, enough experience managing managers. But if there's anything in writing, or if your manager or someone from HR can help clarify this, that's always a good foundation to ensure you're checking all the boxes.

How can I make my proposals more autonomous and easier to approve? Instead of saying "this is a problem we should fix," frame requests like concrete, full-fledged proposals with clear goals and success metrics. For example: "In the next quarter, I'm intending to experiment with [process change] because we see an opportunity to impact [metric]. I'll share how it went by [date], but please let me know by [date] if you disagree or need more time to decide." This defaults moves the path of least resistance for your manager from “no” to “yes”.

What would happen if I took a week off? This is a diagnostic question. If everything would run perfectly, it means you've built a resilient system. If things were to fall apart, you need to figure out why you're a single point of failure, and how can you distance yourself from the critical path.

How would I see if things are bad in the team? This helps you distinguish between healthy independence and disengagement. Would you notice if someone was struggling? If there was technical debt building up? If morale was dropping? If the answer is "maybe not," then you have some work to do in increasing visibility and deepening relationships.

How can I increase my understanding of the business to identify truly impactful initiatives? People coming from engineering backgrounds often lack knowledge of the business side. Maybe reach out to the CFO, CPO, or a more seasoned engineering manager peer to get a better understanding of the business, so you can identify what initiatives would actually move the needle.

The core challenge isn't finding more to do, it's shifting from reactive to proactive leadership and learning to create value in ways that aren't always immediately visible. Your worth as an EM isn't measured by how busy you are, but by how well your team and the people in it perform and grow over time.

Remember: if your team is truly performing well with minimal intervention, there’s a good chance you already do exactly what a good engineering manager should do. The discomfort you're feeling might not be a problem to solve, but an adjustment period to get used to a fundamentally different type of work.

This Week’s Challenge Summer Break!

I’m taking a few weeks off to recharge. It’s been almost half a year that I write this series, so I want to spend some of this time reflecting on where I want to take LeadTime in the future. I’d love to hear from you too! What value do you get from this series? What would you change? Do you have a challenge to share? Drop a comment below, send a chat message, or email. I’m grateful for your feedback.

Until then, here's a small piece of inspiration:

See you soon,

Péter

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 described a simple question from a director to a Platform Engineering Manager: How many people do you need to support a new observability platform? Read the details here if you missed it.

And thank you, Rodrigo, for inspiring this challenge. If you have a case that you’re curious how I’d tackle, reach out here on Substack or via hello@peterszasz.com.

I'll approach this question with my usual Goals - Risks - Questions structure:

Goals to Achieve

Reframe the conversation: The question "How many engineers?" is a tricky one because it misses the time dimension. I can't answer with a static number like "2.5 engineers." I need to help my director understand that this is about project planning and phases, not headcount allocation. The real question is: what's the migration timeline, what are the phases, and how does this fit into our existing platform goals?

Understand the "why" and "why now": I need to be clear about why we're doing this migration and why now, because I'll have to defend this decision credibly in front of my team, other developers, and stakeholders. Is this driven by scalability issues, operational burden, cost optimization, or feature gaps? Without a clear narrative, I won’t be equipped to answer challenging questions or make implementation decisions autonomously.

Plan for organizational impact: 80+ developers will be affected by this change. We should come up with a phased approach to allow teams to switch over gradually in the timeline best matching their own goals.

Risks to Avoid

Cost explosion: These platforms make it really easy to turn on shiny features like detailed Application Performance Monitoring that can shoot costs through the roof. The $240K quote is an estimation based on current usage patterns, but our needs are changing, and it's hard to estimate actual usage without just doing the migration and measuring.

Vendor "self-service" promises: The vendor promises self-service, but the reality might involve significant hand-holding, custom configuration, and ongoing relationship management. This could become a bigger operational burden than our current setup that developers are already familiar with.

Historical data loss: We might lose access to some historical metrics that are important beyond typical log retention periods. Traffic metrics can be crucial for sales or marketing analysis years later. We shouldn't migrate all historical data, but we need to identify what's truly valuable long-term — or make a decision to keep the old system alive in a minimal infrastructure as a read-only reporting tool.

Organizational disruption during migration: Without careful planning, we risk productivity hits across all engineering teams during the transition. The support burden during migration could overwhelm our platform team if we don’t phase carefully.

Migration complexity underestimation: Depending on how much tech debt exists in our current observability integrations across the organization, this could be a simple wrapper switch or a massive refactoring effort touching every service. In the latter case, we should look at this as an opportunity to pair the introduction of this new service with a refactoring of our current observability implementation within the product’s code.

No rollback strategy: What happens if the new platform doesn't work as promised? We need a clear path back to our current setup without losing operational visibility.

5 Questions

What's driving this migration decision, and why now? I need to understand the specific problems we're solving - scalability bottlenecks, operational overhead, missing features, or cost optimization. This narrative will be crucial when communicating with the team, defending resource allocation, or making implementation decisions. Is this reactive (current system is failing) or proactive (positioning for future growth)?

What's our current code health around observability integrations? How many places in our codebase directly call our monitoring stack versus using a centralized library? This determines whether we're looking at a straightforward wrapper migration or a massive refactoring effort across 80+ developers' codebases. Do we have the autonomy to update client code in product teams, or do we need their collaboration?

How will we measure the success or failure of the project? What specific KPIs will prove the expected "reduced operational overhead"? Maybe it's reducing our on-call volume by X%, decreasing mean time to resolution, improving developer satisfaction, freeing up Y hours per week of platform team capacity, or simply overall cost saving. We need concrete metrics to evaluate the investment.

What's our rollback strategy if this doesn't work out? Can we run both systems in parallel indefinitely if needed? How long can we maintain the old stack on minimal infrastructure for historical data access? What's our decision timeline for fully committing to the new platform versus reverting?

Which team members should lead different aspects of this migration? Who has experience with similar observability platforms? How can we distribute the learning opportunities? This could be significant professional development for engineers wanting to expand beyond our current Prometheus/Grafana expertise.

This Week’s Challenge

Moving on to the next one, let’s make it a bit lighter:

You're the recently promoted Engineering Manager of a small product engineering team at a remote-first company. After the promotion, you find yourself with surprisingly little to do day-to-day. You handle emails in the morning, approve everyone's daily plans, answer a few Slack messages during the day, and then... nothing. Apart from Monday's weekly all-team calls around which you're swamped with preparation and small follow ups, you're working maybe 20 hours a week max. Your team is highly independent and rarely reaches out for help, even though you've made it clear they should.

You've identified several process improvements and strategic initiatives that could benefit the team, but all your proposals are sitting on your boss's desk waiting for approval. He's the company owner who wants to be involved in every decision, and when you do get meetings with him, he says he "needs to think about" your suggestions. You're starting to worry — is this normal for a new manager, or are you missing something fundamental about the role? Your team seems to be performing well without much intervention, but you can't shake the feeling that you should be doing more to justify your position and grow your impact.

What do you do?

Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly managerial challenges as soon as they are published:

Subscribe now

Until then, here's a small piece of inspiration about platform engineering:

See you next week,

Péter

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, we imagined a situation where a company-wide cost-cutting layoff impacted our team, and we would need to say goodbye to John, a junior developer who’s performing according to expectations. Read the details here if you missed it.

I'll approach this difficult situation with my usual Goals - Risks - Questions structure:

Goals to Achieve

Own the decision. While the fact that cost-cutting is necessary to save the company was not your choice, how you implement it is. This is not the time to negotiate, delay, or ask for alternatives. Your director expected one name, and you needed to step up with clear leadership. The decision is made: it's John. Now execute it with dignity and professionalism.

Support John through this transition. This is one of the most important goals. Do everything within your power to make this less painful for him. Be transparent about why this is happening, offer your network for references, provide strong recommendations, and be flexible about his departure timeline. Show him the same respect you'd want in his situation.

Maintain team trust through transparency. The team will be watching how you handle this situation. Your approach here can strengthen or destroy your leadership credibility. Be honest about the financial situation while staying forward-looking. Frame this as a sacrifice for company survival and stability, not arbitrary cost-cutting for investor benefits. The world around us is changing rapidly, and resilient companies have to be careful to ensure they are ready for whatever comes.

Restructure work without missing delivery commitments. Review current and upcoming tasks to ensure John's departure doesn't derail the team. This might mean reassigning Mara to different projects, postponing some work, or redistributing responsibilities. Use this as an opportunity to eliminate lower-priority work entirely.

Shift focus from the past to the future. After processing the immediate impact, help the team channel their energy into fighting for the company's success. Connect their work to business outcomes - show them how their efforts contribute to stable financials.

Risks to Avoid

Making this about you. Letting someone go is hard enough if they are underperforming — firing an innocent victim is brutal. Still, regardless of how difficult it feels for you, it is much harder on John. Don't let your discomfort or guilt become the focus. John might be angry, disappointed, or critical of leadership decisions. Your job is to acknowledge his feelings, provide support, and maintain professionalism — not to argue, defend, or justify beyond the basic facts.

Under-preparing for the conversation. Know all the details: severance package, notice period, remaining PTO, stock options, benefits continuation. Have this information ready or know exactly when you'll get it. This isn't a discussion you want to fumble through.

Promising what you can't deliver. Avoid making commitments you can't keep in the heat of the situation. Don't say you'll "look into options again" or promise specific severance improvements without knowing what's possible. Be honest about your constraints while maximizing support within them.

Letting the team’s narrative spiral out of control. There's a huge risk of "us versus them" thinking: complaints about incompetent leadership, sales failures, or other departments’ perceived mistakes. This builds cynicism and hurts collaboration. In team settings, you can address this directly by focusing on what your team can indeed control and how everyone is doing the best they can toward company recovery. However, in the safety of private one-on-ones, you can let people vent and release some steam; these are stressful times. Acknowledge how they feel without validating their statements.

Timeline mismanagement. John should absolutely hear this from you first, not through office gossip, a different manager, or HR. Once you tell him, you need to manage the team announcement carefully. Respect his privacy preferences, but avoid a prolonged uncertainty that hurts team planning and morale. The team should also hear this from you first, not in a company-wide announcement or colleagues’ rumors.

Ignoring existing insecurities and survivor's guilt. Mara, as the other junior developer, will be particularly affected by John’s departure. Be explicit about why she's staying, what her contributions are that you’re counting on, while acknowledging that nobody can guarantee indefinite stability. Focus on current work needs and how her skills align with these.

5 Questions

What are the facts that I need before the conversation with John? Fine-tune and practice your "elevator pitch" for why this had to happen, so you can remain clear, collected, and consistent. Work with HR and your director to understand every detail of his departure package. What's the notice period? Severance amount? Benefits continuation? Stock option treatment? Can he keep or purchase his work laptop? Anticipate his questions and have clear answers. This isn't the time to say "I'll find out and get back to you" about the most basic logistics, but make sure you don’t delay the talk too much waiting for the last details.

How can I maximize support for John within my constraints? What's in your power to offer? Can you extend his notice period? Reduce his final workload so he can focus on job search? Connect him with your network for job opportunities? Write a strong LinkedIn recommendation? Be specific about what you can commit to offering beyond the generic “let me know if I can help with something”.

What work needs to be redistributed — or eliminated entirely? Don't just shift John's tasks to others; use this as an opportunity to reassess priorities. With reduced capacity, what should you stop doing? Which projects can be postponed or cancelled? How do you ensure this doesn't just increase everyone else's workload unsustainably?

How do I frame this to maintain team motivation? The team needs to understand this is about company survival, not individual performance. Connect their work to business outcomes: how does what they're building help the company recover? Besides this purpose, can you increase their autonomy or mastery within their day-to-day? (These three areas are known to motivate creative workers.)

What's my retention strategy for key team members? This layoff and the bad financials might trigger others to start interviewing. Who are your most critical, top-performing team members, and what would you do if they gave notice? Are there retention conversations you should have proactively?

The Leadership Test

This is one of the hardest challenges in management.

How you handle it will define how your team sees you as a leader. The goal isn't to make everyone happy; that's impossible. The goal is to act with integrity, support those affected with dignity, and guide your team through the crisis toward a better future.

Your team is watching. Show them what leadership looks like when things get tough.

This Week’s Challenge

Thanks, Rodrigo, for suggesting the question that inspired the following challenge:

You're leading a platform team of 8 engineers supporting infrastructure and tooling for your organization's 80+ developers. Your director is evaluating a new observability platform that would replace your current monitoring stack - a mix of Prometheus, Grafana, and some old proprietary in-house tools.

The vendor demo went well. The platform promises unified metrics, logs, and traces with "minimal operational overhead." Annual cost is $240K, which is more or less what you're spending on your current setup when you factor in hosting and engineering time.

The vendor claims their platform is "self-service" and should reduce your operational burden significantly. But you know that any new tool comes with its own setup and operational requirements: user management, configuration, integration maintenance, and the inevitable support requests when teams can't find what they need.

Your director needs your input: How many engineers would you need to dedicate to this new platform?

Think about what your goals would be and what risks you'd like to avoid in this difficult situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly managerial challenges as soon as they are published:

Subscribe now

Until then, here's a small piece of inspiration about communicating layoffs:

Did you enjoy this episode? Do you know someone who could benefit from thinking about similar challenges? I need a favor from you then: please, spread the word. Recommend LeadTime in Substack, post to your company Slack, send over to a friend or colleague, share with someone who’s leading engineering teams or is considering this path. Word of mouth is the best way to reach interested readers.

Thank you and see you next week,

Péter

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, we looked at a situation where Sarah, a Staff Engineer with 12 years of experience, joined our team after her previous one was disbanded. She's technically brilliant but seemingly bored after three weeks, finishing tasks in half the expected time and showing visible frustration during standups. Read the details here if you missed it.

This challenge was inspired by a recent discussion, but the names and the situation were significantly changed. Thanks, Kata!

I'll approach this situation with my usual Goals - Risks - Questions structure:

Goals to Achieve

Immediate engagement with long-term partnership: Sarah needs something challenging to spark her interest quickly. Show excitement about her joining, not fear or avoidance. We should paint this as an opportunity for a partnership where we collaborate on her career development, even if that eventually leads outside our team or company. She's not stupid - she knows what's happening. The question is whether we have the opportunity to influence this transition or if it occurs without our input. We should build trust with her quickly so she can see us as her ally.

Maintain team credibility: The other 7 developers on the team are watching how you handle talent. If you can't engage a Staff Engineer effectively, what does that say about your management capability? What career path lies ahead for the Senior Engineers? This is as much about your leadership as her retention.

Leverage this as an opportunity for higher ambition: Maybe our roadmap lacks technical challenges because we've been unambitious. Sarah's arrival could be the push to tackle problems we've been avoiding or innovations we haven't considered.

Knowledge sharing both ways: Utilize her expertise through pairing, mentorship, and technical leadership while introducing her to our domain. When she eventually moves on, the team should be better for having worked with her.

Risks to Avoid

Timeline miscalculation: She's probably answering LinkedIn messages now. You have maybe 2-4 more weeks before she's gone, not months to slowly build trust.

Team morale damage: If team members see you make exceptions just to keep her pleased (skipping on-call, avoiding bug fixes, working only on "interesting" problems), it'll backfire fast. Losing her is bad, but destroying team cohesion is worse.

Over-accommodation leading to chaos: Letting her drive technical decisions without proper context could mess up your stack or derail your roadmap. Pragmatism beats pure technical excellence, especially if you take into account the time factor: today’s smart solutions can quickly turn into tomorrow’s tech debt, when she’s already gone to another team or company.

Spreading organizational negativity: She's coming from a disbanded team where colleagues got laid off. That frustration and disappointment can be contagious if not addressed directly. You need to provide an area for her to vent privately, while eventually turning discussions future-focused.

(Note: I wrote about this aspect specifically in an earlier article titled How to Deal with Negative Behavior.)

5 Questions

1. What’s one challenging problem that she can start solving immediately? A long-standing bug that's been frustrating everyone, a technical debt assessment of your stack, or a gap analysis of your future strategy. She needs to understand she's needed here, not just accommodated.

2. What are her short, mid, and long-term career goals? You need this information to immediately jump on opportunities that match her aspirations. If she wants to move toward architecture, platform engineering, or technical leadership, what part of your team’s work can contribute to that path?

3. What's the real story behind her reassignment? The official version might be sanitized. Talk to her previous manager, other leads, or former teammates. Understanding the full context helps you better position this opportunity and address any lingering concerns transparently.

4. How can we be more ambitious with our current scope? If your roadmap truly has "no major technical challenges" and "business is happy," maybe you're thinking too small. What innovations, optimizations, or technical investments could Sarah help you pursue that you wouldn't get into with your current team?

5. Should we involve our manager in expanding her scope? Connect with your manager about this situation. Maybe there's an adjacent team where she could contribute to, or there’s an opportunity for cross-team technical guild participation that's relevant for a Staff Engineer's career development. Your manager might even have the authority to elevate her role across multiple teams. Their visibility might hint at future positions to open for Sarah that should keep her motivated.

The fundamental challenge isn't keeping her busy, but showing her that this reassignment can actually advance her career in ways her previous role couldn't.

Did you have to handle similar transitions in the past? Do you find something missing or misleading in my assessment? Let me know in the comments!

This Week’s Challenge

You're an Engineering Manager leading a team of 8 developers. Your company has been struggling financially, with three consecutive quarters of missing targets and cost-cutting across all departments. Your director has informed you that your team needs to be reduced by one person. This isn't about performance - it's purely about company survival.

Looking at your team, you have two junior developers. Mara has been there slightly longer and handles complex tasks independently. John, while enthusiastic and learning quickly, is still the least experienced and requires more handholding. Given the reduced workload ahead, keeping both junior positions doesn't make financial sense. It’s clear that you need to let John go.

John recently moved to the city for this job and has been genuinely excited about their growth. They're well-liked and progressing exactly as expected for their experience level. Your director agrees with your choice, and wants the termination completed by month-end.

Think about what your goals would be and what risks you'd like to avoid in this difficult situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly managerial challenges as soon as they are published:

Subscribe now

Until then, here's a small piece of inspiration about career development:

See you next week,

Péter

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 described a situation where you, as the Engineering Manager of a product development team, are tasked with forming an internal platform team from your current developers, plus people from other teams, with a three-month deadline to take ownership of shared services and tooling. Read all the details here if you missed it.

I'll approach this situation with my usual goals-risks-questions structure:

Goals to Achieve

Execution: Get clarity on the platform team's mandate and scope. This is where assumptions can cause misalignment, which usually takes a long time to discover. I need to understand exactly why we're creating this team, what parts of the tech stack we're taking over, what autonomy we have in build-versus-buy decisions, and what ongoing projects need immediate attention.

As the Domain Lead for Platform Engineering at Dashlane, one of the most impactful changes we introduced was treating platform engineering as product work. Our customers are the developers around us, and we use lean product development to iterate quickly toward the best solutions for them. This means discovery, experimentation, and evangelization throughout the organization.

Team: Form a team with a distinct identity, purpose, and principles. Social Contracting can be a good tool to achieve that. Without focusing on this, there's a risk that the original team will operate as a subgroup, excluding newcomers.

Personal: Support everyone through this transition. People staying on my team have to be okay with leaving feature work behind. People joining from other teams need proper handover from their previous managers: I need visibility into their career goals, performance history, and motivations to manage them effectively.

Risks to Avoid

Making assumptions about scope and expectations: Everyone has different ideas about what platform engineering means. Miscalculating what we're taking over, or basing decisions on wrong assumptions, can lead to misaligned development and frustrated stakeholders, even risking the whole Platform Engineering initiative.

Not operating like a product team: The biggest risk is working on the wrong problems, even building solutions nobody asked for. Experienced engineers often think they know not just the answers, but the questions too. For example, we could spend months building a unified local dev environment because the centralized support aspect might sound great for a senior engineer, while developers are enjoying and relying on their current freedom and don't see this as a problem that holds them back in their work.

Working in silos: Platform engineering success depends on problem discovery and constant communication about our direction. We need early feedback on ideas before we build them, and ongoing evangelization so adoption isn't starting from scratch.

Scope creep: When there's delivery pressure, platform teams might receive random feature work because "you're capable developers." This hurts our roadmap, demoralizes the team, and signals that our work isn't important enough to protect. The product-focused approach I described above can also help push back against these attempts.

5 Questions

1. Why did the organization create a Platform Team? What exactly is our mandate, and how does our work tie to business goals? I need concrete answers about the problem we’re trying to solve, the technical scope, process expectations, and decision-making authority. Platform engineering is a cost center - companies can survive without us longer than without feature teams. We must clearly show how we contribute through quality improvements, faster feedback cycles, better onboarding, organizational efficiency, or developer experience.

2. What success metrics will define our impact? By the end of three months, we need agreed-upon engineering metrics that we'll work on positively impacting. Maybe DORA metrics, maybe developer experience metrics, maybe both, maybe something else. (See the inspirational quote at the end of the article to get some ideas.) This alignment with leadership is crucial — it's how our work gets fairly judged and how we push back against random feature development requests. Without clear metrics, we're just a team that "enables developers" with no way to prove value.

3. Who's in my team now, and how do I make sure everyone collaborates effectively and efficiently? I need the previous managers' assessments, career aspirations, and performance history of incoming members. I need to reassess the remaining members’ goals and their place in the new team. Finally, what activities can ensure we function as one team instead of the original members plus newcomers? This is important both for psychological safety and collaboration.

4. What's the current developer experience, and where are the real pain points? This is product discovery work. What are developers struggling with? What works well? How do we compare to similar organizations? I'd start with developer experience surveys and benchmarks rather than assuming I know what needs fixing. Then we can have facilitated group exercises like Value Stream Mapping to discover all aspects of the software development lifecycle and its current pain points.

5. What quick wins can we tackle immediately? Low-hanging fruits serve multiple purposes: show progress to leadership and the organization, motivate the team by showing purpose, and give us practice with our new technical scope. It could be speeding up builds, automating a tedious task, or addressing some CI/CD issues. Even if it doesn't follow perfect product discovery, early wins can give a great boost of momentum and credibility to our work.

The core challenge isn't choosing the right tools or processes — it's transforming from individuals with improvement ideas to a team that discovers what developers need and solves the most impactful problems.

Did I miss any important considerations for this transition? Have you handled forming platform teams from mixed groups before? Let me know how it went in the comments!

This Week’s Challenge

You're managing a team of 7 developers when Sarah, a Staff Engineer with 12 years of experience, joins from another part of the company. Her previous team was disbanded during recent layoffs, but she was kept and reassigned to your team. She's technically brilliant, works fast, and has deep expertise that your current work doesn't really require.

Three weeks in, Sarah is clearly bored. She's onboarded to the new scope fast, and now finishing tasks in half the expected time and has started proposing solutions to problems that are not burning yet. Her frustration is becoming visible during standups, and you suspect she's already answering LinkedIn messages from recruiters.

Your roadmap for the next six months has no major technical challenges, and the business is happy with current performance. You need to keep Sarah engaged, but you're worried about losing her to a more stimulating role elsewhere.

What do you do?

Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly brain-teasers as soon as they are published:

Subscribe now

Until then, here's a small piece of inspiration related to this week’s challenge:

See you next week,

Péter

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

In the previous issue, I described a situation taking place right after a failed product launch, resulting in a production incident, followed by a weekend of struggling with hotfixes. Read all the details here if you missed it. I'll approach this situation with my usual structure:

1. Goals to Achieve

Show leadership: Build back trust by showing both your team and stakeholders that you've got things under control. Avoid decision paralysis; start taking actions while keeping everyone informed of your progress.

Rebuild team morale: Multiple developers working through the weekend is a massive red flag. Your team is demoralized and defensive - they need to see that you're committed to preventing this from happening again, not just promising to "be more careful next time."

Diagnose root causes systematically: This isn't just about process gaps - examine your technical setup, testing coverage, and deployment procedures. Look at both what failed and what systems should have caught these failures before they reached production. Run a blameless postmortem focused on system failures, not human mistakes.

Individual performance assessment: Objectively identify if performance issues contributed to this failure. Support team members who need development, but don't ignore systemic patterns if they exist.

Keep the roadmap moving: You can't halt delivery to fix everything. Find ways to pair small process improvements with feature development so you can test your fixes and get feedback on them in real life, with the next deployment.

2. Risks to Avoid

Going to extremes: There are two bad paths here. Either you halt all delivery for a massive process overhaul, or you chalk this up to human error and make vague promises about "being more careful next time." Both are extremes that rarely work out well in reality. You need to find the right balance between these.

Further demoralizing the team: Weekend workers might resent colleagues who didn't sacrifice their time, who, in return, might be experiencing some level of missing out and guilt. Address this fragmentation directly during your retrospective or individual conversations. Make it clear that weekend work is the (sometimes necessary) exception.

Losing more stakeholder confidence: Executives are asking pointed questions. Give them honest assessments and regular updates on your improvement plan. It’s OK not being able to commit to everything yet, but whatever you do commit to, keep it. Don't promise unrealistic timelines. You can often buy time by sharing your plan for gathering the necessary information, committing to a specific date for follow-up, or providing regular progress updates as needed. Remember, the goal is to gain back confidence that you’ve got this under control — and not that you dump all the random information on your manager’s table for her to make sense of it all.

Overcorrection leading to risk aversion: Teams that get burned can become paralyzed by fear of another failure. Maintain a culture where calculated risks are still acceptable. (See my earlier article on Celebrating Failure.)

Inefficient postmortem: This can be a stressful and costly meeting. You need to balance psychological safety with transparency. Including stakeholders might provide valuable context and can help circulate information — but having leadership in the room could also prevent honest discussion if your culture isn't mature enough for it.

Taking on too much without asking for help: This could be a significant product, engineering, and organizational failure. If you feel overwhelmed, don't try to solve everything yourself. Involve your manager and peers in both the analysis and solution design as needed.

3. Five Questions

1. What really happened? Understanding the actual business damage helps prioritize fixes and sets realistic expectations with stakeholders. Was this a minor inconvenience, or did it seriously impact customer trust and revenue? Was this a surprise in a usually uneventful list of deployments, or are failures a regular occurrence? Why didn't we just roll back to the previous version and fix the bug during normal working hours? Was it technical limitations or external commitments? Who made the decisions, and how did we communicate?

2. How should the Postmortem be organized? The key is to build a group-solving and not a culprit-finding mindset. You’re all on the same team, trying to solve a puzzle together. Resist the temptation to be satisfied with an “XY made a mistake” answer; focus on things that made the mistake easier to happen. Why didn't testing catch these bugs? Why was emergency deployment so difficult? You can use the 5 Whys technique to dig into root causes:

   Why didn't the user sign-up modal work? Because there was a bug in the signup system.
   ➡️ Why? Because we didn't alter the table that stores new data.

   ➡️ Why? Because the person deploying forgot they needed to alter the database.

   ➡️ Why? Because there was no documented process for deployments with database structure impacts.
   ➡️ Why? Because we have outdated documentation.
   ➡️ Great, let’s capture that as an action item to review and update all deployment-related documentation.

   This is a great tool to identify action items that can prevent similar issues from happening in the future, by ensuring you impact the root cause and not a symptom. Make sure you document the postmortem’s key findings: timeline of events, observations, action items, and next steps; and ensure these are shared transparently within the organization.

3. How do we balance process improvements with delivery momentum? You need quick and concrete wins to rebuild confidence, but you can't stop shipping features. Which process fixes can be implemented alongside the next feature release? What's the “minimum viable improvement” that reduces risk while maintaining velocity? Can we alter or descope the next features in the pipeline, to find the best development tasks to match with process improvements?

4. How can we better separate code deployments from feature releases? The two don’t need to go hand in hand. Feature flagging, staged rollout, and various other techniques can ensure that you have more safety and options to course correct when new code gets to production. Moving closer to a more robust deployment process can help both in decreasing production incidents and in evaluating and iterating on new features as close to their final environment as possible.

5. Do I need help? This might be bigger than something a single team or EM can solve alone. Are there organizational, resource, or knowledge constraints that require escalation? What expertise or authority do you need that you don't currently have? Are there decisions you’re not sure of, and if so, who could help increase your confidence or challenge your assumptions?

The ultimate task is to build a resilient culture with iterative, small deployments decoupled from feature releases, where failures are rare and quickly recovered from without catastrophic impact on team morale or trust.

Did I miss any important considerations? How have you handled recovery after major production failures? Let me know in the comments!

This Week’s Challenge

Your company is creating an internal platform team mostly consisting of your current staff, including you as the team’s Engineering Manager. Three of your current developers and two more from other teams will make up the new platform team. You will need to take ownership of part of the tech stack and provide shared services and tooling for the entire engineering organization.

Your director wants this transition completed within three months, and expects the platform team to operate with the same discipline as serving external customers.

You need to figure out how to transform this group's approach from shipping user features to building and maintaining internal tools that other engineering teams will adopt and find valuable.

How do you approach this new role?

Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly brain-teasers as soon as they are published:

Subscribe now

Until then, here's a small piece of inspiration slightly related to this week’s challenge:

See you next week,

Péter

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 described a challenge where a new Engineering Manager is tasked with fixing a web development team's stressful monthly releases, with developers burning out from branch merging struggles and frequent emergency rollbacks. Read all the details here if you missed the post.

Goals to Achieve

Show progress. The deployment process needs fixing - it's unsustainable. While I need to balance analysis with action, I need to show continuous improvement - this is explicitly what I was hired to deliver within the quarter, so of course it’s one of my main goals.

Gain the team’s trust. However, without gaining the team's trust first, technical changes will be harder to implement. These experienced developers have seen improvement attempts fail before. Gaining their confidence is the first step to everything else.

Learn why things are this way. The current system evolved for reasons. Before changing it, I need to know those reasons. Understanding why things are this way helps me come up with better solutions that address root causes — and avoid pitfalls others fell into.

Establish clear metrics. I need to set up a baseline of metrics that matter to both the team (reducing stress) and the business (improving delivery). These metrics will guide prioritization, make progress visible, and serve as objective success criteria.

Address burnout. The current release process is probably the main contributor to their low engagement, but what other factors might be at play? Are there deeper issues around autonomy, mastery, or purpose that need addressing?

Risks to Avoid

Over-indexing on action. Rushing to implement changes without understanding context or building trust has a huge risk of failure. Trying to force textbook CI/CD processes on an organization I don't yet understand risks creating solutions that won’t work, and further damage team morale.

Under-indexing on action. Equally bad is analysis paralysis, spending too much time analysing without doing. This risks losing the director's confidence and gradually accepting the status quo. Making changes is easiest when you're new, and this advantage fades with time.

Ignoring team expertise. These are experienced developers with reasons for their current practices. Disregarding their knowledge means missing valuable insights, and also, the IKEA effect matters - people give more support to what they helped build.

Forcing industry best practices. Assuming off-the-book standards will work unchanged in this context is dangerous. Every organization and every product is different. There must be some legitimate reasons why their system evolved like this.

Wrong order of improvements. Some changes depend on others. We need to find steps that have a demonstrable impact while still building necessary foundations. Working for months on invisible infrastructure without showing regular progress will kill trust in the process.

Big bang migrations. Creating parallel systems that aren't used in production means building on assumptions without real feedback. Without testing changes in production and learning from results, we risk building the wrong solution. Plus, migrations are risky - incremental improvement is often safer and is a better way to demonstrate progress.

5 Questions

1. Why is the current system structured this way? How and why did previous improvement attempts fail?

Are monthly releases required by business cycles, regulatory needs, or technical limitations? When previous managers tried to improve things, what went wrong? Which constraints can I challenge, and which are not possible? Getting this context helps to better understand the current status quo and avoid repeating past mistakes.

2. What's one small, concrete improvement I can implement quickly?

Finding a quick win builds momentum and trust. This could be automating release notes, writing down an undocumented process, simplifying rollbacks, or removing a manual step everyone hates. The ideal first change addresses a clear, universally shared pain point without requiring massive changes, but it’s small enough to avoid having to rely on organizational context and interconnected systems.

3. What metrics should we track to measure improvement?

I need to find and start recording the metrics that best represent the current problem, both technically and business-wise. DORA metrics can be a good starting point, but developer experience matters too, so maybe I’ll need something more holistic, like a version of the DX Core 4 framework. Either way, I need to involve stakeholders and developers in validating my choice to ensure these metrics connect to the business impact we want to make.

4. How does the rest of the engineering organization operate?

Do other teams face similar challenges? Have some solved problems we're still struggling with? Finding internal examples of better practices provides practical blueprints and credibility. Solutions that worked elsewhere in the company are easier to implement.

5. What are the team's specific fears about changing the process?

Is there a lack of trust in other developers' code that makes them hesitant about trunk-based development? Are they worried that CI/CD will remove important manual checks? Understanding specific fears helps us address concerns directly and design solutions that maintain what works.

Finding the Balance

Let me summarize: The core challenge isn't choosing between technical solutions, it's balancing action with observation, and managing the change process itself.

Did I miss any important considerations? What approaches have you found effective when introducing deployment improvements to resistant teams? Let me know in the comments!

This Week's Challenge

Your team just completed a major product launch that went poorly. The new features had multiple critical bugs that weren't caught in testing, resulting in customer complaints and an emergency hotfix that kept several developers working through the weekend. The product team is frustrated about damage to user trust, executives are asking pointed questions about what went wrong, and your team is demoralized and defensive.

You’re under pressure from multiple directions: you need to quickly identify process failures, regain stakeholder trust, rebuild team confidence, and most importantly, prevent similar issues in the future. All while the product roadmap is still ambitiously planning to deliver the next major feature in six weeks.

What do you do?

Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly brain-teasers as soon as they are published:

Subscribe now

Until then, here's a small piece of inspiration slightly related to this week’s challenge:

See you next week,

Péter

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, we had a more pleasant than usual challenge: figuring out how best to spend a moderate team-building budget. Read the details here if you missed it.

I'll approach this situation with my usual structure:

Goals to Achieve

Increasing Team Cohesion: Break down existing social barriers, especially between newer hires and veterans. Create shared experiences that can provide a foundation for better collaboration. The team is hybrid, which probably means that a lot of communication happens async. How people interpret a short, direct Pull Request comment or Slack message can be very different based on their pre-existing personal relationship.

Psychological Safety: Use team-building to reinforce that people can take interpersonal risks without fear of negative consequences. When team members know each other beyond their professional roles, they're more likely to speak up, ask questions, and engage in constructive disagreement. All these are key characteristics of a high-performing team.

Inclusive Participation: Ensure everyone can fully participate, regardless of preferences, location, timing, etc. This is key for creating a truly shared experience.

Sustained Impact: The activity should be the starting event for ongoing behavioral changes, not just serve as a one-time momentary spike. The goal isn't just a fun day, but establishing patterns and connections that persist and continue to improve when everyone returns to daily work.

Risks to Avoid

Reinforcing Existing Divides: Without thoughtful planning, team activities can strengthen rather than break down existing social patterns. If people only interact with those they're already comfortable with, we'll entrench the very problems we're trying to solve.

Comfort Zone Violations: Pushing someone too far outside their personal boundaries risks creating resentment rather than connection. Not everyone thrives in the same environments - what energizes one person might exhaust another.

Remote Member Isolation: Activities that don't meaningfully include remote team members can worsen their sense of disconnection. A "second-class" team-building experience for remote folks undermines the entire purpose — if travel is not feasible, it might be better to organize the entire event online for everyone. Hybrid events can leave remote folks feeling like second-class team members and not get the expected results.

Exclusionary Elements: Overlooking dietary restrictions, disabilities, religious observances, or cultural differences can make team members feel unvalued or excluded. (This is why the often default alcohol-centric activities might quietly alienate some team members.)

Leadership Extremes: Finding the right balance of direction versus autonomy is also important. Putting everything to a vote can lead to endless discussion and default to lowest-common-denominator activities, driven by more assertive team members. However, dictating every detail without input signals that team preferences don't matter. Align on the goals, run the organizing process with transparency, and offer clear intervention points where you rely on team feedback.

5 Questions

1. What type of activity would best serve our team's specific dynamics? Purely social events like happy hours might reinforce existing social groups. Skill-based activities could highlight talents beyond coding. Problem-solving activities that require cooperation might encourage new interactions. Something engineering-adjacent but unfamiliar to everyone (for example, a Capture The Flag security challenge, or building some hardware with microcontrollers) could provide both common ground and a level playing field.

2. How can we structure the activity to ensure meaningful cross-group interactions? Should we deliberately mix people from different project teams or tenure levels? What mechanics would encourage those who don't normally interact to work together? Can we design an activity that requires complementary skills from different team members?

3. What's our strategy for truly including remote team members? Is it better to bring them on-site or design a fully distributed activity? If we're bringing them in, how do we ensure they're not jet-lagged or stressed during the activity? If remote, what technology or approach ensures they everyone has equal presence and participation, even those who are more used to in-office work?

4. How will we measure the success of this team-building effort? What behavioral changes would indicate improved cohesion and better communication? What metrics (qualitative or quantitative) could we track before and after? How will we know if the investment paid off? These are important questions both for assessing the EM’s decision and providing learning opportunities, and both for securing next year’s team-building budget.

5. What follow-up activities or changes to team processes could sustain the momentum? Team building shouldn't be a one-off event. Are there some lightweight, regular practices we could implement that build on the connections formed? Should we adapt our daily work processes to reinforce the collaborative behaviors we're trying to encourage?

I didn’t include practicalities like how to ensure the scheduled event doesn’t disrupt delivery, how to minimize expenses, etc., because I felt it was more important to focus on these high-level questions. Besides that, do you think I miss any important considerations? Let me know in the comments!

Next Week’s Challenge

You've been recently hired as Engineering Manager for the web development part of a bigger engineering team that’s known for their stressful monthly releases. Each release day inevitably turns into a 48-hour firefighting session, with developers struggling to merge development branches, frantically debugging issues and occasionally reverting to previous versions or doing partial releases.

You've quickly identified several potential solutions - implementing proper CI/CD, moving to trunk-based development, using feature flags - but you're unsure which to prioritize or how to introduce changes without creating more chaos.

The director who hired you wants to see concrete improvements within the next quarter, but you’re afraid of rushing into changes that might backfire. The team consists of experienced developers, but they are nearing burnout and are somewhat resistant to new processes, having been burned by previous improvement attempts.

How do you balance technical improvements with team morale while delivering measurable results that satisfy stakeholders and customers?

Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly brain-teasers in the future as soon as they are published:

Subscribe now

Until then, here's an inspiring quote slightly related to last week’s challenge:

See you next week,

Péter

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, we explored a situation where you need to choose between two excellent senior developer candidates - one with deep expertise in your current tech stack who could solve immediate problems, and another with broader experience across different domains but less specific depth. Read the details here if you missed it.

I'll approach this situation with my usual structure:

Goals to Achieve

Execution: Improve our delivery capability by adding the right mix of skills to the team. The new hire should help address current challenges while also contributing to our future direction. Of course, we can never perfectly predict what technology shifts will happen - the future is inherently unknown, so adaptability matters regardless of which candidate we choose.

Team/Organization: Enhance the team's capabilities in areas where we're currently lacking. This works at multiple levels - we should be thinking not just about our team's needs, but also skills the wider organization could benefit from. This is especially true if our team frequently collaborates with others.

Don't just consider your team as it exists today, but as it will likely be in the near future. If the organization is expecting growth, or if some team members are nearing their ceiling and might leave soon, factor that into your decision. Missing context here can lead to a hire that makes sense today but creates problems in six months.

Personal: Create the right balance of challenge and achievement opportunity for the new hire. They should be stretched enough to grow, but not so far that they can't contribute effectively in the short term. Too little challenge leads to boredom; too much leads to anxiety or failure.

Also, consider how this senior hire can help grow others. A great senior developer doesn't just contribute individually but elevates those around them through knowledge sharing, mentoring, and setting technical standards. How will each candidate help develop the rest of your team?

(Tip: I co-hosted a podcast episode with Jeremy Brown discussing What Puts the Senior in Senior Software Engineer? where we discussed in depth how a senior developer contributes to the team beyond technical skills.)

Risks to Avoid

Execution: Over-indexing on either immediate problem-solving or imagined future flexibility. The reality is that our predictions about future technical needs are often wrong - new requirements emerge, technologies evolve faster or slower than expected, and business priorities shift. And just like hiring someone who can't deliver concrete results today, bringing a person on board who’s stuck in a single stack can set them up for eventual failure. In fact, the real risk is hiring someone who works well only in static environments and is not used to learn and adapt.

Team/Organization: Creating unnecessary tension through poor communication about your decision. The team is already divided in their preferences, and without a clear explanation of your criteria, this division could deepen. Be especially sensitive about not appearing to value some team members' opinions over others.

Avoid roles that would isolate the new hire or inadvertently create a "second-class" team. For example, hiring someone to work alone on a new technology while the rest of the team maintains legacy code can be demotivating for everyone involved, creating silos within your team.

Personal: Setting up the new hire for disappointment by selling them on opportunities that may never materialize. If the generalist candidate is excited about working with diverse technologies, but in reality will be confined to your current stack for years, they'll likely become frustrated and leave. Similarly, if the specialist expects to deepen their expertise, but you're planning a tech stack migration, their specialized knowledge might quickly become irrelevant.

5 Questions

1. What is our validated technical strategy for the next 12-18 months? The emphasis is on "validated" - not just what the engineering team wants to do, but what has buy-in from leadership and product management. Without this alignment, technical aspirations often vanish when business priorities shift. This core question should drive much of your decision - if significant architecture changes are planned and approved, adaptability becomes more valuable. If you're optimizing your current system with no major shifts planned, immediate impact might matter more, and candidates who have experience and future goals in this stack should be preferred.

2. What skills and perspectives are most needed to complement our team? Look beyond just technical knowledge. Perhaps we need someone who communicates complex concepts clearly to non-technical stakeholders, or who excels at documentation, knowledge sharing, or mentorship. Maybe the team could use someone who can bridge between technical implementation and business objectives. The biggest impact usually comes from adding dimensions the team currently lacks, not reinforcing existing strengths.

3. How will each candidate grow in the direction we need? A specialist can expand their knowledge breadth over time, while a generalist can deepen specific areas. Based on their learning agility and career trajectory, which candidate shows better capability to evolve with our needs? Past adaptability, not just current knowledge, matters greatly here. Also, consider how their personal goals align with the team's direction - a misalignment will lead to problems regardless of technical match.

4. What else did we learn from the interviewers? Technical skill assessment is just one dimension. Talk with interviewers individually, especially if you fear that less senior people won't contradict more senior ones in group settings. Sometimes critical information about collaboration style, problem-solving approach, or communication challenges only emerges in one-on-one discussions where people feel safer sharing reservations. Share your concerns about a candidate and see how they agree with you or defend their previous judgments.

5. What will the onboarding experience look like for each candidate? The first three months often determine long-term success, and coming up with a 30-60-90 onboarding plan can help clarify priorities, which can inform the hiring decision. Who do they need to talk with first? How quickly can each candidate become productive? What support would they need? Who would mentor them? The specialist might contribute faster but in limited areas; the generalist might take longer to learn your specific stack, but could bring immediate value in other ways. Plan the onboarding process for each, and see if that reveals aspects you hadn't considered.

The specialist-versus-generalist dilemma is just one dimension; make sure you don’t get stuck with it only, and consider other aspects too. As usual, concrete, proven work experiences and demonstrable skills should carry more weight than ideas and theoretical knowledge. Past behavior predicts future behavior better than preferences.

Did I miss any important considerations? How would you handle this hiring dilemma? Let me know in the comments!

Next Week’s Challenge

You're managing a team of 9 developers and have been given a modest budget for team building. While delivery is going well, team cohesion needs improvement - newer hires rarely interact with veterans, and people stick to their immediate project groups.

Your team is diverse: different ages, personalities, and working styles. The company has a successful hybrid culture, while most people go to the office at least once a week, two members work fully remote.

You want something meaningful that strengthens relationships beyond the usual happy hours or escape rooms, which tend to have mixed results. The activity should respect different comfort levels while genuinely fostering better working relationships.

What do you do?

Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly brain-teasers in the future as soon as they are published:

Subscribe now

Until then, here's an inspiring quote related to last week’s challenge:

See you next week,

Péter

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, we explored a situation where bad company results led to spreading negativity within a team. Read the details here if you missed it. I'll approach this situation with the usual three-step approach:

Goals to Achieve

Execution: Maintain delivery speed and quality, despite uncertainty. Redirecting the focus of the team to execution is key for maintaining productivity. I also have to provide clarity in what “getting back to basics” means concretely for our team, so people see how their work connects to business goals.

Team/Organization: I need to improve (or at least maintain) team morale. I should also preserve a healthy team dynamic that allows for openness, for everyone, without toxicity or fear of speaking up.

Personal: When giving support to my team members, I need to balance transparency with leadership responsibility. I must represent company decisions even when I don't fully agree with them, while maintaining credibility with my team by not dismissing concerns.

Risks to Avoid

Execution: Uncertainty in business goals can negatively impact product development, which can cause further frustration. Doubling down on work can also increase the risk of incidents and burnout in this already stressful time.

Team/Organization: Creating fractures within and around the team by allowing an "us vs. them" mentality to develop. This can damage team culture and make it harder to integrate newer members who may feel caught in the middle. The critical senior engineers have legitimate concerns that deserve space, but not at the expense of psychological safety for newer members or team cohesion. Tolerating unacceptable behavior sets a bad example and shows that my expectations are lowered for everyone.

Personal: Losing trust by either blindly defending management decisions I don't believe in or by openly criticizing leadership. This balancing act is critical - lean too far either way and I become either an ineffective messenger or an untrustworthy leader. (For more thoughts on this, see my article on How to Represent Decisions You Disagree With.)

Mental Health: Overlooking signs of anxiety, burnout, or isolation. Not just in team members, but within myself too: these situations require tremendous energy from Engineering Managers to navigate, so I need to watch out for signs, and know when and who to ask for help.

5 Questions

1. What specific areas can our team control right now? This helps redirect energy from passive complaints to active work. For each area of frustration, I need to sort them into "things we can influence" versus "things outside our control." Then I'll work with the team to create concrete actions for the things we can change. For example, if product direction feels uncertain, we can create more visibility into our current work's impact on business metrics to demonstrate value.

2. How can I transparently communicate what I know while respecting confidentiality? I should establish a regular cadence of updates that includes: what I know for certain, what remains unclear, what I'm actively seeking answers on, and when the team can expect more information. This approach builds trust by demonstrating I'm not withholding information, while creating a structure that reduces constant speculation. Delivering on these promises will free the team from worrying about what information they are missing.

3. What's the actual impact on each team member? I need individual conversations to understand personal concerns beyond what's voiced in group settings. Some may be worried about career growth in scaled-back projects, others about job security, while newer members might question their decision to join. These conversations help me tailor my support to each person's specific situation, including helping those who might be better off transitioning elsewhere. Relatedly, if relevant, I need to dig into how remote team members are processing this uncertainty. Physical separation can amplify anxiety during uncertain times. Are remote team members getting the support they need? Do they know about available resources like mental health benefits, wellness time, or even simple options like taking vacation days? I should create safe spaces for remote team members to connect both with me and with each other, beyond just work discussions.

4. How can we redefine "getting back to basics" in a way that motivates rather than deflates? Working with the Product Manager, I need to frame our adjusted priorities in terms of impact and growth opportunities rather than simply as cuts. For example, "We're focusing on improving our core user journey, which touches 85% of our daily active customers." highlights importance rather than merely noting what we're not doing.

5. Why is this still a decent place to work at? We tend to take the good stuff for granted, and when something changes for the worse, we focus on that only. Most places are still pretty good, for example, the salary is probably decent, colleagues are inspiring, the tech stack provides a lot of learning opportunities, hybrid work allows flexibility, etc. What makes our team a good one, and how can I show this to the people in subtle, indirect ways (so it's not interpreted as changing the subject away from bad news)?

The fundamental challenge here isn't just managing negativity, it's nurturing a team culture that can process disappointment constructively. The "disagree and commit" concept can become handy: team members should feel free to voice concerns, but once decisions are made, we must align on execution rather than continuing to relitigate the past.

Ultimately, my goal isn't to eliminate all negative feelings; that would be unrealistic and patronizing. Instead, I want to create an environment where people can express frustration without spiraling into cynicism, and where we can acknowledge setbacks while still finding purpose and engagement in our work. (See more on handling team members’ frustration in my article on How to Deal with Negative Behaviour.)

What's been your experience managing team morale during uncertain times? Have you found effective ways to balance empathy with maintaining momentum? Let me know in the comments!

This Week’s Challenge

You're an Engineering Manager who has been running a hiring process for a senior developer role. Finally, you've narrowed it down to two excellent candidates. Both impressed everyone during the interviews, but have slight differences in what they could bring to the table.

The first candidate has deep expertise in your current tech stack and proved during the technical interview that they could navigate your complex codebase with surprising ease. They identified several issues your team has been struggling with for months. They're clearly a specialist who has mastered your exact technology combination.

The second candidate brings a much wider range of experiences across different domains and technologies, though not as deep in any specific area. They showed an open mindset, asked insightful questions about your system, and have good pragmatic opinions on the options you described them.

Your team is split on their preferences, with senior members leaning toward the first candidate's immediate impact, while others appreciate the second candidate's broader perspective and enjoyable collaboration attitude. Their salary expectations are both withn range, and your director has left the decision entirely up to you.

You need to make an offer within the next two days, and you can only hire one of them.

What do you do?

Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly brain-teasers in the future as soon as they are published:

Subscribe now

Until then, here's an inspiring quote related to last week’s challenge:

See you next week,

Péter

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, we explored a situation where a technically strong but sometimes abrasive senior developer resisted adding communication skills to his development goals. Read the details here if you missed it.

I'll approach this situation with my usual framework:

Goals to Achieve

Support his overall growth: My fundamental goal is to help Leon develop towards a better version of himself. His technical skills already exceed expectations — what's limiting his impact and career progression are his soft skills. I want to help him overcome these obstacles while maintaining his technical enthusiasm.

Agreement on the problem: Before we can start to make progress, Leon must acknowledge that his communication style is an issue worth addressing. Currently, it feels like he perceives it as his intrinsic characteristic, something he cannot do much about. Without this agreement, any development plan will have much less chance to succeed.

Team execution: Improving Leon's ability to collaborate effectively with both technical and non-technical teammates will make the entire team more efficient. The way he reviews code, explains complex concepts, and interacts with other departments all impact our ability to deliver.

Establish clear expectations: I want Leon to demonstrate what "good" looks like for a senior engineer in our organization, both technically and behaviorally. This sets standards not just for him but for the entire team, especially less experienced members who might see him as a role model.

Risks to Avoid

Losing his trust: If Leon perceives me as pushing some "bullshit agenda" that he doesn't value, I'll lose my ability to influence his development. He needs to see me as an ally in his growth, not an obstacle.

Pushing him away: If handled poorly, Leon might decide the organization doesn't value his technical contributions enough and start to look elsewhere. Given his strengths and potential, that would be a significant loss.

Overemphasizing weaknesses: Following a strengths-based development approach does not mean solely focusing on fixing deficiencies. The goal isn't to transform Leon into someone he's not, but to help him use his strengths to navigate his blind spots.

Taking ownership of his development: If I dictate goals without his buy-in, they become mere tasks without the motivational and accountability aspects that make development effective. Leon must own his growth.

Tolerating problematic behavior: The easy (lazy) approach would be to isolate Leon, limiting his interactions while leveraging his technical skills. This approach would not only stunt his growth but also set a dangerous example for the team about what behaviors are acceptable.

5 Questions

1. What are Leon's longer-term career aspirations? Understanding what Leon ultimately wants helps frame the conversation. If he aims for an eventual Staff Engineer promo, I can directly connect soft skills to that path. If he wants a bigger technological impact, I can show how communication enables that influence. Even if he wants to "just code," I can discuss how the changing nature of work (think about AI) means technical skills alone won't be sufficient long-term.

2. Is Leon operating with a fixed mindset about soft skills? His statement "I'm an engineer, not a people person" suggests he might see soft skills as innate rather than learnable. How can I help him understand that soft skills — like communication, empathy, collaboration, adaptability, and emotional intelligence — are not fixed traits, but abilities that can be developed and strengthened with intentional practice, just like technical skills? Are there examples of colleagues who've made similar journeys that might serve as proof points? Maybe I can share my own development path?

3. How can I connect soft skills to his technical success? Leon cares deeply about technical excellence and efficiency. How can I help him see that his soft skill limitations actively hinder his technical impact? For example, if his ideas aren't communicated clearly during architectural discussions, they won't be implemented regardless of their merit. If his code reviews alienate teammates, his technical guidance loses effectiveness. Additionally, the negative image he creates through his style means people take his thoughts with skepticism, making it harder for him to convey even the best ideas.

4. Does Leon understand career progression and baseline expectations? As engineers advance from Senior to Staff and beyond, technical skills become table stakes while influence, communication, and leadership become differentiators. Has Leon studied our career ladder? To take it a step further, does he understand that certain behaviors aren't just hindering advancement, but they fall below the requirements for his current position? Being disrespectful could be considered a performance issue regardless of technical prowess. This could be more than "nice to have" skills, and rather about meeting fundamental job expectations.

5. How can we integrate soft skills as primary goals to be achieved by using his technical interests? Rather than treating soft skills as secondary additions to technical goals, how can we frame them as the primary focus while using his technical interests as the vehicle? For instance, instead of "mastering a new framework", the goal becomes "delivering a workshop to the team" that requires learning the framework. The open source goal could be "having a contribution merged" — which requires understanding the social dynamics of open source communities, where clear communication and respectful interactions are often as important as code quality. By the way, the experience of having technically sound contributions rejected due to poor communication or not following community norms might also help Leon empathize with colleagues who feel dismissed by his current communication style.

Did I miss any important aspects of motivating soft skill development in technical team members? Have you handled similar situations with technically strong but interpersonally challenging developers? Let me know how those went in the comments!

This Week's Challenge

Your team's atmosphere has noticeably darkened since the company's disappointing quarterly results announcement a few weeks ago. Where conversations once flowed with optimism, they're now punctuated with cynical remarks during meetings. Two particularly vocal senior engineers have started openly criticizing decisions from upper management, and others silently nod along. The CEO's vague all-hands message about "getting back to basics" offered few specific plans, and a new project your engineers were excited about have been quietly deprioritized.

As the Engineering Manager, you're caught in an uncomfortable position. While you understand, sometimes even share some of your team's frustrations, the spreading negativity is affecting morale and productivity, which risks delivery on your current projects. You've also noticed that newer team members appear increasingly uncomfortable and uncertain during team discussions.

Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly brain-teasers in the future as soon as they are published:

Subscribe now

Until then, here's a small, not obviously related, but either way, quite inspiring quote:

See you next week,

Péter

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, we were assigned to lead a struggling team split into opposing factions. Read the details here if you missed it.

I'll approach this situation with my usual structure:

Goals to Achieve

Execution: Rebuild the team's ability to make decisions and deliver. Without establishing a functional decision-making process, delivery will continue to suffer regardless of other interventions. I must create clarity around how technical decisions get made, executed, and evaluated.

Team/Organization: Break down the factional identity that has formed. As long as people identify primarily with their "side," cooperation will remain superficial at best. The low level of psychological safety works against raising creative solutions to problems. My goal is to reset team norms and establish new patterns of interaction that discourage tribalism. (A Social Contract is a great tool to capture and display these norms and patterns.)

Personal: Build individual relationships based on trust and objectivity. Team members need to see that I'm not simply taking sides or arriving with preconceptions. Conversations should be kept fact-based and solution-oriented.

Risks to Avoid

Execution: Getting bogged down in historical grievances while missing immediate delivery expectations. While understanding the past matters, dwelling there too long risks missing the 3-month window I have to show improvement. The team also needs forward momentum, seeing the way they can work together can boost morale.

Team/Organization: Driving away good contributors by oversimplifying the conflict or dismissing their points by focusing on delivery only. A dysfunctional team can hide solid technical work. The whole team falling apart is a big risk, too. On the other hand, trying to change everyone to work better in the team is a risk too — if it’s obviously not a good fit for someone, I should work on making the separation easier for all.

Personal: Appearing to choose sides. If team members perceive me as having been "captured" by one faction, I'll lose any ability to influence the other group and likely deepen the divide rather than healing it.

5 Questions

1. What are the actual power dynamics behind the apparent conflict? Is there an imbalance in perceived influence, recognition, or access to information that's driving resentment? Understanding the underlying structures matters more than cataloging individual grievances. I need to observe who speaks first in meetings, whose opinions carry weight with leadership, and where information flows freely versus where it's guarded.

2. How do one-on-one conversations differ from group settings? Some can be open to spell out their opinions more comfortably in this setting than in front of the group. Often in divided teams, people express more nuanced views than they do publicly. Meeting each team member individually might reveal that positions aren't as hardened as they appear in group settings or might identify specific triggers that escalate tension.

3. What are the real business consequences of the team's dysfunction? Understanding the concrete impact on customers, other teams, and the business creates urgency beyond abstract notions of "team health." This helps frame the situation not as "let's all get along" but as "our dysfunction is harming our customers in these specific ways."

4. What decision-making approach would give everyone confidence in the process, even when they disagree with outcomes? A good process that everyone believes in can make even controversial decisions acceptable. This could involve clarifying what decisions are made by consensus versus authority, documenting the reasoning behind choices, or establishing clear criteria for technical decisions.

5. Is there a concrete project that could serve as a "clean slate" opportunity? Finding work that isn't tainted by previous battles could provide neutral ground for establishing new team norms and trying out the new decision-making process. The key is finding something where historical baggage is minimal and can create delivery discipline, helping the team see what success feels like.

Did I miss any important aspects of handling this team transformation challenge? What experiences do you have with unifying divided teams? Let me know in the comments!

This Week's Challenge

During your goal-setting session with Leon, a technically strong senior developer who's been with the team for three years, presents goals exclusively focused on technical areas: mastering a new framework, deepening his knowledge of distributed systems, and contributing to an open-source project. His enthusiasm about these topics is evident.

You know, however, that what's actually limiting Leon's impact and advancement aren’t his technical skills, which already exceed expectations, but rather his communication style, sometimes being dismissive or disrespectful. His code reviews can be abrasive, he struggles explaining complex concepts to junior team members, and he doesn’t respect the opinion of non-technical colleagues.

When you suggest adding soft skill development goals to his plan, Leon pushes back: "I'm an engineer, not a people person. I'd rather focus on what I'm good at." You value his contributions and see great potential, fear that without addressing these areas, he'll eventually hit a ceiling in both effectiveness and career growth.

Think about what you would do in this situation and how you’d approach finding the angle that can convince Leon to look into soft-skill development. I’ll share my points next week. Sign up to receive it when it’s live:

Subscribe now

Until then, here's a small piece of inspiration to match last week's challenge, from Jason Fried’s article “Rescuing a project in progress”:

See you next week,

Péter

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, one of our senior developers shared that she wants to transition to management. The situation is complex because she’s a key technical contributor, and there are no known EM openings at the company. Read the details here if you missed it.

I'll approach this situation with my usual three-step framework:

Goals to Achieve

Career Development: Support Kate's growth aspirations while being honest about current opportunities. I should probe her motivations and understanding of the EM role to be able to support her appropriately. The goal is to find ways for her to learn and grow in areas that can be used in both technical and managerial leadership positions.

Team Execution: Maintain our technical capabilities and delivery expectations. As Kate is a technical anchor, we must balance her growth with our team's technical depth and stability. I need to find a balance in transparency with the rest of the team so they understand what’s going on and can also support her growth.

Organization Benefit: Develop Kate as a potential future leader while maximizing her current contributions. Great companies develop talent proactively, not just reactively when a position opens.

Risks to Avoid

Binary Thinking: Seeing this as an "either stay technical or become a manager" decision could unnecessarily limit options. There's a spectrum of leadership opportunities between these poles. She needs to discover and understand what management means. We can do a lot of that while staying in her role, pushing her career decision to later when she’s more informed and confident in her choice.

Disengagement: Without a satisfying growth path, Kate might disengage and eventually leave. This would harm both her career and our team's capabilities. We should support her personal growth regardless of organizational opportunities.

Misalignment: Supporting a management transition without exploring Kate's true motivation could lead her toward a role she's not well-suited for or not motivated by, ultimately making her less fulfilled and effective.

Business Impact: Creating responsibilities that don't serve real business needs just to appease Kate would waste resources and potentially create future role confusion.

5 Questions

1. What's truly driving Kate's management aspirations? Is it that she genuinely enjoys developing people, facilitating team processes, and handling organizational dynamics? Or is it that she's feeling stagnant technically and sees management as the default next step? Understanding her deeper motivations will help shape the right development path. If she's primarily seeking growth and impact rather than management specifically, other paths might be more fulfilling — she might not be aware of the existence of these. These might include Staff/Principal Engineer, Technical Program Manager, Sales/Support Engineer, Product Manager, or technical specialist roles with broader influence. By widening the conversation beyond "IC vs. manager," we might find better fits for her skills and aspirations. But first, we need to understand the root of her motivations.

2. What leadership gaps exist in our organization? Even without formal EM openings, there may be under-addressed leadership needs that Kate could help with. Could she lead the interview process improvement? Own cross-team technical initiatives? Run mentorship programs? Manage an intern? The goal is to find real business needs that develop leadership skills, not make-work assignments. Sharing the situation and my plan with leadership would also allow them to think about Kate when planning a reorganization.

3. How can we create leadership experiences in her current role? Rather than waiting for an EM position, what opportunities could give Kate real leadership experience now? These might include running or facilitating team ceremonies, mentoring newer team members formally, representing the team in cross-functional meetings, or helping with hiring and onboarding. These experiences would build relevant skills and provide a clearer picture of whether management is truly her calling.
   
   Recommended reading: On my engineering leadership blog, I listed 50 things developers can do to prepare for an Engineering Manager role here.
   

4. How serious is Kate about changing paths? Would she leave if there's no clear transition opportunity in the next 6-12 months? Understanding her timeline helps prioritize actions and have honest discussions about what's realistic. If she's determined to become a manager soon, we should support her getting the necessary skills here, while eventually networking with other teams or even other companies rather than trying to retain her in a role that no longer fits her goals. This would maintain the trust we have and could help us build a sustainable offboarding plan.

5. Does Kate truly understand what the EM role entails? She only saw us working in team and individual 1:1 settings, but a big part of EM work is outside of team context. Is she familiar with stakeholder management, planning, interviewing, supporting, performance managing, and other Engineering Management expectations? She needs this insight to be able to make the right decision.

Did I miss any important aspects of handling this leadership development challenge? What experiences do you have with supporting career transitions in your teams? Let me know in the comments!

This Week's Challenge

You've been assigned to lead a team known for missed deadlines and high turnover. In your first two weeks, you discover a deeply divided team culture that has evolved from technical disagreements into personal animosity.

What began as debates over architecture and tooling has morphed into a toxic environment where team members have formed opposing factions. The rift appears personal now – people dismiss ideas based on who proposes them rather than their merit. Team meetings are tense and unproductive. Some members remain silent entirely, while others only speak when their allies are present. New joiners quickly learn which "side" they're expected to choose.

The previous manager tried addressing specific conflicts as they arose but never tackled the underlying trust issues before transferring elsewhere. Your director's expectation is clear: transform this dysfunctional environment into a collaborative team that delivers reliably—within three months.

What do you do?

Think about this challenge, what would be your immediate goals, what questions would get you closer to achieving them, and what risks you’d like to avoid. I’ll publish my approach next week - make sure you’re subscribed to receive it on time.

Subscribe now

Until then, here's a small piece of inspiration to match this week's challenge:

See you next week,

Péter

I’m Péter Szász, writing about my engineering leadership experience on my blog, training aspiring and first-time Engineering Managers on this path. See more about what I might 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, we explored a tough situation where an Engineering Manager was asked to reduce their team size by two people. Read the details here if you missed it.

I'll approach this situation in our standard three steps:

Goals to Achieve

Execution: I shouldn't fight, let alone sabotage the task. Instead, I should show clearly the impact of downsizing on our team’s commitments. This includes effects on our roadmap, services to other teams and customers, on-call rotation, etc. I have to collaborate closely with the Product Manager to determine what this smaller team can realistically produce in the future.

Team/Organization: Keep the balance and diversity of the team despite having fewer people. This includes maintaining a mix of seniority, expertise, and tenure. Teams should be set up to solve tomorrow's problems, not just today's, so I need a forward-looking vision: what’s the best team setup to successfully execute on a reduced scope?

Personal: Handle the process with dignity and transparency. People will remember how their departing colleagues were treated, shaping their own sense of security and loyalty. I need clear, objective criteria for my selection that can be shared with the team later.

Risks to Avoid

Execution: Promising the same outcomes with reduced capacity would set the team up for burnout and failure. Neither is desired nor sustainable. We'll need to delay projects, or even better, cut the scope of delivery.

Team/Organization: Making selections based on personal bias, convenience, or purely short-term thinking could critically damage team capabilities. For example, cutting only less experienced people might seem the less painful decision, but it would be short-sighted because team seniority would be out of balance, potentially causing motivation-related problems in the future.

Similarly, and somewhat counterintuitively, I should not make my decision based mainly on performance. If someone performed below expectations, I should’ve dealt with it already. This is an externally-triggered multi-team layoff, performance was not the source of it.

Personal: Creating a culture of secrecy and mistrust by mishandling communications. Until decisions are final, this is the rare case when full transparency with the team isn't helpful. That being said, I should be honest if asked and share the high level: the company is expecting funding headwinds and other difficulties in the near- to mid-term future and, therefore, looking at options to ensure we're best prepared for any scenarios — and commit to share updates as soon as there are developments.

5 Questions

1. What is our future product direction with this smaller team, and what skills will that require? This is the most important question. I need to work closely with the Product Manager to discover together where we're heading. The selection criteria must focus on who can best serve this vision. With fewer resources, we must revisit the fundamental "why?" behind our initiatives. This might actually trigger creative solutions we wouldn't consider otherwise.

2. Is this task clear, and do I have the necessary support? Follow up with the Director because this is a new and critical task. Do I understand precisely what is expected from me, by when, and in what detail and format? Outside our comfort zones, we often make too many assumptions, I should avoid that. I should also discuss where I can get help and mentorship through this process, as things will likely move quickly once decisions are finalized, and I’m new in this.

3. What is the exact reason for the layoff, and what are the selection criteria? I need to be clear and confident in understanding this decision because this is the sole reason people are being let go. Any hesitation or lack of information can hurt future trust with my team.

4. What inter-team dynamics should I take into account? While the ask is a list of individuals, team dynamics cannot be ruled out. Some people work great together, and exploding two pairs like this might impact the entire team more than letting go of one of the pairs. This being said, it’s a minor concern compared to the aspects above.

5. How will I support both departing and remaining team members? For those leaving, I need a dignified process. For those staying, I need to help navigate the change: process survivor's guilt, fear for their own future, and increased pressure. The team will need psychological safety to prevent further attrition and clear expectations about how we'll operate with reduced capacity.

Did I miss any important considerations? Do you disagree with some of my points? How would you handle this painful but sometimes necessary part of engineering management? Let me know in the comments!

This Week's Challenge

You're an Engineering Manager for a mid-sized tech company. During your 1:1, Kate, one of your strongest senior developers, shares that she wants to transition into an engineering management role. She's been with the company for five years, has deep product knowledge, and has informally helped newer team members.

Your initial reaction is surprise mixed with concern. Kate is one of your technical anchors - losing her hands-on contributions would create a significant gap in your delivery capabilities. You've relied on her expertise to solve some of your most complex problems.

While you can see her potential for leadership, your team already has sufficient management coverage, and there are no immediate EM openings elsewhere in the company that you know of.

Kate seems earnest in her request, mentioning she’s starting to feel plateaued technically and believes management could be her next career challenge. She’s asking for your guidance and support.

What do you do?

Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly brain-teasers in the future.

Subscribe now

Until then, here's a small piece of inspiration to match this week's challenge:

See you next week,

Péter

I’m Péter Szász, writing about my engineering leadership experience on my blog, training aspiring and first-time Engineering Managers on this path. See more about what I might 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, we explored a situation in which a developer was offered their first management position through a surprise skip-level conversation. If you missed it, read the details here.

I'll approach this situation from the standpoint of that developer who’s being offered the Engineering Manager role, focusing on goals, risks, and 5 questions that can inform and guide towards the best decision.

Goals to Achieve

• Career Development: This should be a conscious career choice, not a path-of-least-resistance move. I need clarity on whether this aligns with my long-term career aspirations. Even if I decide to refuse the offer, it should be about preferences in developing technical skills instead.

• Support Structure: If I take this role, I'll need appropriate mentorship, training, and clear expectations during the transition.

• Team Continuity: The team is losing their manager already; if I step in, I need to ensure stability during this transition.

• Personal Fulfillment: I need to determine if I'd genuinely enjoy management, including leading people, rather than just taking it for status, compensation, or pleasing a leader.

Risks to Avoid

• Rushing a major career pivot: Taking a management role without proper consideration could lead to poor performance, career regression, and burnout.

• Overcommitting without support: Agreeing to step up without securing concrete mentorship and resources increases the risk of failure.

• Damaging team relationships: Transitioning from peer to manager will fundamentally change workplace dynamics that I value.

• Undermining technical credibility: Without a plan to maintain technical involvement, I could quickly lose the expertise that got me this opportunity.

• Creating a no-return path: Making the switch without establishing how I could return to IC work if management isn't the right fit.

5 Questions

1. What does success look like? I should ask the VP for specific expectations for my first 30/60/90 days. This helps gauge if the expectations are realistic and if I'd be set up to succeed or fail. What specific metrics would be used to evaluate my performance? Understanding the real definition of success beyond vague statements like "lead the team well" is crucial. This can also give some insights into how leadership sees the performance of my team.

2. What insights can the departing EM share? The topic might be sensitive, so I need to ensure them first that I’m keeping their confidentiality, but since they're leaving anyway, they have little reason to withhold critical information. I'd ask about team dynamics that aren't obvious, recurring challenges they've faced, and their honest assessment of what the role actually entails versus what's officially described. What would they do differently if starting over? Who needs what kind of support on the team? Which stakeholder relationships require special attention? Their unfiltered perspective could reveal important context the VP might not mention — or even be aware of.

3. How does the organization support management transitions? I'd ask both the VP and other EMs about mentorship programs, training, and other support during the learning phase. Is there an onboarding plan specifically for the transition from developer to manager? Does the company have examples of people who have successfully moved back to IC roles after management? Are there EMs who maintain technical expertise while managing?

4. How can I handle the shifting team dynamics? I need to think about how my relationships with colleagues would change, while considering ways we might preserve the most valuable aspects. My familiarity with the team's strengths and challenges should be an asset during this transition for all of us, as the other option for the team is to get an EM starting from zero context. How can I have honest conversations with them about this change? What are the risks we see, and what support would we need from each other? The trust we've built could enable us to work through this transition more openly, acknowledging that we're all adapting to new dynamics together.

5. What are my true motivations for considering this role? This self-reflection is critical. Am I drawn to management because I genuinely enjoy developing people and solving organizational challenges? Or is it about status, compensation – or maybe pleasing others? When I've coordinated work in the past, did I find satisfaction in helping others succeed? Can I honestly see myself energized by one-on-ones, performance discussions, and conflict resolution – or do these sound draining? What would I miss about being an IC? How would I feel watching others solve technical problems while I focus on people and processes? Can I find fulfillment in the team's technical achievements rather than my own? If I chose management and looked back in a year, what parts of my current role would I wish I still had?

The answers to these questions would shape my next steps. If I see a supportive environment around me and genuine motivations within, I might accept, with clear agreements about support, evaluations, and options. If not, I might propose alternatives like a temporary leadership role or a trial period. Otherwise, I should be clear that the current circumstances both within the organization and myself are pushing me towards continuing to develop on the technical track.

What's most important is recognizing that the technical-to-management transition is not just a promotion (at some organizations, it’s not even a promotion) — it's a career change. It requires new skills, new measures of success, and a fundamental shift in how one creates value.

Did I miss critical considerations? How would you approach this pivotal career decision? Let me know in the comments!

This Week's Challenge

You're an Engineering Manager for a team of 8 developers. Your company is stable but has decided to "tighten the belt" given market conditions. Your director has asked you to develop a plan to reduce your team by two people within the next month. You need to choose who to let go, and how to handle the situation with the remaining team members.

The team is a mix of senior and mid-level developers with various specialties. Everyone is performing adequately, though some are stronger than others in different areas. You've never had to let anyone go before.

What do you do?

Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly brain teasers in the future.

Subscribe now

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

See you next week,

Péter

I’m Péter Szász, writing about my engineering leadership experience on my blog, training aspiring and first-time Engineering Managers on this path. See more about what I might 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, we looked at a situation where a valuable team member expressed interest in moving to another team within the company. Read the details here if you missed it.

I'll frame my approach in four steps:

• Goals: what I want to achieve in this situation

• Risks: what I want to avoid and should be mindful of

• Questions: what do I need to discover to make the right decisions

Goals to Achieve

Execution: I need to ensure that delivery impact is minimized, by potentially descoping or reprioritizing work. The critical project is at risk, and I need to understand what can realistically be delivered within the six-week timeline without Jasmine.

Team/Organization: I should look at the bigger picture for the company. If Jasmine's skills are better utilized in infrastructure, the organization would benefit from this move, even if my team temporarily suffers. Given that I've only been with the team for eight months, I need to pay extra attention to the changing team dynamics this could cause.

Personal: Support Jasmine's career growth in the bigger context of business realities. Career development is crucial for motivation and engagement, which is key to high performance and retention.

Risks to Avoid

Execution: The project could be delivered late or with poor quality if not handled properly. Stakeholders might be surprised by the change, damaging trust. I should never surprise a stakeholder.

Team/Organization: This move could trigger a mass migration if other team members also feel their career aspirations are better served elsewhere. Jasmine’s motivation to leave the team might be hiding issues I haven’t discovered (or caused myself!) in my short tenure, issues that won’t be solved if I only focus on her move.

Personal: If I block or delay Jasmine's team change without empathy and a strong narrative, I will lose her trust and risk disengaging her completely. She might start quiet quitting and look outside the company instead even if she looks OK with the decision on the surface.

5 Questions

1. What's the real motivation behind Jasmine's request? Is it purely about her interest in infrastructure, or are there other factors in our team that might be pushing her away? Understanding this helps me address both her request and any potential underlying issues in the team.

2. What options exist for descoping or reprioritizing the project? While working on the details of a potential transition, I need to prepare for losing Jasmine. I should talk with the Product Manager about what's truly essential for the six-week deadline. What's the minimal viable product we can ship that still delivers value? This is critical regardless of how we handle the career move.

3. Could we redistribute work instead of people? My strong belief is that high-performing teams shouldn't be disrupted without good reason. Could we incorporate more infrastructure work into our team's scope instead? What exactly does the infrastructure role entail, and could we take on some of those responsibilities while offloading other work? This would make us truly own the full vertical of our product while giving the infrastructure experience that Jasmine's craving.

4. Who on the team could potentially step up if Jasmine leaves? This is both a risk assessment and an opportunity identification. Is there someone who could grow into Jasmine's responsibilities, even if it creates a temporary gap elsewhere? This could be the silver lining of a development opportunity for someone else.

5. How determined is Jasmine, and what transition timeline might work? If this specific opportunity doesn't materialize, would she look outside the company immediately? Could we structure a gradual transition that allows her to start a new role while completing critical project components? Maybe satisfy her motivation to learn with specific infrastructure-related development goals and an assigned mentor within the company? Understanding her urgency and flexibility helps craft a workable solution.

Did I miss any important considerations? How would you handle this situation? Let me know in the comments!

This Week's Challenge

You’re a senior developer in a tech scaleup. On a skip-level 1:1 with the VP of Engineering, she confidentially shared that the Engineering Manager of your team will be leaving for another job. She offered you the opportunity to step into the EM role, mentioning she’s been impressed with your technical leadership and task management abilities. While you've done architectural work and have experience breaking down and coordinating tasks across the team, you've never had people management responsibilities before.

You're motivated by the opportunity but at the same time, worried this might be a career-impacting mistake. You don't want to fail the team, damage your reputation, lose hard technical skills, and shrink your future career options.

What do you do?

Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly brain-teasers in the future.

Subscribe now

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

See you next week,

Péter

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 might 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, we looked at a struggling senior developer going through personal issues that start to impact his work performance. Read the details here if you missed it.

I'll frame my approach around these in three steps:

• Goals: what I want to achieve in this situation;

• Risks: what I want to avoid and should be mindful of;

• 56 Questions: what areas I want to discover to make the right decisions.

Goals

Execution: I need to stop the pattern of mistakes. Our team's work quality and delivery timelines are at risk. The recent production incident is a symptom of a deeper problem.

Personal: I want to support Ivan through his difficult time while maintaining appropriate performance standards. Understanding what support would actually help him is key.

Team: I need to protect the team from carrying an unfair burden, potential resentment, damaged external image, and above all, the risk of normalizing substandard work.

Risks

Execution: If I delay intervention, more mistakes will happen, negatively impacting the quality and performance of the products and services our team is responsible for. If I overreact, I might create a culture of fear, where people are reluctant to take risks, and mistakes are frowned upon. (See my thoughts on Celebrating Failure here.)

Personal: Ivan might perceive any intervention as a lack of empathy during his personal crisis, and pushing him too much might break him. On the other hand, ignoring performance problems could enable a downward spiral that becomes harder to address later. Any delay in actions sends two bad messages: that this performance is acceptable, and that I don’t care about him enough to recognise he’s suffering and offer my support. Altogether, the risk of losing a valuable developer is high if I don’t act promptly and with care.

Team: Ivan's struggles, especially after the incident, are clearly visible to the team. Not addressing it openly could suggest I have different standards for different team members, breaking trust and team cohesion.

6 Questions

(Yeah, I know this is usually 5, but I felt all of these are important to think about.)

1. How aware is Ivan of the impact of his actions? His reaction when turning off tests to meet deadlines - was it a conscious "I know this is wrong, but I'm desperate" decision, or does he genuinely not see the issue with his approach? In addressing performance problems, I always start with aligning on the problem itself with the impacted person. Do they see the problem? Do they agree that this is a problem? This alignment is a necessary prerequisite to move the discussion towards performance improvement. In this case, this can also make the difference between the need to support hard skills (testing philosophies) or soft skills (time management, focus, etc.) development.

2. Did I create a Culture of Safety? There are potential red flags in the story. If Ivan didn’t trust me before to share his struggles and ask for help, if he wanted to push through the pain and cut corners out of fear, without involving me, the person who he should trust most to give him the support he needs, then maybe I’m involuntarily sending signals that contradict safety and trust.

3. Do I truly believe Ivan can improve? It’s a tough question, but it addresses the key in supporting a low performer. Without this faith, it’s better for everyone to move things towards a clear closure, where Ivan moves to another role, team, or company. I saw a lot of people improve their performances from bad situations, but not one without the faith of their manager in their capabilities to succeed. On the other hand, many times I witnessed managers secretly losing faith in someone on their team, but delaying the inevitable unnecessarily long, therefore hurting the person, the team, and the organization.

4. What specific support would help Ivan right now? Often, people don't need a reduced workload but rather more structure, clearer priorities — or to the contrary: less structure and more flexibility in when, how, and where they work. Others might need temporary adjustments, perhaps more frequent pair coding or mentorship situations. Either way, we have to figure out together how the team and I can help him, and I should make him understand it’s OK to ask for help.

5. What’s the external impact exactly? The incident might be the top of the iceberg only. I need to check in with stakeholders, peers, and fellow teams to ensure there are no problems left undiscovered — and to enforce the message that we’re handling the issues.

6. How is the team experiencing this situation? Are they aware, frustrated, sympathetic, or taking on extra work to compensate (and hide the problems)? Is there someone else who needs my attention, but I can’t see them because I’m focusing on Ivan? Understanding the team dynamics helps me tune my approach and might lead me to discover other areas that need attention. Related, but Ivan might not be comfortable sharing all the details with the team. I should get clarity on that and respect his need for privacy.

I've faced variations of this situation multiple times, and there's no one-size-fits-all solution. The most effective performance improvement programs I've seen are based on empathy, combining clear expectations with genuine support, and a concrete plan with frequent check-ins that both the person and their manager feels can be achieved.

Use these pointers to plan your approach: Empathy, clarity, support; plan, check-ins, faith in success.

Did I miss any important aspects? What would you do in this situation? Let me know in the comments.

This Week's Challenge

You've been managing a small team for eight months when Jasmine, one of your most reliable engineers, comes to you with a surprising request. She wants to transition to a more infrastructure-focused role and has found an opening on another team within your company that interests her.

Your first reaction is dismay - you're already understaffed, your commitments are tight, and Jasmine is leading a critical project that's due in six weeks. Her leaving now would put your delivery timeline at serious risk. However, this is clearly an opportunity she's excited about that would give valuable experience to her career progression.

What do you do?

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

Subscribe now

Until then, here's a small piece of inspiration to match last week's challenge, about an important aspect I left out to keep this article’s length at bay:

See you next week,
Péter

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 might 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

We had a hostile email coming in last week, complaining about the most senior developer on our team. Read the details here if you missed it.

Continuing last week’s structure, I’ll approach this situation in three steps:

• Goals: what I want to achieve in this situation;

• Risks: what I want to avoid and should be mindful of;

• 5 Questions: how I get the missing information to be able to choose my actions.

Goals

• Execution: I want to de-risk delivery. Seems like these engineers are at a communication stall, which has a significant chance of delaying both teams. I need to unblock them.

• Personal: I want to support Hailey. I need to discover why she didn’t mention any problems yet, and what’s her assessment of the situation. Finally, I have to understand if she’s capable of resolving the conflict herself or I need to intervene.

• Team / organization: I also want to support George. His email sounds desperate and frustrated. While I’m not managing him, I need to ensure we’re collaborating well.

Risks

Outcomes I want to avoid:

• Execution: If they are arguing for weeks on API design, at the root, they might have different assumptions, which means (at least) one of them is wrong, which could lead to increased tech debt by developing the wrong things at the wrong time.

• Personal: If I take George’s criticism without challenging it, I risk losing Hailey’s trust. Digging into the technical details might make Hailey feel like her autonomy is being taken away. On the other hand, if she’s technically lost, I need to get more hands-on or find someone to give her the appropriate level of support.

• Team / organization: Pushing back strongly to George has a risk of building a culture of “us versus them”, making future collaborations even harder. Talking to George’s manager instead of him would send the same bad message that his email about Haley had to me.

5 Questions

1. How is the project progressing, according to Hailey? How is the collaboration between the two teams? These can help me get more context and hear out Hailey’s point without taking sides. Depending on her answers, we can jump into finding a solution, or uncovering why she has a different perception of the situation.

2. How capable is Haily of handling this situation? It’s difficult to balance changing product requests and negotiations with a more senior engineer than you. Maybe she needs more concrete help from me, her task-relevant maturity could be too low for this.

3. How are the API designs discussed? Can we move from a request-reply process to a more collaborative one? Could Hailey pair with George and create an RFC together?

4. Is there a way to gradually release and iteratively improve this API? What’s the bare minimum core feature set that covers at least one use case that could be released to production to get feedback from real-world usage? This would move the arguments away from assumptions and beliefs, and closer to facts and data.

5. Why didn’t George discuss this with Hailey directly? Why did he feel the need to escalate? How can George be supported to be able to give more efficient feedback? Timely, concrete, direct to the person. Is this something his manager is working on with him? He clearly cares about the health of our codebase, so he should be interested in how he could get what he wants more efficiently.

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 in the comments!

This Week’s Challenge

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

Ivan, a senior backend developer, is struggling in his role. He was hired a year ago and seemed to hit the ground running, but in the last few weeks, he’s had multiple late deliveries and seemingly careless oversights. Yesterday, to meet a deadline, he turned off a test that seemed flaky but actually would’ve caught the bug in his code, causing a production incident when going live. You know he’s going through a difficult divorce, so you were willing to ignore some of the early signs, but it’s probably time to intervene now.

What do you do?

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

Subscribe now

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

See you next week,

Péter

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!

Leave a comment

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:

Subscribe now

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

See you next week,

Péter

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:

Subscribe now

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

See you next week,

Péter