Of course, the first question for anyone looking at this is – what is the difference? Let’s start by saying that we’re not speaking specifically about “product engineering” – although it plays a part in this discussion. We’re actually looking at software development teams broadly, how they work and what they can (and can’t) do for your development efforts.

Today’s IT environments can be complicated beasts – with unique mixes of internal and remote API’s, web services, service-based components, virtualized infrastructure, and various open source, proprietary and custom applications. Orchestrating this architecture to provide the internal and external business services for an organization is an increasingly critical operational concern. Depending on the size and complexity of the environment, it is likely to be managed by one or more skilled engineers who are focused on the security, standardization, automation, scalability, availability and reliability of IT systems.

Traditionally, software development teams have been separated from this complexity to some degree by internal standards for application architecture and operation developed by IT. But, as the maturity of IT environments has progressed and agile has become the standard of the tech industry, software development teams are gradually being integrated into combined engineering and engineering teams under DevOps implementations. At this point, there are many different levels of integration between IT engineering and software development teams and if you are considering outsourcing a project – knowing what you are asking for is an important part of your research and decision process.

So, let’s set up a scenario: You are about to embark on a custom software development project. For the sake of this discussion, let’s assume the application to be developed is strategic and tied to your business model. With so many applications and systems available on the market, if it wasn’t – you would probably just adapt an off-the-shelf application for your purpose. You have a charter and description of the business problems your custom application needs to address, a general budget and executive support. The decision has been made to outsource this project rather than do it in-house.

With that in mind, let’s insert some different conditions that could make a significant difference in your needs for an outsourced team:

1. New, but fully-backed venture with basic organizational structure but with no IT engineering beyond office systems automation and help desk.
2. Existing IT team with legacy experience but little experience with modern infrastructure or IT operation patterns. No dedicated development team or significant custom applications.
3. Traditional operations, IT and software development but siloed – not integrated other than by operational standards.
4. An enterprise-level organization with a fully-integrated IT operations and development team in a DevOps style implementation with a significant portfolio of custom applications that are under continuous development and/or maintenance.
5. A new venture of an existing entity that is expected to operate as a free-standing organization based to a large extent on the services provided by the new application(s) developed during the project.

There are other complexities we could imagine, but for the most part, they can be addressed as variations of these five scenarios and the basic conditions we set up for this discussion.

1. The New, Mostly Naked, Venture

As a new and growing company, there is always (or there should be) pressure to be efficient and do things right from the beginning. If you have a technical leader in your team and/or a significant part of your operation is based on leveraging software applications to provide your services, there is a natural tension – should you focus on your customers, your value proposition and lead your software development at the product level (leaving the actual development to an outsourcing partner), or should you build and control everything in-house? We’ve covered this question before and it is a significant decision – but now, we’re considering a little deeper level of thought. If you are considering an application that will actually support all or a significant part of the services you offer and your revenue – the proper operation and maintenance of that application is a strategic decision.

Your application must be:

1. Planned with a set of operational standards in mind.
2. Scalable, so it can grow along with your business without significant rewrites and basic changes in architecture.
3. Logically broken into maintainable and extensible modules so it can be enhanced and the value of individual services can increase as they find their place in your portfolio.
4. Reliable across upgrades, changing loads, and new features through the full product lifecycle.
5. Economical to operate and maintain based on a solid architecture and the ability to leverage automation across all levels of development, deployment, and maintenance.

If you are a new venture and you want to spend your time focusing on your customer, the value of your services, and managing feature-fit, you shouldn’t expect an outsourced development team to simply take on these issues from day one. They may deliver a wonderful application that provides everything you need, except the five points above. Although your customers will be happy, you have just purchased a load of technical debt. Like any loan, it will come due at some point and the longer you wait to deal with these shortcomings – the more expensive they will be to retire.

So as an entrepreneur with enough problems on your plate, you have a choice (remember – our scenario is that you’re going to outsource this project):

