Why Marketing Teams Need Access to Developer Resources

From my experience as well as from the conversations I had in the marketing community, I’ve found one thing bugging me as a marketing analyst that is spread across almost every company having an in-house marketing team: the lack of (or limited access to) engineering resources.

There is a need for access to developers for marketing purposes: setting up the events in an app or service and forwarding them to third parties; implementing tracking and ad SDKs — all these things need to be done as groundwork to assure proper work and measurement for the marketing department.

Consequences

Lack of sophistication in marketing campaigns

The very first thing that comes to mind is the limited ability to expand the measurement of marketing campaigns. Without access to the developers, marketers are not able to drive campaigns anywhere beyond the standard goals of bringing users to the platform.

Any more sophisticated campaigns require a lot of engineering work in setting up the new events either in the backend or frontend, tracking those with proper parameters, and sending them to the MMPs and ad networks for optimization purposes. Without preparation, no analysis is possible, neither on internal data nor on external platforms.

Outdated setup and the risk of ad fraud

Every SDK and every event that’s been set up and tracked needs to be updated regularly to be up-to-date with the current state of the market (implementation of any legal requirements as well as keeping up with the new challenges of the marketing teams—SKAN, tracking deprecation) and also to bring the security up to the latest level.

Without proper maintenance, you are opening yourself not only to ad fraud but also to the wrong data being delivered from one system to another. Besides this, every outdated system or piece of software is prone to failure and misalignment with other parties.

The consequence of both of them can lead to incorrect or inflated metrics that lead to wrong decisions both strategically and in execution.

Missing recovery capabilities

From time to time, you’ll experience an outage of some of the tools or services you’re using. Whether it’s an ad network, MMP, or anything else, you’ll be hit with data loss. It is a joint venture of the data and engineering departments to get the missing elements back and rerun whatever calculation or aggregation was done in the meantime.

Sometimes the data comes in delayed and just needs to be reprocessed; sometimes it has to be explicitly recovered with serious hacking, and this is where you need the engineers. Usually, such cases require quick actions as the data used for recovery is only available for a short amount of time (either due to the processes of the data provider or GDPR), and established relations with developers can help to speed things up and recover as much as possible within the given time constraints.

Lack of documentation and processes

Devs hate repeated work and love to automate. They also don’t hesitate to share their knowledge. If they know that the incoming inquiry is only a side project and won’t end up in a long-running relationship, the documentation will be sparse, and the processes will end up being rough and applicable only in very particular situations.

Whenever the same or similar request appears, everyone is doomed to repeat the same mistakes again and again. Additionally, picking up where the task was left last time, maintaining the delivered results, or updating the existing setup will be much harder and take more time.

Wrong attribution

This is a nightmare for every marketer, as attribution determines the success or failure of each campaign. An old, unmaintained SDK can send inaccurate or wrong data to the MMP and ad networks; the logic can change over time, and some important events may be omitted in the process or change over time.

Marketing lagging behind the product

Every product or service is constantly evolving. While not every change is a huge one, every single one can make a difference between marketing and product. While some minor discrepancies are negligible, the problems come from overlooking the needs of marketing tracking in product development.

It is highly doubtful that many developers keep marketing tracking in mind when developing the product and a/b testing new features. As a result, the tests reveal a discrepancy in the data between product and marketing. In the worst scenario, the non-tracked variant gets implemented in production, and it stays like this until someone starts digging around the differences.

Reasons

Two worlds

The most common setup is that there is a clear distribution of responsibilities and, as a consequence, resources between the marketing and product teams. The former is responsible for getting the users into the platform or product, while the latter focuses on retaining and monetizing them.

Generally speaking, marketing spends the money the product meticulously generates.

While there is a consensus about interactions between those two worlds, they are happening in a limited way. There is no intrinsic value in the exchange between marketing and product perceived by any side.

This leads to an automatic lock of resources on both sides to work on their own projects only. As a result, we see marketing suffer from a lack of access to developers. And boy, do they need them.

No persisting need and one-offs

Honestly, there are hardly enough requests for the services of engineers coming from marketing to keep engineers on their toes, and they do not like to just sit and wait. Working on product development gives the security of constant engagement and learning.

The projects coming from growth teams are mostly bigger in both scale and impact, at least for the stakeholder (i.e., implementing MMP / CRM tools, setting up event tracking and postbacks to 3rd parties, preparing the whole pipeline from data creation to the dashboard, …) and require both greater amount of resources for a short period of time.

Additionally, those projects are rarely followed up on, leaving the end results untouched for years and slowly decaying. Maintenance is limited to the mitigation of problems and bug fixing, while future-proofing is mostly left out as a low-priority task.

Missing the buy-in

Sometimes the developer resources are treated as “guns for hire”, a service unit that is judged only by the work to be delivered, and as such, they are not being fed all the relevant information, including the big picture and the impact on the company. The ladder is hard to estimate, even for experienced marketers, since there is no proper framework to do it. Basing them on external sources can partially solve it, but it has to be kept in mind that other parties tend to work with modeled (a.k.a. made-up) numbers, especially if those are coming from ad networks.

This leads to a missing commitment. If there is no clear understanding of the value the work will bring, then the efforts needed to achieve the outcome can hardly be estimated.

Solution

The best thing is to keep communication between departments open and honest via dedicated points of contact. Growth teams keep the devs in the loop when setting up MMPs, ad networks, and campaigns, while the dev teams inform growth about planned changes to the product that could potentially affect marketing. In the long run, the processes will be worked out for the amount and specifications of information needed for the exchange.

Sadly, most cases end up with quickly scrambled and even quicker disassembled teams to tackle single problems in a quick and dirty manner. It leads to one-off requests without a deeper understanding of the nature of the problem and overlooks potential follow-ups and maintenance. Once the solution is delivered, everyone goes back to their previous business. There’s no follow-up, and rarely any maintenance. Quick and dirty scrambles are put up before the search for a long-term solution to the problem.