How the Engineering Manager role is evolving

The Engineering Manager is the most misunderstood role in a startup.

Before AI agents could write code, the job revolved around coordination: sequencing projects, moving information between product and engineering, managing dependencies and blockers.

But as agents took over more of the implementation work, the EM role becomes less about coordination and more about verification and accountability – making sure that shipping speed doesn’t compromise quality.

Here's how the role of Engineering Manager has evolved at Seapoint, and some of the lessons we’ve learnt along the way.

Why coordination got easier

To avoid overstretching coordination cost, I used to run a limited number of projects at any one time. Now with AI, one engineer can ship a substantial amount alone, so the engineering team can take on more projects in a sprint.

Instead of assigning three or four engineers to a project, I can now pair one or two engineers up with a product manager and give them the full autonomy over the project. This way, the PM and engineers can align, decide and deploy without coordination overhead slowing them down.

The same team, shipping a multiple of last year’s code:

But coordination was never the entirety of an EM’s job. EMs are still accountable for the outcome and the quality of work produced by the engineering team, and with AI playing a more poignant role in the process, it has to be owned more deliberately.

The EM is accountable for the engineering team’s work

When an engineer writes code, they own the output. They understand the way the code is written, and are better placed to pinpoint bugs and fix mistakes.

When AI writes code, accountability for the code isn’t so clear. Nobody fully understands the code the way they would if they’d written it themselves, and any mistakes made are much harder to spot in review.

As Engineering Manager, my job now is to be accountable for how fast the team can safely move. While moving faster doesn’t automatically mean lower quality, output accuracy can slip very quickly if left unmanaged.

That’s why I spend a lot of my time building and improving the infrastructure that catches mistakes before customers do.

Agents need permission boundaries

There are horror stories of AI deleting production in a matter of seconds, warning engineers that AI is unpredictable. But to me, these errors don’t come from erratic software – somebody just hadn’t set up their infrastructure correctly.

If AI has unconstrained access to production data, it’s likely missing the boundaries it needs to know the code shouldn’t be touched. In practice, this is fairly unglamorous work: for every agent we have, we need to make sure it has exactly the permissions it needs to do its job, nothing more, nothing less.

Every service operates under the principle of least privilege, and every new capability goes through an extensive security review before it can touch production data. It’s stringent and time-consuming work, but essential for ensuring the team can move quickly without breaking anything.

End-to-end tests matter more

In an interview with The Pragmatic Engineer, Charity Majors, CTO and co-founder of Honeycomb, poses the question: what would it take you be fully comfortable shipping code you haven’t read?

In Majors view, it’s building a system that validates this code. That’s why we’ve doubled down on end-to-end testing.

At Seapoint, we’ve built end-to-end test infrastructure that simulates a real user session. Every time we ship, a headless browser logs in, sets up an account, runs through transactions, opens the reporting view, and checks that the numbers match what we expect.

As well as writing end-to-end tests, the agents are capable of automatically adjusting when the UX changes. Before, keeping end-to-end tests current was an expensive and time-consuming endeavour, especially when shipping at velocity. Now, they’re cheaper to build and maintain.

With this system in place, we’ll know whether AI-generated features work or if they need engineer input, helping us ship code with confidence.

People management matters more than ever

There’s a narrative that AI is reducing work, but what we’re actually seeing is the opposite.

Here’s what our engineers said in our latest pulse survey:

For engineers, AI is addictive. What used to take a day now only takes an hour, giving you the scope to take on more ambitious problems and ship a whole lot more.

Working in a startup is already high-intensity, and with AI speeding things up, engineers can very quickly slip into overworking. Without being managed, this can lead to burnout, and as EM it’s my responsibility to make sure that doesn’t happen.

The takeaway for EMs

If you're running an engineering team with AI in it, three things seem to matter regardless of stack or team size.

First: own the verification system explicitly, as speed without safety is a recipe for disaster.

Second: test the whole system. Unit tests still have their place, but your confidence signal for AI-written code should come from end-to-end tests that simulate user behaviour.

Third: pace your people deliberately. AI creates the conditions for overwork by making high-effort feel low-friction. It’s your job to help your team ship fast without burning out.

While coordination is less of an overhead for EMs, there’s still plenty to focus on. Now, quality control and people management are what I think will define the EM role in the years to come.