You have 1 article left to read this month before you need to register a free LeadDev.com account.
A marketer walks into a bar and asks for an ill-defined custom integration for the company CRM. They wait two years for the engineering team to prioritize the feature. Everyone is frustrated.
As a marketer who has spent the last five years sitting at the intersection of engineering, product, and marketing, I’ve witnessed what happens when power struggles, misaligned goals, and poor communication throw teams off track.
Marketers often fail to appreciate the complexity of their technical requests and ignore the need to communicate exactly how a particular piece of development work will contribute to achieving organizational goals.
Engineers are occasionally prone to turning down requests for new features or functionality without explanation and can block technical optimizations that would make the marketing department’s life a lot easier.
It doesn’t have to be this way. Throughout my career, I’ve witnessed first-hand how cross-functional marketing teams can collaborate effectively to achieve exceptional results.
The secret is respect, clear communication, and a shared understanding of workflows.
Have a process for deciding responsibilities and outcomes
Early on in my career, I was responsible for editing content on a website which had no CMS. Copy was treated as code, which meant I had to amend live HTML, Markdown, and YAML files without even the safety net of a staging site.
Needless to say, I messed up a lot and created a whole bunch of extra work for the engineering team, who frankly didn’t have time to deal with basic errors. It was undoubtedly frustrating for them and extremely demoralizing for me as I always felt like a burden, despite their kindness and tolerance of my repeated requests for help.
The obvious fix would be to integrate a CMS with preview functionality to ensure I couldn’t touch any code. Easy right?
The challenge was that the website fell into an organizational grey area – neither marketing nor engineering were technically responsible for it, which meant that nobody had ownership of the problem or the solution.
One of the most important lessons I’ve learned from collaborating with engineers, but also across all teams, is to always develop a clear understanding of who owns specific organizational outcomes.
Whether it’s making decisions about technology, processes, or strategic direction, there must be an agreement on how work is divided up and who is responsible for specific tasks or business functions.
That’s not to say other teams can’t have input (they absolutely should), but there must be an agreed process for gathering stakeholder feedback and making decisions. In our case, a lack of process became the process and it was absolutely paralyzing as nobody felt empowered to make any obvious decisions, which would have saved everyone a whole lot of time and headaches.
If you’re building new teams as an organization grows, or joining a team in a leadership role, It’s worth getting this ownership worked out as early as possible, even if it takes a little wrangling, as it’ll save a lot of time and effort in the long run and can bring transparency and clarity to complex projects.
Remove jargon and reduce concepts to basic components
Marketers and engineers alike use a lot of jargon, which is unintelligible to the uninitiated and often even hard for those in the know to unpick clearly.
For example, in marketing, we often talk about CPA, LTV, CPM, and so on. This sort of language isn’t inherently problematic, but when we’re working with people from outside of our bubble, we can forget not everyone speaks our shorthand.
Whether you’re a marketer, engineer, or product manager, we all need to avoid using overly technical language and acronyms when communicating outside of our respective disciplines.
At the core, this is an issue of inclusivity. By using jargon, we’re making it harder for people from outside our team to engage with our work, and ultimately reinforcing the barriers to our industry.
In one of my first jobs, as a marketing assistant, I was sitting in a meeting listening to people talk almost entirely in acronyms, and I didn’t have a clue what they were saying. It was alienating and made me feel like I shouldn’t be there. This is an insight I’ve taken forward into my work as a manager and cross-team collaborator.
Working across teams is not just about collaborating with people with different skill sets. It’s about working with people with different experiences and backgrounds, who may be coming from a completely different industry. Ultimately, while it might feel more efficient in the moment to use technical language or obscure shorthand, a more inclusive and intelligible communication style will lead to more effective collaboration in the long run, and better outcomes for everyone.
Mutually agree on workflows
I once worked in a company where the engineering team was transitioning from a waterfall to an agile delivery process.
I watched as they transformed their release cycle from once every six months to once every six weeks. This success spurred me on to try and run my own marketing team using Agile/Scrum principles.
Alongside helping us ship marketing campaigns faster, our alignment with the engineering team’s workflow had another interesting benefit.
By running our own sprints with clear tasks and deliverables, we found it much easier to package up marketing-led work for the engineering team in a familiar format that could be easily integrated into their workflows.
We employed user stories with clear acceptance criteria to describe individual tasks, following the same templates that the engineering team used to document their own work. We agreed on when we should submit marketing tasks for consideration into the next sprint, and the development team had confidence in our tasks as it had a clear idea of what the finished product might look like.
This dramatically reduced any confusion around scope or deliverables, alongside ensuring that both sides understood their roles and responsibilities.
Always provide context
When you’re asking a member of another team to do something, it’s really useful to give as much context as possible as to why the work is important and how it will add value to your organization or customers.
For example, I’ve been approached about writing a blog post without any context about who it was for, why it should be written, or how it fed into strategic or organizational goals. As you can imagine, the writing process was extremely hard and I felt pretty unmotivated to do the work.
It can be easy to fall into the trap of providing the bare minimum information when you’re busy, but failing to add the all-important context prevents buy-in on the part of the person you’re asking.
This can lead to people becoming disengaged, disinterested, and prone to leaving your task at the bottom of the pile.
Failing to get buy-in is something I’ve seen happen both ways between marketers and engineers, but it’s so easy to avoid. Being as clear as possible about the desired impact and the strategic value of a piece of work will go a long way towards achieving a better working relationship and, frankly, a better result.
Explore solutions together before deciding on fixed implementation
I’m the type of marketer who knows enough about software development to be dangerous, but rarely useful.
This can be a problem when it comes to collaborating. I may have an idea about how to achieve a given technical outcome, but the engineering team can see two steps ahead of me regarding the problems we might face in implementing it.
It’s all too easy to be prescriptive when it comes to asking other teams to action something, but the best results are usually achieved through a collaborative approach, where both sides are able to feed into the solution.
By talking through a problem together, by saying ‘this is our objective, what is the best way of achieving it?’, we can open up a discourse that is much more effective than a unilateral decision made by any one person or team.
While you might need to devote time to this at the beginning, it will undoubtedly save time, energy, and money in the long run Additionally, it will allow staff to better understand how everyone’s job fits together, building a more effective and efficient team, and ultimately a better work culture.
