The word software in the title usually means you're not the only kind of engineering in the building. You run the people who write the code, but your release date is tangled up with hardware, firmware, test labs and sometimes an auditor. This page walks through one ordinary day at a company that ships a connected device and the apps and cloud services behind it.
At a pure software company, the job is usually just called engineering manager, because everyone there writes code. The software label tends to show up where it has to be told apart from mechanical, electrical or manufacturing engineering. That changes your week more than you'd expect. Your team can't ship whenever the pipeline is green, because the app has to match a firmware version that's already on devices in people's homes. You'll sit in program reviews run by a hardware lead who thinks in build phases and parts lead times, not sprints. You also end up translating in both directions: telling the hardware side why a backend migration can't be squeezed into a week, and telling your engineers why a board revision means the Bluetooth pairing flow needs rework. Managers who come from web companies often find this slower pace maddening at first. The ones who stay learn to plan around fixed dates they don't control.
Before your coffee's cool you're in the CI dashboard. The nightly integration run against the hardware-in-the-loop rig failed, and a firmware engineer has already started a Slack thread blaming the mobile app's new pairing code. You read the logs just far enough to see it's a timeout, not a crash. Then you assign it to the engineer who wrote the pairing change and ask the firmware lead to pair with her for an hour. Fixing it yourself would be faster this morning and worse for the team by Friday.
Standup is quick because the Jira board already says most of it. Your one-on-one right after is with a backend engineer who's been quiet in design reviews. Halfway through, he tells you he's thinking about moving to the platform team. You don't argue. You ask what he'd want to be doing that he isn't, write it down, and promise to come back next week with something real, maybe ownership of the device telemetry pipeline he keeps complaining about.
This is the weekly meeting with the hardware program manager, the QA lead and the firmware manager. The release was on track until the hardware side mentions, almost in passing, that a supplier swapped a sensor part. Firmware needs a driver change, and the app's calibration screen reads values that are now scaled differently. You have to decide on the spot what drops. You cut the redesigned settings screen from this release, keep the calibration fix, and tell the product manager before she hears it secondhand. Nobody in the room is happy, which is often the sign you made the right call.
A senior engineer has written a design doc for moving device commands off a polling loop and onto a message queue. You don't review every pull request any more, but you do read every design doc that touches the device boundary. You leave comments about rollback: what happens to devices still running the old firmware if the new service goes down. That one question is the part of your engineering background you use most. It also shapes the test plan QA will write next week.
The interview panel debriefs on an embedded-adjacent candidate who was strong on C but shaky on the cloud side. You push each person to say what they saw, not what they felt, before anyone gives a yes or no. The team splits. You make the call to extend an offer with a clear plan for the gap, write the justification in Greenhouse, then look at tomorrow: a quarterly planning session with the hardware director and two more one-on-ones. You block an hour in the morning to read the rest of the sensor change notes before anyone asks you about them.
This is the most common route. You already know the codebase, the device quirks and the hardware leads by name, so the company takes less risk on you. It usually starts with running a small group of engineers informally, then taking over hiring and reviews when the manager above you picks up another team.
If you've been running sprint planning, writing the release notes and sitting in the program review for your team, you've done a lot of this work without the title. Say so plainly on your résumé, with the release dates you hit and the people you mentored, and apply for manager roles at companies that build hardware or regulated products.
Managers from pure software companies get hired into these roles when they can show they'll respect a slower, gated release process. Read up on how firmware updates reach devices, learn the words the hardware side uses, and be ready to explain how you'd plan around a date you don't control.
13% of openings are fully remote.
$144,300 – $226,276
Typical range in the 42 of the newest 60 postings that list pay.
The work is mostly the same: hiring, one-on-ones, reviews, planning and keeping delivery honest. The difference is context. The software label usually means the company also has hardware, firmware or other engineering groups, so you'll spend more time coordinating release dates, test labs and change control with teams outside your own.
A little, and rarely on the critical path. Most keep their hands in through design reviews, reading pull requests on risky changes, and the odd internal tool or script. If you're the one blocking a release because your own code isn't done, the team has lost its manager for that week.
The page shows the figures. What moves them is the size of the team you run, whether the company is a software firm or a hardware firm with a software group, the industry you're in, and how much of the release decision sits with you. Regulated industries like medical devices and automotive often pay for managers who've shipped under an audit trail.
HeroApply applies to them for you, so you can keep doing the job you have.