New Technology Implementation

Background

Deploying data services and managing flows of information across companies is a complex and costly process that has been the downfall of many hyper-growth startups.

This is particularly true of advanced products such as NLP/LLMs and other AI technologies – things that rely heavily on complex data to function effectively.

Spiraling implementation costs as software companies scale have a negative impact on SaaS margins. Teams of internal engineers, consultants, and contractors spend hours implementing increasingly complex technologies with a perpetually growing body of clients.

Shared Responsibility

When a company onboards a new vendor, there’s a process that occurs to join the information systems of the two companies. Companies build and share APIs – endpoints (like plugs and sockets) that allow their internal systems to connect securely and pass information across nodes to and from their partners’ systems.

If you’ve ever used Google, Salesforce, or Shopify, you’ve worked with a vendor who makes their data available via an API.

With companies that size, you as the customer are generally expected to do the work to connect your systems to their API. In this sense their model is self-serve – meaning the responsibility lies with the customer, not the vendor, to spend time and energy building and maintaining this connection.

This is not the standard in cases where companies are contracting startups with advanced platform technologies –

For example: NLP/LLM products often need client data as an input to make decisions or offer recommendations.

Someone needs to do the work of pulling this data from the client and piping it into the company’s product. In many cases that responsibility lies with the vendor, not the customer – and that process can get very complicated and expensive.

A telltale sign of companies facing this challenge can be found with a quick visit to their careers page. We typically see startups with complex technology products hiring for roles like “implementation engineer”. This is a clear indicator that the company is being forced to sink time and money into getting their software to play nice with their customers’ data stacks.

On the other end, customers of these technologies often engage SaaS-specific admins (i.e. SFDC or Hubspot admins for sales teams), sinking money into hiring FTEs to serve as POCs and internal managers of these softwares at a price incremental to the cost of subscription.

Either way, money and time being spent on implementation is money and time not spent on improving the product and moving the company forward.

Implementation teams are a cost-center – a cost required to deliver on the promise of the contract – they are not a driver of growth. Any startup whose implementation costs are increasing at a faster rate than their revenue growth will be doomed when those two curves cross.

How do we treat cost centers?

If we’re smart business owners and managers, we aim to minimise the impact our cost centers have on our revenues. As a company, the easiest way to do this is to force the other party in the contract to do the work.

The pecking order for implementation responsibility seems to follow a basic “my company is bigger than your company” principle, which means that the smaller company is always expected to shoulder the cost of whatever implementation work is necessary to get the service up and running.

In cases like the aforementioned Google, where the larger company is the provider the customers are forced to use their technologists, or hire contractors to do this work. In cases where the provider is smaller than the customer, they are expected to provide the implementation services.

In cases where the size disparity is significant, smaller startups are forced to provide white glove service to large and demanding clients, spending whatever is necessary to keep this “strategically significant” client happy.

The degree of disparity between the two companies will determine whether the increase in costs will be nominal or insupportable, and ultimately whether the startup loses money on the client. It is tremendously risky for a small startup to take on a huge client, but also often is seen as a necessary step to drive growth.

It is similarly risky for larger clients to favor working with smaller vendors. Often, their technology is relatively new, unpolished and untested and therefore actually requires a high level of service to implement and maintain. In this way, there is an inherent risk of using a small vendor.

How do I limit my technology implementation costs?

The primary way startups limit implementation costs is by leveraging a partnerships strategy. The data product industry is actually great at this – a quick visit to Snowflake’s website and you’ll find their “partner network” page easily under the “Solutions” tab of the banner across their site.

By building a partner network, companies can design a model that offsets their primary cost center to a third party – a network of trusted partners (contractors) that have been vetted for legitimacy by the company, understand their technology, and can be hired by the client for any implementation work necessary.

This doesn’t solve the problem of implementation cost, but it displaces the cost back onto the customer rather than the vendor. Furthermore – customers may not want to grant 3rd parties access to their information systems, much less pay for them to do so.

