A clearly defined, efficient software development team structure is absolutely essential if you want to avoid stagnation.

You can hire the most talented developers in the business, invest in top-of-the-market productivity software, and keep on top of all the latest in DevOps and Agile methodology…but all the advantages these offer will be undermined if there’s no clear structure to your team.

If there’s no clear workflow for picking up requests, directing them to the appropriate team, and closing them off, you risk lost time and sluggish deployment – not to mention frayed tempers and inevitable finger-pointing when things tank.

Your software development team doesn’t necessarily need a rigid, hierarchical structure to succeed – but it does need to be clearly defined. In other, simpler words, everyone needs to understand how things work to get things done in the software development process.

That’s what this guide is here to help with. We’ll cover:

• Why software development team structure is important for all types of companies to examine.
• Whether Agile is a viable option for you.
• How to navigate the project/maintenance divide.
• Choosing between generalists and specialists – and knowing when to compromise.

Companies of all sizes need to focus on their team structure

Whether you’ve just hired your first developer or are a multinational success story with whole teams of software engineers behind your product, software development team structure matters.

Here’s why:

For startups

If you’re a startup working towards the launch of your first product, you might be feeling a bit smug at this point.

“We don’t need to worry about that because we’re a team of 10 with two developers, all working together in a single room! We can just shout at each other and everything can be done on the fly.”

And seriously, do feel smug about this. That flexibility and general feeling of togetherness is what makes working for a startup so exciting.

Still, plan ahead. Plenty of startups make plans to hire more as their product takes off, but neglect to figure out how to change the structure of their development function to make the most of these hires. Any company can be agile and fast when the CEO can issue requests to the development team over the top of their computer monitor – it’s keeping this flexibility as you expand that’s the real challenge.

Make plans now and you might be able to keep that flexibility as you expand. Ignore it, and you won’t.

For established companies

If you’re an established company, it’s all too easy to fall back on the ‘we’ve always done it this way’ approach.

Maybe your software development team just sort of…evolved naturally into the structure it has at the moment. Maybe it works fine. The question you’re refusing to ask yourself is ‘could it be better?’

If it’s taken as given that you’ll often miss deadlines, that new starters will take a while to understand key processes, or that the period building up to a release will be unavoidably chaotic, it might be time to make a change. The companies you compete against are only going to get faster and more efficient – you want to be ahead of the curve rather than playing catch-up.

Point one: should we go Agile?

Whilst Agile might not work in 100% of software development teams, it’s got plenty to recommend it – particularly for larger projects.

In a nutshell, an Agile approach to software development involves small specialist teams with no strict structure. The project is managed by the team as a whole, often using a kanban methodology, rather than relying on lots of input from project managers.

There’s a product owner, and a ‘team lead’ for each team involved in development. This helps significantly in keeping things flexible, responding to client or stakeholder demands, and running development and testing tasks concurrently to save time – all major advantages of an Agile approach.

This differs significantly from a traditional (sometimes known as ‘waterfall’) team structure, which divides the development process into individual stages managed by a project manager, each with a separate review phase.

Waterfall can often be simpler to project manage – and if you’re running a relatively small, straightforward project with super-clear requirements, it might be your best bet. On the other hand, it does slow down quite significantly if you scale it up. Because there are fewer opportunities for direct client or stakeholder involvement, you often end up adding unwelcome time (and cost) on at the end of a project to address any points they aren’t happy with.

Agile can take a bit of getting used to. It works best in larger teams consisting of highly self-motivated people. Once embedded, however, you’ll finish larger projects faster and lose a massive chunk of the administrative burden that was preventing you releasing on time, every time previously.

Interested in how these two methodologies compare? We’ve written an in-depth post comparing Agile vs. Waterfall.

Point two: how should we divide maintenance and new features

A poorly-structured software development team will struggle here.

If you have a product out in the big wide world already, it’s a given that you’ll have a stream of day-to-day maintenance tasks related to it – minor bug fixes or optimization points, for example.

If you’re not careful, your development team can get bogged down in solving these issues at the expense of project work, which can feel less immediate given that it’s not going to immediately affect how users see and interact with your product.

The easiest solution is to split your developers into separate teams for keeping on top of maintenance issues and delivering new projects.

