Some quick thoughts:

• Sub-teams are a good idea: 11 direct reports without any structure is too large for a workable team (you won’t have enough time for direct coaching, and team meetings with that many people will tend to be unproductive).
• Consider separating operations out from development – it’s a slightly different skillset and being interrupted by operational issues all day can seriously harm development productivity on projects.
• As a result of the first two points, I think you should have perhaps 3 subteams – Intranet, External Sites and Operations. The operations guys will deal with all day-to-day issues / maintenance fixes etc. while the two development teams focus on delivering new projects / value to the business.
• Cycle people between teams on a regular basis. This can be either occasional (e.g. having people do review of code in another subteam), for a project or on a permanent basis. But make sure it is understood that team roles will change whenever there is a business need – nobody “owns” a specific role forever.
• Don’t add more managers/administrators – this is a surefire way to reduce the overall effectiveness / productivity of your teams. Have the most experienced person in each subteam play a team lead / coach role. Make sure that they see their role here as coaching and making the whole team succeed, and make sure that they are equipped to behave in this way rather than act a “task manager”.
• Your role should be focused on external stakeholder management, prioritisation of resources / tasks within the group, and acting as “head coach”. You’ll need to handle the occasional escalated issue from the sub-teams, but in general you should encourage them to solve problems themselves without coming to you.
• If you are highly technical yourself you may also choose to play an architect / design assurance role. If not, find someone who can, within the team or elsewhere…..

Also, it’s always worth going and (re)reading the Agile Manifesto, and especially the twelve principles.

That structure will mainly depend on project specifications

Ideally, there should be 3 juniors per senior developer in a team. Consequently, there are 2-3 senior developers per a teach lead.

Thus, only tech leads will report to PM on progress status of the project. Described structure still assumes that for a non-technical issues (vacation, time-off, conflicts, etc.) everyone can have access to PM.

One of the relatively successful software development teams I was a part of went something like this, on a per-project basis:

A Software Development Manager/Senior Developer/Mentor, to whom everyone else reported directly.

• A project manager, who kept schedules, facilitated requirements and acceptance negotiation, and did communications. Everyone dotted-line reported to this person, too.
  A documentation person (who occasionally was also the PM, but only when expertise permitted).
• A mix of 1-3 developers or senior developers, depending on the project’s needs.
• A junior developer when available.
• Someone assigned from a QA pool.
• An infrastructure person (a role often fulfilled by the manager, since he had solid SA competency as well).

It worked perfectly fine, and I loved that organization. On the other hand, I was the Software Development Manager, and the team’s organization structure was evolving.

Consider following the Functional Staff Organization pattern. This would speak towards your second option of splitting the team by software product.

To quote the article in your context:

The greatest strength of a functional organization is that it ties social structures to delivery of business value. In my view software projects succeed as much as they improve the effectiveness of the activity they support – yielding business value. By organizing your teams the same way, you have a team oriented around satisfying their business users.

The actual management/HR structure is irrelevant beyond that.

Is there a standard way of solving this problem which I am missing?

Not really. It will depend on your team, you, what you need to get done, and what resources the company will make available to you.

Personally, the best sort of switch is by splitting the technical management from the administrative management. It’s rare that people are good at both, and they rarely tend to interact.

One person handles the technical aspects. What needs to be done, who is going to do it, how things need to line up. The other handles administrative aspects. Reviews, budget meetings, product planning, etc. They then work together to communicate insights from one side to the other and to provide a united front.

How this is broken up can go a few different ways. The most common is to have the engineering manager be the administrative side and an achitect be the technical side. They are peers and report to a director/VP.

Another I’ve seen work is to have the engineering manager be the administrative person, and then the team lead(s) act as the technical person. This is trickier, and requires the right people to act as (mostly) peers even if the reporting is hierarchial.

For your specific scenario, I would recommend having 2-3 teams and have technical leads do the technical aspects and you focus on the administrative. Yes, it cuts time from the leads actually writing code, but they should (if they’re doing a good job) recoup that time by making the more junior developers more efficient/productive. It provides them more motivation and a sense of accomplishment with the actual promotion too. And most practically, it’s an easier sell to management than opening a new position.