An Australian construction-tech company — the kind that turns site photos and audio into structured records — is hiring an Engineering Manager. Sydney or Melbourne. Hybrid. AUD $140,000–$170,000 including super. The job is to lead engineers, run sprints, unblock people, ship code, and make sure work moves from "ready to build" to "shipped and stable" with a predictable cadence.
That's a lot of words for a role about to become a thin layer of glue between a product manager and a codebase that writes itself.
What the job really is
The posting is unusually honest about the split. The Product Design Manager owns the what: scope, design, acceptance criteria, monitoring. The Tech Lead owns technical quality and architecture. The Engineering Manager owns the how: engineering capacity, sprint planning, unblocking engineers, and the quality of the engineering process. They also deliver code themselves.
So the EM is a delivery mechanic. They make sure the right tickets are in the right state, the right engineers are working on them, nobody is stuck, and the thing ships on time. A human kanban board with empathy and a keyboard.
That is a remarkably automatable job description.
What automates first: sprint planning and capacity
The EM's first job is to look at a backlog, look at team velocity, look at engineer availability (leave, part-time, other commitments), and decide what goes into the sprint. This is a constraint optimization problem with known inputs. A language model with access to the issue tracker, the team calendar, and historical throughput can produce a sprint plan as good as the median EM's, and it can do it in seconds instead of a 90-minute planning ceremony.
The pipeline is straightforward. Pull closed tickets from the last six sprints to estimate each engineer's effective velocity per ticket type. Pull the open backlog, rank by the PDM's priority. Apply a bin-packing algorithm weighted by each engineer's skill tags — frontend, backend, infra, domain familiarity. Subtract known absences. Output a sprint. The EM currently does this in their head plus a spreadsheet plus a Jira board. The model does it with a script and an API call.
What about the "unblocking" part — the EM sitting in standups, hearing someone say they're stuck on an auth issue, and either helping directly or pointing them at the right person? That's a triage function. A model monitoring standup notes or the Slack channel where engineers post blockers can classify the blocker type, match it against the codebase and internal docs, and either return a solution or route it to the engineer most likely to know the answer based on git blame and past PR history. The EM was a router. Routers are software.
What automates second: code delivery
The posting says the EM "delivers code themselves." This is where it gets uncomfortable. The kind of code an EM delivers on a product team is rarely the hardest part of the system — it's features, bug fixes, integrations, glue. That is exactly the category of work that AI coding agents now handle competently. An agent connected to the repo, the issue tracker, and the acceptance criteria can draft a PR for a well-specified ticket, run the test suite, fix what breaks, and open the PR for review.
The EM's "how" — the engineering process, the quality gates, the definition of done — becomes a configuration file. Branch protection rules, required CI checks, automated test coverage thresholds, PR templates that require the PDM's acceptance criteria to be checked off. The process the EM enforces through social pressure and standup nagging is enforced by GitHub Actions instead, and it never forgets and never has a bad Monday.
What automates third: the people part
Here is where the posting gets sentimental. The EM is "responsible for the engineers in their team, including their performance, growth, and day-to-day execution." Performance reviews. One-on-ones. Career conversations. Coaching.
This sounds human and safe. It isn't. It gets hollowed out first, because it's the part with the least defensible structure.
Performance feedback at this level is mostly pattern matching: is this engineer shipping, is their code quality trending up or down, are they unblocking others, are they growing into new areas. All of that is observable in the system of record — PRs, reviews, tickets closed, incidents caused, incidents resolved. A model that ingests six months of git history and Jira activity can write a more evidence-grounded performance summary than most EMs, who are working from foggy memory and a few scribbled notes.
The one-on-one — the coaching conversation, the "how are you really doing" — survives longer. But it survives as a shrinking fraction of the role, and it gets done by someone no longer called an Engineering Manager because they no longer manage engineering. They manage morale. That's a different job, and it doesn't pay $170,000.
Where it breaks
The system breaks at ambiguity. The PDM writes acceptance criteria, but acceptance criteria are always incomplete. Tickets say "implement X" and X turns out to mean three different things depending on who you ask. The EM's real job — the one that doesn't fit in a pipeline — is sitting in the gap between what the PDM wrote and what the engineer built and figuring out which interpretation serves the customer. That is a negotiation. It requires knowing the product, the customer, the codebase, and the humans well enough to make a judgment no one involved can articulate clearly. A model can draft a better sprint plan. It cannot yet sit in a room with a frustrated designer and a defensive engineer and produce the third option neither of them saw.
The system also breaks at hiring. Reading a CV, running an interview, calibrating against a team's culture and needs — the automated versions of this are bad enough that companies still pay recruiters and EMs to do it by hand. The model can screen for keywords. It cannot yet screen for "this person will thrive in this specific team's chaos." That judgment is still human, still expensive, still worth paying for.
And the system breaks at trust. Engineers follow an EM they trust into a sprint they think is wrong, because they trust the EM to fix it when it goes sideways. No one follows a script into uncertainty. The social contract of delivery is a relationship. The model can optimize the sprint. It cannot be the person someone talks to when they're thinking about quitting.
The verdict
The role doesn't vanish. It shrinks and changes shape. The sprint planning, the unblocking, the process enforcement, the code delivery — that's a pipeline now. The ambiguity navigation, the hiring, the trust — that's still human, but it's a much smaller job, and it doesn't need a full-time manager per team. One person could hold the trust-and-judgment layer for three or four teams, because the mechanical layer is gone.
This company is hiring someone to manage engineers at a company that builds AI agents to replace human work. That's a roadmap. They already know what it looks like when a human role becomes an API call — they're selling that transformation to construction companies. The only question is whether they'll buy it for themselves before or after this hire settles in.
If you're the person who takes this job, enjoy the standups. They won't last.
