How to structure a development team

Question

I am the manager of a team of 11 software developers who look after my company's web sites / web applications, running up to 4 concurrent projects plus day-to-day support at any time. Within the 11 developers there is a mixture of technical skills, job titles and experience, although the team structure is flat with all 11 developers reporting directly to me.

The whole team having a single manager is starting to prove not to scale very well. I am starting to be spread too thinly so want to reduce my number of direct reports. All the ways I can think to do this have significant downsides:

• Have junior developers report to senior ones. This reduces the time spent on development by the best technicians.
• Split the team by software product, e.g. developers 1-6 work on intranet and 7-11 work on external sites, with each section having new team lead (possibly a new job description with more management / mentoring / coaching responsibility than the current senior developers). This adds artificial silos and might make it difficult to get an "intranet developer" to work on an external website if I want them to.
• Keep the structure flat and add managerial support in the shape of Project Managers / Team Administrators just to take the pressure off. This doesn't solve the problem as the team can't go on growing like this forever.

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

If not, how have others of you solved this problem?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.