Balancing where complexity lives in B2B tech partner programs : Tesler's Law

I can tell you, tech partnerships and partner programs, by their very nature, are complex

I ran tech partnerships in my last org, (in the Fintech sector no least!) and they have A LOT of moving parts

First, second, third-party integrations, multi-thread attribution certifications, fast-paced acquisition and churn, and constantly changing regulatory processes and procedures to name but a few

So complexity was pretty much unavoidable, but I made sure it wasn't messy

How did I do that?

Using Tesler's Law

This law, sometimes known as the Law of Conservation of Complexity, asserts that any system or application possesses an inherent level of complexity that cannot be reduced

Instead, we made sure this complexity was either be handled by the developers (hidden behind the interface) or transferred to the user (via interaction)

When applying Tesler's Law to B2B partnership programs (especially those that often involve complex product offerings, integrations, and long-term relationships) this principle becomes crucial to understanding and effectively operating within these kind of systems

Here's how we leveraged the law to our advantage

1?? WE IDENTIFIED & DISTRIBUTED COMPLEXITY

Product Development vs. Partner Experience - First, we determined which complexities our development team could handle behind the scenes VS those that had to remain visible to partners

In a B2B partnership program, you must make decisions about what complexities need to be streamlined in the backend to make the partner's experience smoother and more intuitive

?? Use case - our program involved complex data-sharing processes between systems, so we had to decide whether we wanted the partnership program to handle data normalisation and integration (making it easier for partners to use) OR to leave the technical integration to the partner (requiring them to allocate resources)

2?? WE DESIGNED FOR FLEXIBILITY WITHOUT OVERBURDENING THE USER

Since complexity can’t be entirely removed, we focused on designing the user interface and partner engagement process that anticipated where complexities might arise

We developed tools, resources, and frameworks that guided our partners through the necessary steps without overwhelming them

?? Use case - our partner program involved complex contract negotiations and/or multi-level agreements, so we offered simplified contract templates and/or step-by-step wizards to assist partners while still ensuring flexibility for customised deals

3?? WE AUTOMATED ROUTINE COMPLEXITIES

We automated repetitive tasks that were prone to error or required significant cognitive load

Complexity often arises from handling repetitive and manual tasks, such as updating contracts, reporting, compliance checks, or performance tracking

?? Use case - we automated regular data sharing, such as integrating CRM systems, rather than leaving partners responsible for frequent data uploads

4?? WE PROVIDED TAILORED TRAINING & SUPPORT TO MANAGE COMPLEXITY

It became necessary to offload a certain amount of complexities onto our partner, so we provided robust training, support, and documentation to support the processes - i.e. we made it easy for them to navigate these aspects of the partnership without feeling burdened

?? Use case - we created onboarding materials, detailed API documentation, and support structures to help our partners deal with the technical aspects of integrating our systems with theirs

5?? WE OFFERED MODULAR PROGRAM DESIGN

We offered modularity in the partnership program, where partners could pick and choose the elements of the program they needed, based on their own capabilities and resources

This allowed them to manage complexity at their own pace, and according to their needs

?? Use case - we allowed our partners to choose the level of integration they wanted (basic referral programs, co-marketing partnerships, or deep product integrations) instead of forcing them into an all-in-one model

This really helped with our overall PX, buy-in, sustainability, effectiveness, trust and advocacy

6?? WE PROVIDED SIMPLIFIED DATA & REPORTING

We simplified our insights

We understood that our partners had to make sense of complex data sets to evaluate performance, ROI, and customer interaction - again, it was unavoidable

We therefore provided simplified & bespoke dashboards and visualisations that condensed critical data insights, allowing them to grasp outcomes without dealing with data complexity themselves

?? Use case - instead of providing raw customer usage data, we offered predictive insights or KPI dashboards that summarised key performance metrics, highlighting trends and actions our partners needed to take

Making this data actionable made all the difference

7?? WE CREATED CONTINUOUS FEEDBACK LOOPS

Because of the vertical we were in, the complexity of our partnerships evolved almost on a daily basis. So it was vital we created feedback loops where our partners could continuously provide input on where they encountered difficulties

This helped us evolve our program in a way that continually reduced complexity at their end over time

?? Use case - on occasions, we discovered our partners were finding a certain API too difficult to integrate, so we adapted our development to focus on improving the process, or subsequently offered pre-built integrations from the off

CONCLUSION

Complexity in tech partnerships must be handled somewhere; it's quite simply unavoidable

Whether you choose to run it on the backend by developers, or in the user’s experience, the key is to strategically decide where this complexity should live

And this should be based on x 3 primary factors -

?? the technical capacity of your partners

?? your resources to handle it on the backend

?? the value exchange between you and the partner

By approaching tech partnerships from this angle, we maximised the user experience for our partners

We didn't eliminate the complexity itself, because we couldn't, but by simply redistributing it in a way that ensured a seamless and productive program, we minimised our maximum risk of complexity overload