When daily sync is a trigger for changing org. structure, this is a classic case when the symptoms hide the real sickness. The engineering team was struggling, but it was not their fault and their "solution" in the end forced some people to leave. It is sad. The actual sickness: inexperienced middle management, not aware of best practices. 11 direct reports are too many to maintain awareness of their work and their well-being.

How it should have been solved?

1. 2 or 3 smaller teams supported by product manager. More cohesion, more focus on long-term business objectives, more end-to-end long-term ownership (but high enough bus factor). Have daily sync within those teams and let someone well-socialized steer it, do not make it a report, instead focus on cooler talk and one big task that is currently in their mind. Force them to omit details and schedule ad-hoc talks or go async if they want to go into details. The primary objective of daily sync is to keep people connected, not to keep them updated.

2. Maintain specialization and expertise. When there is a dependency, people are forced to collaborate, build bridges and improve efficiency of communication. When one generalist completes the whole task, the smaller is the knowledge transfer. Generalists are good for one-off tasks, but building a product requires a team.

3. Use horizontal organization for engineering excellency. Call it chapters or whatever you want, but make engineers from different teams working on the same stack meet regularly to present ongoing work, discuss technical topics and technical strategy. Have async channels for that communication too (e.g. pull requests for something noteworthy).

4. People over processes, processes for people. If something does not work, use retro to fix it. Sometimes applying solution to the whole team won't work, but it may work on personal level - do it, as long as everyone remains productive and happy.

People should at least understand that "generalist" route with modern frontend and backend is nearly impossible today, especially when stacks are different. They are vastly different domains developing at a high speed. Nobody is able to maintain up to date knowledge of them both while doing sufficient amount of work without getting burned out quickly.

I think your approach would work for a larger company than the article was about.

Edit:

> "generalist" route with modern frontend and backend is nearly impossible today

This is simply not true; it all depends on design and organizational priorities. An organization can choose to use the same language in the UI and server, and prioritize the compromises that come with same language development. (IE, C# + Blazor, or Typescript + NodeJS.)

Every situation is different. It really depends on so many factors: what are skills, traits, and preferences of the individuals? How top down are requirements vs bottom up? How distributed is the team? Does the team work on platform, product, or infrastructure? There is no one sized fits all answer to what works best in all situations.

Honestly, I think there are no "best practices" here, there's simply "patterns I've seen work before".

If we put people over processes, you might actually find you can manage a much bigger org. Like if the standup is really killing large parts of the week, you might find killing the standup to be the preferable option. The fact that that's sacrilege and constantly evokes the no true Scotsman tells you all you need to know about people over processes.