Project teams: allow one per major project, with the capacity to take new features from the early development phases into deployment or production. Their duties should be to develop and test new features, respond to client/stakeholder feedback, and iron out any defects along the way. They should not deal with any bug fixes once the feature is live – that’s the maintenance team’s task!

Though there probably will need to be some crossover personnel-wise if you’re running projects concurrently, this will give product managers a set group of developers who are responsible for everything pertaining to a particular new feature or idea.

Maintenance teams: a good maintenance team knows the ins and outs of their product like the back of their collective hand. To maximize their effectiveness, don’t stretch a maintenance team over several different products – allow one per product and no less.

Encourage your maintenance teams to take a proactive approach to their work, rather than waiting for customer service requests to come in. There doesn’t need to be any major planning around each bug fix – simply set up a kanban board which the team can use to identify the most pressing issues, address them, and mark them as complete.

Now…we can all guess which of these sounds more appealing, right? As a developer, of course you’d rather be working on the flashier stuff than spending your days resolving a series of minor issues with little to no wider recognition for your work.

The good news is that this software development team structure is easily adaptable. From your ‘core’ of software developers, rotate who gets picked for project work and who’s on maintenance duty. This will ensure that everyone gets a chance to flex their creative muscles whilst pulling their weight on the ‘boring’ bits and getting to know the intricacies of the product they’re working on.

Point three: generalists, specialists, and finding the right balance

Do you go with larger teams of generalists or smaller, specialized teams with very specific functions?

Broadly, it depends on what you’re creating.

Generalist software development teams have the skills and background knowledge to take a project from development right through to completion. The advantages of this approach are obvious – it facilitates project management and communication, makes everything more traceable, and encourages a strong sense of ownership over the project.

The downsides? If you want to build, integrate, or otherwise involve anything complex, it might be beyond your generalists’ expertise to create on-time and under-budget. Generalist teams work well for projects with clearly defined, fairly basic requirements, but tend to become unstuck when dealing with complicated requirements.

Specialist software development teams involve employees with a deep level of expertise in one particular area working on several different projects at once, only contributing where their chosen area of knowledge is needed. A project developed using a team of specialists might, for example, pull in one of your frontend devs, one of your backend devs, an automation specialist, and a couple of software testers.

Here, you sacrifice that sense of ownership and togetherness – and if you’re not careful, accountability and traceability can take a nosedive too. On the other hand, you have the experience necessary to deal with complex requirements quickly and the flexibility to assemble and reassemble sub-teams whenever needed, rather than maintaining one generalist team 24/7.

Is there a compromise between the two? 

Yes, but don’t assume it’s the best option for the sake of it. Either of the approaches above can work well in the right circumstances. Consider:

• Are our requirements complex enough to warrant a specialist approach?
• Will a team of generalists have enough expertise for our most complex requirements?
• Do we have the budget to sustain several teams of specialists?
• If we don’t budget for specialists now, will we need to hire them out-of-budget if we run into difficulties further down the line?
• Do we have the managerial experience to run a specialist team to its maximum potential?

If you do need elements of both, you can take a hybrid approach to structuring your software development team. This involves sustaining a team of generalists for end-to-end project development, as well as specialist sub-teams which the generalists can call on when needed.

You’ll get both the sense of ownership and the expertise you want, without having to sacrifice one to get the other. Reputationally, hybrid teams do very well…as long as you have both the money and the management resource to run them well.

Your PMs will need to be clued up on managing both horizontal and vertical subteams at the same time – otherwise your hybrid team will end up a confused, disorganized mess which creates more problems than it solves. You’ll also need to consider whether the cost of maintaining both generalists and specialists at the same time is something that’s workable for you.

A few final thoughts

Ultimately, there’s no such thing as ‘the best software development team structure’. There’s only ‘the software development team structure that’s best for your individual circumstances’.

Agile evangelists, for example, will tell you that Agile is absolutely the only way forward and that anything else will make you slow and unresponsive. For larger companies maybe, but are you really going to try and run concurrent developing, testing, and debugging operations when your entire IT/software development team consists of two people?

In the same vein, taking a hybrid approach to software development team structure is all well and good, but if your PMs are under-experienced, or else at capacity already, you don’t have the resources to run it well. One organization’s successful team structure is another’s expensive, disappointing failure.

The most successful software development teams are those with the structure that fits their company’s needs best. It’s all about understanding your requirements and limitations, and doing the best job possible with those in mind. Get in touch with our