As a customer, if you’re expected to shoulder the cost of implementation you need to make sure whoever is doing the work will do so quickly and efficiently, thereby minimizing cost and maximizing time to value.

Why it is so hard to come up with a solution

The problem is one of perspective: specifically, that we think of implementation as a zero sum game:

“Someone has to shoulder the cost so that I don’t have to.”

If I’m a huge company – serving all of these clients at scale is an untenable task. If I’m a small startup, putting all my resources into implementation for one big client might mean I’m not around next year.

In these cases, I need the other party to shoulder the burden absolutely.

We like to put things in absolute terms because they’re easier to understand, and therefore easier to quantify. But complex problems defy this categorization (by being so complicated that reducing them to a binary expression actually changes them so much that they become meaningless).

It goes without saying that if the goal of software implementation were for the other person on the contract to shoulder the costs and troubles rather than you, then the zero sum model would work great. We wouldn’t need this article and I wouldn’t be standing on this cardboard box, screaming into the void, disguised as a Linkedin Feed.

The difference between the expectation and reality in the example above is where the greatest risk to both parties, and to the contract’s success can be found. No one wants to end up spending more on something they expected their vendor/customer to pay for.

The solution is always collaboration

Unfortunately for all of us, the goal is for your software purchase to actually work. And this model is terrible at incentivizing the involved parties to do a good job implementing the software they just bought/sold.

Incentivising collaboration involves building and certifying trust in each involved party. This requires the customer and the vendor meeting each other in good faith across the table and equitably dividing costs and responsibilities in the way that makes the most sense.

For the very largest software providers like Google or Microsoft, this may look like offering extensive documentation on their software and all its features – running classes and seminars teaching and certifying professionals to use and teach others to use their softwares.

But for most of us, this involves a frank conversation about our firms’ priorities and capabilities and a contractual negotiation that ends with an equitable and documented division of work among the involved parties.

A simple model for mutual compensation

I’ll start this section with the caveat that I’m obviously a biased observer – as a contractor my belief is that we are well-positioned to act as intermediaries between the groups that can minimize costs for both parties.

In this section I will make a pitch for hiring contractors to solve this problem – I’ll try to make it not sales-y but I figured I’d warn you in advance so it doesn’t feel like you read this article only to stumble into the middle of a car commercial.

Now that we understand that the greatest implementation risk is the difference between expectation and reality, we need to find ways to de-risk our implementation plan.

Whether you choose to work with a third party or not, the best model for implementation relies on shared benefit – meaning that the work should be aligned in a manner that reasonably fits the resources and capabilities of the parties. Let’s examine this using a literal example:

Smaller Startup / Bigger Customer

The smaller startup takes on contractor A as a partner in their partner network. They then sign a client that has a need for implementation support and propose the contractor as the implementation team.

In this case we are assuming the goal of the startup is to offset implementation costs in the form of hours worked by passing them off to a third party.

In this case we are assuming the goal of the customer is to maximise time-to-value and limit costs that come from complexities and delays.

In both cases we assume the primary goal is to achieve a positive outcome – meaning the product delivers value to the customer as intended and the contract renews.

Requirements for a Successful Contractor Partnership

If we are to successfully pass this responsibility off to contractors as the provider we need:

• Confidence that the product will work.
• Confidence that implementation costs will be offset.

If we are to successfully pass this responsibility off to contractors as the customer we need:

• Confidence that the product will work.
• Confidence that the installation process will be limited in time and monetary cost.

For contractors to succeed, they must have:

• Knowledge of the product.
• Knowledge of data engineering to work with the vendor’s stack.
• Trust from both parties that they will deliver on the work promised by the contract.
• Effective communication and collaboration across all three parties.

Why Hiring Contractors Works on a Fundamental Level