• Dig in and hire a really competent engineering team that has real world experience in larger operations and understands where you are going. It is going to be expensive, time-consuming and at times – frustrating. You will have more expertise sitting around than you need in the early days, but it is an investment you need to make in lieu of the cost of redoing much of your early work when all your predictions come true. You don’t want to have to operate your business while changing the undercarriage as it speeds down the road. Once you have your engineering team and they understand your business model and where you are headed, they can manage your outsourced development team – but with both sides being new to you it is likely to be a fairly inefficient match in the beginning. Expect six to nine months to hire, train, and begin your project and another period of time integrating your outsourced team (which you also have to select) and your in-house engineering to the point where the combined team can be productive.
• Find an outsourcing partner that can provide the engineering skills as a part of the team they provide. If you find the right vendor, the team should be scalable with the resources you need, when you need them. The application should be designed with the five points above in mind from the start. If the vendor operates as a partner with your organization, doing that part of the development and operation successfully is part of their value proposition to you. If the outsourced team has broad experience (as they should) they will bring to the table a range of solutions you may not find otherwise. They have worked in the market and delivered solutions in many different situations. Finding the right vendor will not be as quick as it might be if you were only looking for an outsourced development team (there are many pretenders in the field), but in the end, you should be able to get your project running faster, with better efficiency, lower cost, and risk.

The choice is yours and (of course) there are other factors you may have to consider in your situation – but at a high level, if cost, time-to-market, and lowering distractions from your emerging business are concerning, an outsourced engineering and development team would seem to be a strong option.

2. Existing IT Team, No Internal Software Development Team & Little or No Current Experience with Custom Apps and Modern Infrastructure

At first, this would seem to be a simple match for an outsourced development team – and in some cases it may be. But, the lack of current experience with custom application development and modern infrastructure in this situation should be concerning. Companies in this position tend to be service-based, SMB/E organizations with established client bases, regional strength in their market and a strong, competitive need to grow. As we pointed out at the beginning, we are assuming there is a budget for this project and the company is committed to outsourcing but – they have an existing market and they can’t afford to burn their existing customers while they transition to a new or expanded level of services. Because of that limitation, even without considering the eventual operation and maintenance of the new application once it is released, an organization in this position can’t afford to overburden their existing staff with development of a mission-critical, custom application and the operational planning needed while they continue to serve and maintain their existing services. The staff must be involved in the changes but only to the extent that they need to be to be able to take a role as things move forward.

Again, we come down to some choices:

Hire one or two technical leads/product and project managers who will take the position of planning the new application, its architecture, and operational requirements while managing the outsourced development team. They will need to be much more experienced than the existing IT team so there will be some initial friction and it will (again) take time, be costly and frustrating. It will take time to get them up to speed and integrated into the team before an outsourced development team can be selected and put to work. The reason to use only one or two resources, in this case, is to hold down costs, but doing so will only make each resource more critical and (probably) more expensive.
• Hire outside consultants to develop the operational architecture, requirements and train your internal team. Since the internal team is unlikely to be large or have the skills necessary, there will still be a need to hire additional internal resources, but it can be delayed to some extent. The downside of this strategy is that when experienced staff is added eventually, they may or may not agree with the direction put in place by the consultants and there may be a period of realignment and unexpected technical debt. Also, the use of external consultants to manage all or part of the work done by the outsourced development team can create an “arms length” relationship with the development team that can make it difficult to have the level of collaboration and trust you need to avoid communication problems, especially with agile development.
• Find an outsourcing partner that can provide the engineering talent as a part them team they provide. If you find the right vendor, the team should be scalable with the resources you need, when you need them. If the outsourced team has broad experience (as they should) they will bring to the table a range of solutions you may not find otherwise. They have worked in the market and delivered solutions in many different situations. If you want to transition the outsourced team out at some point, you will still need to hire additional staff for operations and maintenance of your new applications, but you should be able to have them work in parallel with your outsourced team during the transition and lower the burden significantly.

Any of the three options could be successful but if you find the right outsourcing vendor, it would be a faster, less costly and less risky route to get your project going. But, of course, it depends on finding an outsourcing vendor with the option to include engineering skills in their team and to have a flexible approach to providing the team you need.

3. Siloed Operations, IT & Software Development Teams

This scenario lends itself to slightly larger and more technically-based operations than we discussed in the second scenario. This is the type of organization we expect to find in an established ISV with a strong client list in a specific vertical. Their operations are usually as they have been for a decade or more. Their IT staff is established and has a strong operational base. Their software development team is well-versed in their existing applications, the technologies they use and the customer base they work with. If they didn’t have to step out of that box to build this new application, we can easily assume they wouldn’t need to outsource and their engineering is just fine for what they are doing today.

But that is the rub. We’re examining a scenario where they need to extend themselves into new technologies and possibly change their operations significantly. And because we’re assuming their teams are informal, separate silos – we’re also assuming they know about the higher efficiencies they could achieve if they began to shift to a DevOps methodology but – again, like our second scenario, they have existing customers and products/services in the field to maintain and support. Like most companies in this situation, their backlog of feature requests for their existing software is just what they can handle at the moment. Adding another layer of work would just mean something would have to give. An outsourced development team, in this case, makes sense and this organization is likely to have customer-facing product development well-in-hand. But, what they don’t have is a scalable organization to match the importance of the project and a broad understanding of new technologies and architectures they need to consider to streamline their organization.

