Software Engineering Manager, հեռավար աշխատանք

Այս հայտարարությունը հրապարակել է LawnStarter ընկերությունը, փնտրվող պաշտոնը՝ Software Engineering Manager։ Սա ղեկավար մակարդակի պաշտոն է, այսինքն պատասխանատվություն ամբողջ թիմի կամ մի ուղղության համար։ Պաշտոնը «IT և ծրագրավորում» կատեգորիայից է և ամբողջովին հեռավար։ Ընկերությունը չի սահմանափակում թեկնածուի բնակության վայրը, ուստի կարող եք դիմել այնտեղից, որտեղ ապրում եք։

Գործատուն թիվ չի հրապարակել, հարցը լուծվում է հարցազրույցին։ Աշխատանքային ժամերի վերաբերյալ հայտարարությունը պայման չի դնում։

Այս թափուր աշխատատեղն անցել է ավտոմատ ստուգում. ցանկ չեն մտնում այն հայտարարությունները, որոնք պահանջում են օտարերկրյա աշխատանքի թույլտվություն, վիզայի հովանավորություն, որոշակի քաղաքացիություն կամ նշված երկրում բնակություն։

Headquarters: Brazil

URL: http://lawnstarter.com

About LawnStarter

LawnStarter is the nation's leading on-demand marketplace for lawn care and related services, with over $100M in annual bookings. We're expanding beyond lawn care to become the one-stop shop for all outdoor home services - pest control, pool cleaning, window cleaning, and more.

About Engineering at LawnStarter

Our engineering team builds the platform that connects hundreds of thousands of homeowners with over 70,000 active service pros. We operate three brands (LawnStarter, Lawn Love, HomeGnome) on shared infrastructure, and we're profitable and growing. Engineering here is fast - we ship constantly, we own our systems end-to-end, and we don't tolerate "not my problem." We have strong processes and existing engineering managers, so you're not building from scratch. You're raising the bar.

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 makes this role different:

- You'll own both delivery AND people outcomes - neither can be delegated

- Distributed team across time zones, so async leadership and written communication matter as much as meetings

- We move fast and actually ship - you'll feel the difference between a team that's humming and one that's stuck

- AI-forward is not a buzzword here - we expect you to lead your team on how to use it, not just follow along

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.

Problems to Solve

Building people leadership depth as the team scales

LawnStarter is expanding into new service verticals quickly. That means new headcount, new complexity, and more pressure on EMs to develop the next generation of senior engineers and tech leads - not just ship features. We need an EM who's done this before, not one who's figuring it out.

Managing distributed teams without losing culture or accountability

Our engineering team spans multiple time zones and countries. Async communication, remote 1:1s, and distributed sprint ceremonies are the norm - not a workaround. An EM who needs daily in-person proximity to lead effectively won't thrive here.

Turning delivery consistency into a competitive advantage

We have product-market fit and real momentum. The constraint now is shipping reliably enough to compound on that momentum. Your team's velocity and predictability directly affects LawnStarter's ability to launch new services and capture market share.

Orchestrating cross-functional delivery from roadmap to release

An EM here is the connective tissue between Product, Design, and specialist functions - quality engineering, architecture, and security - from estimation through delivery. The hard part isn't running any one of those conversations well; it's running all of them in parallel without becoming the bottleneck they route through. We need an EM who can hold business value and technical soundness in view at once and make the tradeoff calls - not one who stalls when Product wants speed, Security wants rigor, and Architecture wants the durable answer.

Turning AI adoption into throughput without sacrificing craftsmanship

We're not experimenting with AI on the margins. Claude Code, spec-driven development, and AI-assisted review are becoming default workflows here - and we track adoption seriously. We need an EM who can turn "the team uses AI" into measurable throughput without letting quality slip, with real opinions about where AI helps and where it quietly creates debt.

What Success Looks Like (Year 1)

- Every engineer on your team has a documented growth plan within 60 days - and you can speak to it from memory

- Your team ships its committed scope on cadence within 90 days

- Zero surprise departures - you know your retention risks and are actively working them

- Underperformance is addressed directly and documented, not deferred

- The Head of Engineering trusts your team's commitments because you've proven they're reliable

- Your team is visibly more AI-enabled than when you joined - new tools adopted, old manual tasks automated, engineers unblocked faster

Requirements

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…