When it comes to creating software for your business, one of the earliest decisions to make is who’s going to do the work. Deciding to develop in-house or outsource the development is a big decision and you’ll find yourself weighing up the pros and cons of many elements – cost effectiveness, time and resource commitments, skills and experience, project complexity and much more. More often than not in-house v’s outsourced are the only two options you’d consider, but let me take you through a third option…
The hybrid team. Consider it for a minute…
Mix the two options together; like a development team martini!
Form a team that has both your own developers and an external development team who work together to deliver your project. Get the benefits of both and eliminate any downsides (I promise I’ve not been drinking martinis).
So what’s the reality of it?
No-one knows your business more than you; how you operate, how your end users work with a system, what drives your business, what’s important, what legal compliances must be met, whose opinions on what count…
With a fully outsourced team, you need to invest serious time to ensure they really understand the project as much as possible and have a genuine interest in getting to know your business.
Having a hybrid team means that you can combine the solid insight of your own team with the fresh perspectives of the external team – helping uncover new efficiencies in your working practices along the way.
Technology and architecture decisions
Internal teams often support existing systems for a large percentage of their working week. Opportunities to create new solutions don’t come along often. The likelihood that they’ve explored the range of available technologies and know the benefits and drawbacks in a working use capacity is even less likely.
Partnering with an external team who regularly works to create new systems across a range of technologies means that you can benefit from their experience. They’ll ask about your needs and requirements and draw upon their team’s experience to bring the best option to the table.
Remember, the newest technologies aren’t always the best option. You want a solution that will stand the test of time; if it’s the latest shiniest technology then you can’t guarantee that it’ll become mainstream and last a long time.
Source code rights
Having the source code written by your team gives you unequivocable rights to use and license the system that’s created.
Now software rights are a complex thing, and there are people that make a grand living out of software IP rights. It’s complicated and you don’t have to know much about it if your own team is writing the software. Word to the wise, make sure that your employment contracts state that the code written by your team does indeed belong to your business.
A hybrid approach will allow you to reuse, amend and have a license to the software that is written on your behalf, which fundamentally means that it’s yours.
It’s not black and white, you can work with external software houses and still maintain ownership. Just make sure you ask the questions upfront in your engagement to make sure that you’re covered.
Long term maintenance
Developed internally – you and your team created the application and therefore support it.
Developed externally – you outsourced the creation of the solution to another team and therefore they do any changes in the future.
It doesn’t have to be one or the other though; it can be the best of both.
If you work together with your chosen software house, then they can support your new system or act as an escalation. They know the technologies; they know the architecture and they’re familiar with the code base. If the intention is that your software development team will support or extend the system later, the best way is for them to be part of that delivery. And your hybrid team can stay around for some reassurance and escalation; you’ll never be in that high-risk position where the people that wrote your solution retire/leave (*delete as applies to your painful memories) and leave you having to manage the fallout.
If you develop internally, then you need to use your existing team or start hiring. Hiring comes with risk; you can’t guarantee that the new team members will be successful and once your project is finished you could find yourself with too much resource capacity.
When you out-source a project, you get a whole new team that will disband after the project completes. Hybrid project teams are a good mix of getting the team members that you need for your project and not having the full-time commitment of new people in the business. You can gear your hybrid team to bring skills that you need to have a fully rounded group; whether that’s code delivery, mentoring, or technical leadership.
Hybrid for the win!
Let’s be honest now. There are some great advantages to be had through a hybrid approach.
Some final pointers to ensure your hybrid team is set up for success – define working practices upfront, outline how the team will communicate, agree who makes final architectural decisions and last but definitely not least, foster a team culture of openness and honesty.
We’ve done this a lot of times at Waterstons and if I’m honest they’re some of the projects that both us and our clients have enjoyed the most. We generally spend a lot of time getting to know our clients’ businesses as it’s as important to us as it is to them. Our team are really inquisitive, want to learn new things all the time, and as consultants, we’re there to challenge and push you out of your comfort zone and explore new things (but to be honest I think they’re just a bit nosey!).
We find our clients love the option of using us as an escalation point for their team if they need follow-up support post project.
I’m really passionate about it as a way of working, so if you’ve got a hybrid software project and/or have some thoughts on it too then I’d love to hear from you and we can talk things through over a coffee (read: martini).