In a zero sum game, the easiest way to break the system is to offer an out – meaning a third option that both parties can choose that maximizes their upside while limiting their downside. Contractors are this out. Both companies pass off responsibility of implementation on a party whose primary incentive is to provide fast and high-quality service.

The promise for the vendor is offset costs. The promise for the customer is bespoke service that maximizes time-to-value.

However, this promise is fickle: the risk when hiring contractors is that they fail to deliver – so buyers must be discerning when considering working with a 3rd party contractor.

For vendors with complex software products: if the product is constantly under development and changing very quickly (as is often the case with tech startups), it is key to set up a robust set of standards and workflows around communicating those changes to your partner network.

How to spot a decent contractor: A Decision-maker’s guide

At minimum, implementation contractors that are a fit need to have spent time being trained in the proprietary technology of the provider. Software providers generally make this promise by offering providers from their own partner network–the assumption implicit in these networks is that the participants are subject-matter experts in the technology in question.

In the case of more complex products, it is also necessary for providers to exhibit mastery of data engineering systems, specifically demonstrating a track record of working with and developing APIs, data pipelines, and database models. They should be capable of writing custom scripts and/or working with technologies that transform data into a usable format. The more complex and/or unique the customer’s data stack, the more discerning you need to be when selecting a contractor.

Trust from both parties–For the provider, this comes in the form of a successful implementation track record. For the customer, one of the key details many prospective providers fail to require of their contractors are security and compliance certifications such as SOC2, ISO 20071, and/or GDPR. Contractors should also be willing to sign an NDA. Especially when working with large companies, these certifications and their accompanying policies will go a long way to ensuring that trust is protected between all 3 parties.

By ensuring any contractor you hire has these qualifications, you limit your downside and maximize the probability of a positive outcome. Some of the biggest consulting firms in the world have mastered the process of building confidence in their work: This is why people pay firms like Deloitte and McKinsey millions of dollars a year–they are the “out” in many very large zero-sum games.

Placing the Contractors in the Right Spot

This step is absolutely key to ensuring proper implementation: you as the customer have to grant the contractors (or your vendor’s implementation team) access to your data stack – not just read access, but write access.

It is easy to think that implementation is about setting up new assets in the software platform you just bought access to, but it’s really about transforming your existing infrastructure to feed your new software purchase. Implementation engineers often spend more time modeling data for ingestion than actually ingesting it and spinning up new data assets.

Partner contractors are a good solution here because they’ve normally been trained by the vendor – which means they know the exact transformations needed to get the product up and running quickly. The only challenge limiting them from delivering quickly is access and permissions.

As a big company it can be a hard sell to let third party contractors into your stack, but lacking this access is the biggest barrier to a quick and efficient implementation of a vendor tooling solution.

By granting contractors access to its internal systems, the customer can ensure that all transformations can be done in-house without unnecessary exposure of data to external third-party systems. They can create an internal account for the contractors from which they can centrally manage all security concerns and access permissions.

As the buyer, ensuring that the contractor meets the criteria listed above before employing them is key to de-risking the actual access and implementation process. After that, as long as they have data security certifications, have signed an NDA, and have business insurance, it should be much easier to grant that access.

Splitting the Costs

The example above assumes that the customer would shoulder the financial burden of implementation with the caveat that the level of service would limit downside in the short term and therefore offset short-term costs with long-term gains.

However, in cases where this assumption is not clear, it is also possible for the provider and customer to negotiate costs associated with implementation in the form of discounts, kickbacks, referral bonuses, etc.

When vetting a provider, be sure to ask about the details of their partnership model to determine whether there are opportunities to get a discounted rate on professional services or on subscriptions in your contract. A good provider will have an incentives plan that benefits you by limiting costs while still allowing them to offset the full cost of implementation on a 3rd party contractor. These details can and should be negotiated and re-negotiated in your contract at each renewal cycle.

That’s it for this article!

Join us next week for more data-related content. For questions and inquiries, please visit our contact form.