Software Engineering Manager

The Role

We're growing, and that means adding engineering leadership capacity to support new initiatives. You'll lead cross-functional delivery teams of 4-5 engineers, reporting to our Head of Engineering. Your job is to make sure your team ships reliably, grows professionally, and doesn't become a bottleneck as LawnStarter scales into new service verticals.

This is a people-first role. If your identity as an EM is primarily technical - if you'd rather review architecture than develop an underperformer - this isn't the right fit. If you're the manager who knows what every person on your team needs to grow, who handles conflict directly, and who can articulate team performance in metrics, keep reading. 

What You'll Own

• People development: Concrete growth plans for every IC on your team - not just the struggling ones. You know where each person is going and what it takes to get there
• Delivery: Your team ships on cadence with predictable quality. You surface risk early, manage scope, and don't miss commitments without warning
• Team health: Conflict gets addressed directly. Underperformers are managed with a clear process. Top performers are protected and developed
• Cross-functional partnership: You're the interface between your team and Product, Design, and other engineering teams. Decisions get made, not stalled
• Technical direction: Close enough to the work to weigh in on system design and catch architectural risks. Not so close that you're in the weeds instead of removing blockers
• AI adoption: You're actively introducing AI tools and workflows into how your team operates - code review, documentation, sprint planning, debugging. You set the pace, not follow it

Who You Are

• Deeply AI-integrated, not just AI-aware. You've gone well past "I use ChatGPT to write emails." Your engineers expect you to bring new AI workflows to the team - you've used Claude to accelerate code review, built prompts that help engineers write sharper tickets, or led your team's adoption of Copilot in the development workflow. When you see a task eating team time, your first instinct is to figure out if AI can handle it. You're actively experimenting, sharing what works, and setting the pace on AI adoption for your team - not following someone else's lead. This is unlikely to be a good fit if your AI usage stops at occasional prompting, if you're still evaluating whether the tools are worth the learning curve, or if you'd describe yourself as "AI-curious" rather than AI-native.
• A people developer, not just a delivery manager. You can give concrete examples of career growth plans you've built, hard conversations you've had, and underperformers you've managed through a structured process. You spend your 1:1 time on people, not status updates. This is unlikely to be a good fit if your management examples are mostly about process improvements or shipping milestones - or if you tend to blame team outcomes on the engineers rather than the environment you built.
• Remote-native. You've led full-remote teams before - not just as a workaround during COVID, but as a default. You know how to build trust without shared physical space, how to run async decision-making, and how to keep distributed engineers from feeling isolated. This is unlikely to be a good fit if you haven't managed a fully remote team in a leadership position, or if you feel like remote work is harder than in-person management.
• Direct in conflict. When there's tension on the team - between engineers, between engineering and product, between a team member's performance and what's expected - you address it directly and quickly. You don't let it simmer. This is unlikely to be a good fit if you've left roles or situations because of unresolved conflict, or if your conflict resolution examples are mostly about "creating space for dialogue" without resolution.
• Data-driven about people and delivery. You can articulate your team's performance in metrics - not just vibes. You track velocity, retention risk, and IC growth, and you use that data to make decisions. This is unlikely to be a good fit if your answers to performance questions are mostly common-sense observations without examples tied to specific numbers or outcomes.
• Technically credible. You stay close enough to the code to earn your engineers' respect - code reviews, architectural input, helping debug under pressure. You don't need to be the best engineer in the room, but your team needs to believe you understand what they're doing. This is unlikely to be a good fit if you've fully transitioned to pure management and haven't touched technical work in years.
• A delegator, not a bottleneck. Your job is to build a team that makes good decisions without you - not to be the person all decisions flow through. You coach engineers toward answers rather than providing them. When you go hands-on, it's deliberate and time-bounded, not a default. This is unlikely to be a good fit if your instinct when a team struggles is to take over, if you find yourself becoming the access point for all requests, or if your team's output goes down when you're unavailable.