Your development team has the people, skills, and expertise, but scaling operations is always a challenge when you land a new project or require very specific platform experience. Should you use contractors or outsourced web development teams? This post will look at the options your development team has to manage growth.
Contractors vs Outsourced Development Teams vs Embedded Teams
Even when you think you have the right development team in place, your company will always be on the lookout for highly sought-after platform expertise. All organizations will ask the question:
Should we hire more staff to deal with our current and/or upcoming projects or would another approach be better?
Making the right decision is not always the most practical one, since a variety of factors can be at play. Do these questions above sound familiar?
- Is this just a temporary surge meaning things will eventually return to normal?
- What if the next project requires different skills than your staff’s current ones?
- Will you be able to cover the cost of additional team members in case you face a shortage of projects in the future, or will you have to let people go?
- How can you support existing projects and take on new ones at the same time without continuously investing in new people (and infrastructure)?
You “rent” a developer (or two, or three) from a company that provides them with a specific amount of time and money, and have them work on one or more projects, or support existing projects.
You manage them for the time they “belong” to you, and get them to do any work you may need. It’s a way of artificially growing your team for short periods of time without having to hire.
Again, you’ll have to do a bit of HR there - the fact that another company suggested a specific person does not mean that it’s definitely the right person for the job. Interviews will have to be performed, and the new developer will have to adapt to what you have to give them very quickly - which is not always the case.
Finally, let’s say everything goes well and the job is done. The developer leaves, and the same person might not be available when you need them again, meaning that you’ll have to go through the whole process again.
#2 Outsourced Development Teams
Outsourcing generally means that you go through a process of finding a reliable company and assign them a project, expecting to get results in a well-defined time frame, with a well-defined scope and specifications.
This works best when you take on a project for which your in-house team has no significant expertise or experience, but you still want to be involved without investing in hiring and/or training people.
- You’ll have to vet the people or the company you will be working with, something that takes time and probably money - or you’ll just have to take a big risk.
- You’ll also have to have a fixed scope and perfect specifications, and probably assign a project manager on your side to watch and guide the other party in every step of the way.
- Things can go south easily due to bad communication or poorly written specs, and there are thousands of cases where this has happened.
And we’re not talking about agile approaches at all here - just forget it, unless you have worked with the same people time and time again.
#3 Embedded Development Team
This is a more hybrid approach, in the sense that you don’t get a single developer but rather a group of people who know each other and have experience working together.
Those people are then “embedded” into your current in-house team, following your procedures and methodologies, and eventually increasing your overall productivity.
As before, you’ll be introducing a “foreign body” into your company and you’ll want it to be integrated with your existing staff right away - and we know, at least from modern medicine, that an organism - such as your company - takes time to integrate foreign bodies, and sometimes it fails.
Eventually, it may work better than the alternatives above, but you’ll need to invest a significant amount of effort on this.
Our suggestion: Development Team As-A-Service
(Or, as others call it, SDaaS - Software Development as a Service)
This is an even more hybrid approach than the embedded development team, and (in our opinion) the most cost-effective and brings the best results.
In a nutshell, you get an embedded development team as previously, but this time you don’t have to really care about the size of the team nor about their skills as individuals - the team will initially have a representative, usually one of the developers, who will be responsible for “connecting” your in-house developers (if you have any) with it, doing all communications and bringing their colleagues up to speed.
You assign work to that team and you pay for the hours they spend working.
This means that, for an urgent task or project, several members of the team-as-a-service would have to be involved in order to complete the work as soon as possible, or that they could split less urgent tasks between them and have one person do each. But this is something that the team itself takes care of.
In either case, you get the same scalability as you would get with the cloud when running a web server - it’s there when you need it, and you don’t have to pay for it when you don’t.
In the long run, as the remote team becomes more and more familiar with your in-house team members, their own expertise, your processes, and your way of working, communications can widen and all developers can participate.
The need for an intermediary is usually gone by then, and you end up having a scalable team, much like an embedded one, that you can manage and use as you need depending on your current workload.
Contrary to utilizing cloud services in an IT environment, this is a more gradual process that needs trust to be established on both sides.
In most cases, the other company will handle the integration process, and you’ll just have to just make life easier for them by providing access and information where needed. Sometimes this may take longer than expected, especially if you’re not used to this way of working. But that’s all there is to it.
He has extensive experience as a developer, development team lead, and CTO, at various companies. Earlier in his career, he also worked with other content management systems based on Microsoft's stack, such as DNN, as well as with document management systems like Spescom eB, and done way more SQL Server querying than he should have (including BI stuff).
Sotiris and his team have participated in numerous Umbraco CMS projects of various sizes, from versions 4 to 10, either directly or via agencies. He likes to point out that DotSee invests significant time in learning how their clients think and work and either adapts to them or, in case they need guidance, brings their own organizational methodology and consults them on it.