Methodology

I’ve been hearing about engineering teams that give developers broad ownership of their work, with very few recurring meetings.

A former colleague now at Mistral and a friend who’s been at Synthesia for a while have both described this kind of environment in their teams. There are still 1:1s, but much of the day-to-day organisation sits with individual developers.

For years, conversations about team methodology often came down to Scrum, Kanban, or some combination of the two. These accounts have made me curious about where coordination happens when fewer decisions are organised around scheduled meetings.

There are other examples. Ashby describes engineers owning projects in “teams of one”, without sprint planning. At PFF, a two-engineer AI pilot replaced Scrum ceremonies with automated updates and feedback huddles every other day.

I can see the appeal, particularly for remote work. Clear outcomes, time to concentrate and room to decide how to approach a problem can make for a rewarding working environment.

What interests me most is the scope of that ownership. A developer’s responsibility can extend from understanding the problem to deciding the scope, building the solution and checking whether it helped. That asks for judgement about when to act independently, when to involve colleagues and when to ask for help. Shared priorities and the wider system still matter.

This approach predates the latest AI tools. My suspicion is that AI could make it practical for more kinds of work, by helping one developer take a problem further before needing a handover. That makes the way we organise work worth examining alongside the tools themselves.

The supporting practices seem important. Synthesia’s published account describes written proposals, daily async updates and clear objectives. It also emphasises hiring experienced engineers. There is a deliberate way of keeping people informed behind the relatively empty calendar.

As a manager, I’d want to understand what a team gets from its current routines before changing them. Planning together can uncover a dependency nobody had noticed. A retrospective can give someone space to raise a problem they wouldn’t mention in a project update. Any change would need to preserve those benefits.

I’d like to understand the effects over time, on delivery and on people. How quickly do useful changes reach users? How much rework follows? Do developers feel trusted, supported and able to learn from one another?

I’d be particularly interested in how those answers change as teams grow and new people join.

Originally published as a LinkedIn post.