My team has grown to be 16+ people, how can I better structure it?

How should you organize your team is too difficult for me to answer without working along side you to see for myself. On how to determine how to organize your team, I think I can provide some insights.

Allowing a team to organize themselves in an organic bottom up approach will allow the team to form more cohesive groups and provide opportunities for the individuals who want to lead, to come forward.

As well, if you have less strict definitions of who does what, it allows individuals to better understand the big picture of what is required and how one's work could affect the next person.

You can provide the list of tasks that need to be done in the coming sprints/weeks and allow the group to collectively assess the efforts for each item then once ready to assign the work out, let them individually volunteer for the work they think suits them best.

16 people is a lot of people to do this method with so maybe not the best suggestion. If that is the case, then I would lean towards maybe having a feature planning session to see who has interest where. Then determine who your 3 - 4 key players and follow their advice on who should focus on what tasks.

I suggest having some sort of feedback loop to determine how well your approach works. Team organization is very subjective matter and there are a million ways to do it. But if you have some type of performance metric (team happiness, bugs found, etc) that you can use for comparison while you find what works, then you can determine what works best when you look back.

Another thing I have found is that team retrospectives do wonders for team cohesion. It gives everyone a chance to have a voice, feel part of the grand machine, and gives you direct feedback on what is truly working.

This is a great question! Structure your team around Services or Value Streams. Analyze where the demand comes from (both external and internal) to make sure you fit for purpose and not for resource utilization. Then there are details like creating a pull system, instead of "assigning" work to people, limiting Work In Progress, etc. ultimately building a predictable delivery system. These concepts are coming from Lean/Kanban systems (Kanban board is just a piece).

I would recommend asking the team. They will have a good idea on what kinds of structure is suitable and by being included in the decision making process will be more likely to buy-in to the chosen approach.

It would also be worth running the proposed structure as an experiment. Work out how you will measure success and review how things have gone after a set time.

You could have the product owner taking care of subgroups assigned semantically by areas of interest within your bigger team. The size of each subgroup could vary according to what makes sense to your scenario. Also, I would try to find a good visual tool to convey the information required for the whole team (statuses, activity queues, pending business definitions, etc) usually this can be achieved with visual panels or Trello Boards (or other tool).

Well, "16 people" is hardly "big," but orgnizationally it seems to me that you might now be the "product owner" of two or more "products."

So – let me treat this for a moment as an "[XY Problem][1]." Although you self-identify "the problem" as "team size," it superficially seems to me that the actual issues relate to such things as your relation to other teams, the nature of the work that you are tasked to do, and so on.

One of the objections that have historically been made to "the Agile model" is that it pre-supposes "a self-directing team" that, within the business in which it actually functions, "can actually be 'self-contained,' 'inwardly-focused,' and therefore 'self-directing.'" It has properly been described as, well, "naïve." "But anyway, here you are." ?‍♂️

Therefore, I suggest that you begin by a review of "the self-perceived problems that you think are now facing you, and/or your teams." There are many ways to re-organize, and you apparently have the power to do so. ("What to do?")

Perhaps the best starting point would be to ... ask your team(s). They see the situation too, albeit not quite from your perspective. Engage them. (And, likewise, definitely(!), "executive stakeholders.") Having identified the problem, you actually have many choices. Solicit input from everyone, and listen carefully. Because, ("good news!"), "this isn't just your decision."

I was on a PMI agile course last week where the instructor recommended that teams should ideally 4 people in size and no more than 8. The reason for this is because the number of communication channels increase with an increase in team size and communication becomes more complex. You would be able to divide team sizes into 4 teams of 4 there you have a nice number of 16. And there should be one scrum master on each team (get the teams to self organise). I'm assuming you are using scrum here.

The term Product Owner is usually associated with Scrum but it sounds like you are not actually taking a Scrum-like approach and the "ideal" role you are describing doesn't sound particularly like a Scrum PO.

Small cross-functional and self-organising teams are usually the best way to deliver a software development project. Between five and ten people per team tends to be optimal and 16 is almost certainly too large if you intend to take an agile approach. I would expect at least two teams in your case with each team being truly cross-functional, not split by role or specialism.

Why not ask the teams how they would prefer to organise. Ask them what project approaches they are already familiar with and what they think would best suit your situation.