Long-Term Strategic Partnerships With Technology Resource Providers
Tags: Technology, Staff Augmentation, Managed Services, Strategic Partnerships, Engineering

1. Desire/Interest

First and foremost the partner must be interested in solving the problems you want to solve for your business. This might seem obvious at first but a great deal of relationships are either weak or break down over time because the partner is not fundamentally interested in the business/product/technology objectives or the path to get there.

To ensure desire and interest alignment with your partner you must first be clear about the objectives of the projects you’d like the partner to engage in. These objectives must be communicated to the partner as early and frequently as possible. Then be clear about the roadmap you intend to follow to get there. You can even build it together.

In the end however you have to make a judgement in terms of whether there is genuine interest there or at least strong potential for alignment of mission.

There is no point in pursuing a strategic partnership with a firm that doesn’t understand your long-term objectives or want to be part of the journey you’re embarking on to achieve them.

2. Mindshare

All partnerships encounter challenging moments at some point or another. This may be breakdowns related to delivery, people, or something else. In these moments it’s vital to have the mindshare of the leadership team of the partner.

After all, you are paying them to solve problems for you. If you can’t get their key executives or managers on the phone in difficult times then the partnership is probably not very important to them.

The ideal metric you’re looking for here is probably “same day return call” or even “same hour return call” depending on the type of project being worked on.

Good leaders at resource providers know they should be a Slack message or phone call away. And that if they make themselves available at critical moments it helps to ensure a smooth running operation between the two orgs.

By the way, if all you’re getting from your partner is a holiday card once a year and they aren’t proactively calling you to check in, that’s likely a sign of a stale relationship.

If they are consistently providing value they should be very interested in telling you about it on a frequent basis.

3. Talent Acquisition & Retention

Your partner should be better than you at talent acquisition & retention.

In fact, this is table-stakes for any resource provider. They are in the talent game and should be experts at it; while you are in a particular industry and talent is just one part of your set of challenges. i.e you’re paying them to worry exclusively about finding and keeping the best people.

A positive indicator in this area is that your partner is proactive about backfilling their open positions. Meaning, when one of their senior developers leaves, you shouldn’t have to contact the partner, they should be reaching out to you instead.

Another positive sign to look for is proof points that developers like working for the partner and stay working for them beyond the typical 3 year attrition window for engineers.

For this you need to do your research before signing the partner. That process should include asking them to list out their talent acquisition & retention strategies, as well as interviewing some of their long-term employees and asking them what makes them stay.

4. Operating Models

Lets define operating model as not just the org chart but all the details and nuances of how Product and Engineering at your company delivers and maintains software.

Many organizations don’t have this clearly defined. Therefore, your first step here might be to describe your current operating model so your partner can align to it.

This can include things like how you practice Agile, how you manage remote teams, your specific SDLC process, the typical composition of your teams, roadmap management, the way you approach technical debt, as well as other key processes.

Keep in mind that every organization including yours has an operating model. You might have arrived at yours organically and therefore never documented it, but it doesn’t change the fact that your partner needs to know what it is in order to work well with you.

5. Negotiating on Cost

If your partner is not one to negotiate on cost what you have is a one-way street which isn’t good for any partnership.

Good partners recognize that both sides must continuously maximize & optimize value in the relationship since dynamics for both the businesses and the labor markets are probably going to continuously change.

Good partners also understand that most organizations are under constant financial and budgetary constraints. Thus the issue of negotating on cost from time to time (I prefer a set periodic review) should not come as a surprise to either party or be viewed negatively.

Negotiating should in fact be a natural and positive dynamic in the relationship so both parties are getting the most out of their investments at any given time.

6. Technical Experience

When establishing a strategic partnership a surprising number of companies confuse technical talent with technical experience. Most organizations are looking for both but often agree to hire partners without testing for the latter.

i.e. you don’t just want a highly skilled construction company to build your home, you want a highly skilled construction company that specializes in building the precise kind of home you want to build. Or at least the key aspects what makes your home unique.