So, in this case, an outsourcing vendor who can bring in engineering experience as a part of their team skill and experience, a flexible, scalable team makeup and willingness to work in a partner role to help their existing team rethink and realign their operations could be a real asset. It is risky to try to do both at once with the same team, but if both teams have regular work to do and can collaborate to adapt operations over time it can be an opportunity that would be nearly impossible any other way. Again, the critical step is to have the skilled resources available as an integrated part of the team who can lead the effort to plan architecture and operations before development gets underway and you find that serious adjustment is needed. There are risks in this scenario, certainly, but there is also an upside to making changes in parallel with everyone onboard the organizational development and change initiative.

4. Mature Enterprise with Integrated DevOps style IT and Software Development

Again, we’ve moved the situation up the scale a bit but we’re still committed to outsourcing and we’re still considering what type of a team we need. In this case, the internal team has an implementation of DevOps and even if it is not complete, it is moving forward with staff support and commitment. Like scenarios two and three, our existing team has a number of custom applications in production and knows what it is doing when it comes to operations and development. We can assume they are fully engaged and the time allotted to this project is short, or they would simply hire as needed and do the project internally.

Since this organization has a DevOps implementation, there is already an assumption that new development resources will have experience in both development and systems architecture for continuous development and maintenance. Bringing on a team that doesn’t have that type of cross-functional experience and mindset would be a serious problem. They simply wouldn’t be able to hold up their end. In this case, if the project is to be outsourced, the incoming team must be able to handle both engineering and agile software development if they are going to hold up their end and integrate with the larger team successfully.

5. Spin Out/Off Venture with Software-Based Service

You might think this scenario would be a lot like the first, but spin-out ventures tend to be better positioned and planned simply because they usually come from organizations with a strong market position and goals that are carefully evaluated before the venture is started. In most cases, staff members come from the “mother ship” with a background in product development and deep understanding of the market they are going into. But, because the loss of technical resources inside the home organization could seriously impact production there for a prolonged period, they rarely pull out more than a few senior IT resources. With that in mind, their team is usually fully aware of current technologies and methodologies, even when they may come from an organization that culturally has not be able to move to them as quickly as they might wish.

A spin-out gives this core team an opportunity to move in fresh directions with less organizational baggage and legacy overhead. So, in some ways, they may look like scenario two with little IT in the beginning – but the big difference is they have experience in the product development side of custom software and how supporting systems can be orchestrated. They are better positioned to evaluate partners and decide on the roles they want in-house versus outsourced. Since we said at the beginning that all scenarios would be based on a decision to outsource – the question is still, “Do we just need an outsourced software development team or do we also need an integrated engineering component?”

The decision comes down to how much of the burden the mother organization wants to continue to shoulder and how expensive the “charge-backs” would be if they did. Leaders of spin-outs usually have strong stock incentives to keep costs in line and move relatively quickly to prove their direction is worthy of the risk. If using existing services inside their home company would create complications, slow product development, and increase costs – they will think twice about that direction. Since we have specified that they have already decided to outsource this project, we can assume they are not looking to spend any time taking on problems that do not get their services and products into the market. But that said, we know the IT resources in the venture are limited and if they want to go to a modern continuous release methodology so they can incrementally improve and tune their applications, they will need to have flexible, integrated teams of engineers and developers from the beginning so that their applications are architecturally and operationally sound from the beginning.

Bottom Line

The bottom line here is that software development is shifting away from internally-focused product development,  siloed enterprise teams and monolithic applications to incremental release patterns, agile organizations, and customer-focused lean product development. Not everyone is there now. There are many different ways to implement change. But, all of these organizations have chosen to take on custom application development for a strategic initiative, the opportunity now is to do it better with an eye toward the future of their organization. This is just one small part of the change they seek, but it is an important one to consider. So, yes – an outsourced team that brings a range of engineering skills and experience along with their development background can be a big advantage for any of these situations, with a vendor who will operate as a partner in the organization.

Scio provides nearshore, outsourced software development and flexible teams with a range of software development and engineering skills based on our experience in many verticals and situations. Our teams can have flexible roles and their bias is toward agile methodologies broadly. If you have a project in mind, please contact us to discuss how our unique blend of skills and experience can benefit your organization. We would be happy to take the time to listen and provide insight into how we could partner for success.