I want to know how your current teams are structured in terms of reporting and org chart. If anyone can provide the names of the various roles used in your orgranization, that will be awesome.
I guess I totally messed up with this question. I also wanted to know what would be the ideal setup, kinda like your dream org chart.
At my company, we have an extremely flat management structure. There is no hierarchy whatsoever in our dev team; all the software engineers are at the same "level" and report directly to the VP of Software Development. Occasionally one of us will be tapped to lead a project, but in our company, that just means a different set of responsibilities, not a promotion. This is kind of cool as it has caused our dev team to become a meritocracy.
We also have "Team Lead" positions and "Project Engineer" positions. I'm sure there are other ones that I'm forgetting but I haven't had enough coffee yet this morning.
For the most part, we're setup like this:
Manager <- CMMI Facilitator <- Software Engineer I-IV
Manager <- Systems Engineer
It's a fairly simple setup, but it works well.
[Director] <-> [PM] <-> [Developer, Tester]
[Developer] <-> [Director]
Quite flat.
In the Microsoft Windows and office organizations, product development teams (mostly) consist of people in three roles, program management (PM's), testers and developers.
Of course, developers are responsible for developing. The test team is responsible for developing functional and related tests and infrastructure; and running the tests to find bugs. Very little testing is done by hand - we spend a lot of time automating things. This includes designing things to make them more easily testable.
The program management role is responsible for communication, coordination and planning. This will mean different things to different teams. But they are the glue that holds everything together.
From an org chart perspective, things are very conventional. Most mangers have between 3 and 9 people reporting to them - not too flat, but not too deep. A very flat org tree would not work well at Microsoft (this doesn't mean the are bad, but from a cultural standpoint, having more than 9 direct reports is challenging).
We have:
The owner.
The devs (the owner is technically one of the devs).
No mid-level managers, no titles, no unnecessary formalities.
Works for me.
I work for a small software company; we only have two developers. Before I started writing software, I studied psychology and I got an MBA after that, so I can tell you from extant literature that the average person can manage 2 - 7 things with the optimal being 4- 5. So, your best bet is to get to groups of 5 or fewer. If you have 5 teams, one person can manage all 5 of those teams. If you have 25 teams, one person manages each of those teams and one person manages the 5 managers.
Personally, I will always have two programmers working at the same desk. My lead developer and I work at a very large desk. We face each other and there's no divider. We get along really well and the ease of collaboration makes us very efficient. I'll probably always have as many as 3 - 4 programmers working in the same office at a time. I'll keep them facing each other so you still get privacy and so that making eye contact to ask questions is easy and comfortable.
Also, I won't keep my programmers in a common area. Distractions can be extremely costly for programmers. I like them to have the ability to close their doors and say, "nobody bug me today . . . I'm in the zone!"
Finally, ideally, developers would work on as few projects at a time as possible. Context switches are killer in a development environment. A simple distraction can cost as much as an hours worth of productivity. A context switch can be several hours. Because we're so small, we often work on 5 or 6 projects in the same day. Larger companies dedicate programmers almost exclusively to one project and this cuts back on the efficiency losses due to context switches.
We have an HR reporting relationship that differs from the teams that do the work. We have three Scrum teams that have a couple of product owners, but the people on those teams don't necessarily report to someone on their team. The senior devs (three of us) report to the director of engineering, and the remaining other devs (six) report to two of the senior devs. Meanwhile, the testers and SDETs all report to the senior SDET. So, in terms of HR management, there are three middle managers who report to the director of engineering, along with one senior dev who doesn't have any reports and our architect. Those fifteen or so people are in turn spread across three Scrum teams that don't necessarily align to the org chart. The Scrum teams are responsible for the day-to-day determination of what people should be working on, while the HR reporting relationship is for job performance, any problems people might have, career path stuff, things like that.