That Time Marketing Bought an API

A couple of years ago, I was working in a small product team that had a lot of incoming work from the marketing team. We were not an empowered product team. We did not work in an agile way (even though we tried). Marketing was very fixed in their ways of working and ran most of their campaigns in a waterfall manner. Anyone who has been in this situation would understand the human challenges involved in manifesting change and why it wasn’t as easy as telling the marketing team that they needed to be agile (spoilers, we tried that as well, it didn’t work). Inevitably, it sucked for both sides and it really stemmed from a lack of education on how software is delivered. We wanted to help, but the expectations weren’t realistic. The team was treated like a feature factory and everything came in at the last minute. Stressful.

One day the email marketing department decided to go it alone. They purchased a license with some SaaS to utilize their API by integrating it with our email marketing tool.
This had zero developer input.
No one had vetted the API.
This went as well as you would expect.

Fast forward a few weeks, the team didn’t understand why the API they purchased wasn’t working. To their credit, they did attempt to integrate with the API using the no code tooling the email platform provided, but they had made a fundamental mistake… They never ascertained whether our email marketing tool had the required user information (the users physical address), which was a required field of the API they were using.

At this point, my team was brought in to solve for this before the holidays. We were obviously annoyed, but at the end of the day needed to make this work as the company had already paid for this API. The other challenge was that we were neck deep in other work and wanted to spend as little time as possible on this (we didn’t have enough time as is).

We got a hacky solution up and running by populating the third party email marketing tool with the data exported from one of our services. Our solution sucked, but it allowed us to enjoy the holidays with our friends and families.

The marketing team had not considered many things which would cross the minds of professional software engineers, including:

• Prototyping the API and integration to ensure that the SaaS / API we are integrating with is viable and we know what we may be missing prior to purchasing a license / contract.
• What format does the address data need to be in for the API? Do we store the data in the same way? Do we need to parse and transform it?
• Wait a minute, should our third party email marketing tool even have the users physical address? Do we have to update our GDPR erasure logic to call out and erase this data?
• What happens if a user changes their address? Do we need to sync this update between systems?
• Did this data even need to live in our third party email marketing tool to begin with? Could it have lived internally in one of our platform services?
• What happens if the request to the API fails?
• How will we know a request to the API failed?

This was at a tech company. It showed a deep misunderstanding of systems thinking. It showed a disregard for expertise and learned skills. It showed a need for education in how to deliver software and interact with product teams. If you work at a tech company, and don’t know how to engage with product teams, please try and understand why they work in the ways they do. They are professionals. Follow their lead and their advice.