For example, in software projects you don’t just want a vendor who can supply you with NodeJS or Python engineers but a provider who knows the ins and outs of developing an e-commerce shopping cart experience, if that’s your use case.

Many resource providers will be happy to hand you talent which looks good on paper and/or tests really well in the interviews. But it’s the past experience which will really differentiate things and allow you to drive velocity out of the teams.

Also keep in mind that you aren’t paying for the resources to learn on the job. Sure, there will be some leveling up on your stack. But for most software projects (not counting bleeding edge/hyper innovative efforts) the outside team should have done similar work in the past.

7. Domain Expertise

It’s obvious that most companies would like a talented and experienced group of engineering & product resources who have also previously worked in their business or product domains.

And today there are enough resource providers out there that many of them have a considerable amount of experience in industries like FinTech, HealthTech, EdTech, etc.

You must decide exactly how much you care about the partner having pre-existing domain expertise and how valuable that is for the project.

For example, if your projects are mostly infrastructure-focused such as migrating from a Data Center to the Cloud, perhaps domain-specific knowledge is minimally required.

However, if you’re adding a new & complex workflow aligned to a customer or market-specific use case, you might want to partner with a firm that has expertise in your market.

8. KPIs

Generally, people don’t like for their output to be measured very closely and unfortunately this is fairly common for strategic partnerships as well.

Metrics & financials exist of course, but given the chance most organizations (whether clients or partners) would love little to no data-based assessments of their performance while working together.

It appears that applying KPIs to relationships can lead to awkwardness and therefore many leaders on both sides avoid using rigorous data to ensure the relationship is highly functional.

But when it comes to resource providers for long-term & large projects, measurement and KPIs are an absolute must for success. Without good data you will never be able to truly be sure if the partnership is succeeding to its maximum potential. At best you will have an approximation.

A KPI framework is necessary and actually not very difficult to agree upon if both sides understand the true value of it, which is more about continuous improvement than accountability.

You should drive the development of this framework and seek alignment from the partner rather than waiting for them to do it. Ideally of course, this framework is already being used in your organization to manage your existing team.

9. Cultural Fit

This is one of the trickier areas to nail down.

Culture has such a broad & varying definition from company to company that it’s difficult for most organization to define it clearly. But to ensure good partnerships it’s worth going through the exercise.

Here are some examples to look at that fall under the broad umbrella of culture:

Is communication primarily on Slack or does your team prefer face-to-face or Zoom interactions?

Do you celebrate big wins by throwing a party or sending a congratulatory email?

Is there a focus on big meetings or are more intimate and personal 1:1 conversations preferred?

When problems or roadblocks arise during development is there finger-pointing or is a mechanism for blameless analysis in place?

What is the relationship like between Product & Engineering? Is it fraught with tension or highly functional?

The easiest way to solve for cultural fit is to write down your culture.

By documenting your culture you give the partner an opportunity to either align to it, come up with ways to meld the two sides together, or choose not to be a partner.

10. 10% Extra

The best people are always doing at least 10% more than what they’re paid to do and the same holds true with partners.

If you have a partner that acts purely based on the MSA and nothing more, then they’re probably not the right long-term fit for you. You want a partner who is going to go the extra mile, and not just at times of key deliveries but throughout the relationship.

The same holds true for you, the client. There is give and take in any healthy relationship so you’ll have to put in the extra effort as well to ensure a highly functional partnership.

For example, I had a partner recently offer the work of one of their AWS architects for 2 days pro-bono. It meant a lot during a time-constrained period, and ultimately went a long way towards awarding their team a contract for new work.

Doing 10% more might sound small in the grand scheme of things, but it’s the secret sauce of what makes a partnership successful.

However, many organizations on both sides tend to overlook this concept or have a mindset that the other side has to put in the extra work, when in actuality it truly is both parties that must make the commitment to do more.