DevMark: The integration of Marketing and Development teams and the sordid tale behind it
I’ll be honest; I come from a fairly “old-fashioned” siloed team format. Regardless of what role I was in or where I worked, this was business-as-usual and nobody questioned it regardless of our roadblocks. I mean, why would anyone who does marketing need to understand the mechanics of the tool that they were trying to bring to market?
I made my marketing plan, I got approval from a client, and I delivered my requests to the creative team which then turned things over to development. There was a built-in mechanism that disconnected marketing from development. It didn’t matter if the devs understood why something was needed, they just spent the next several weeks building it, eventually handing it off with a shrug.
I didn’t truly see the problem with this process at the time because I thought it worked, which really, it didn’t. By the time we reached market, we were already behind.
Why there’s a problem with it
Simple: I never understood anything about what the development team was delivering to me, and they never understood why they were building it. There was no investment on their part in the strategy, and there was none on my part in the infrastructure. It would just magically appear after X weeks and I’d put it in a nice package and deliver it. If the market didn’t like the delivery, we’d chalk it up to experimentation and try something new.
Why it needs to change
A large portion of my marketing initiatives are dependent on a development team deliverable. If they don’t deliver, I have to come up with a back-up plan and push out my initiatives until who knows when. This is endlessly frustrating if I don’t have any insight into where they’re at in the process. They can also view marketing as an annoyance and roadblock to their “real” work.
How we changed it
Daily catch-ups
Every morning at 9am I hop onto a video call with my entire team. We are a distributed team so this is a normal part of our day. In 30 minutes or less, we talk about what we’re working on, what problems we’re facing, and focus on anything that affects another person on the team. We also bring up future items that we deem a priority.
The bonus here is the allowance of each team member to have an opinion in steps we may not normally be included on. I can talk about a bug that needs addressing or a tooltip that I’d like to see.
Transparency in each step
When I’m building a strategy, they’re in on it. I present it to them, get their feedback, and build it back into the plan. They have the option to participate in just about every project I work on. They don’t, because they have a full plate, but it’s about helping them feel like they’re a part of the process. I want to feel this way in regards to theirs, too.
They present to us their roadmap and we go through it in detail through a mind-meld process. This directly effects my plans for the next phase. It’s akin to being at WWDC and getting a first look at what Apple’s launching the next year. (arguably)
Team buy-in
If I can’t get team buy-in, my initiatives are de-prioritized. Why do I need them to be on board? If they aren’t then we’re working against each other. If they disagree or don’t understand something, they’re less likely to participate in anything I may need their help on (which I usually do)
The beauty of transparent planning is it sets you up to make team buy-in easier. In fact, buy-in is inherent to team inclusivity during the planning process. By the time I’m done with my strategy, they’ve basically already seen it and heard about in some way, shape, or form. Roadblocks are avoided because they have a level of investment and integration into the process from soup to nuts.
Showing the dev team how marketing works through analytics and feedback
When I started working at ThoughtWorks, more specifically on Snap CI, I was the first primary marketer for the product. That doesn’t mean we hadn’t done any marketing, it just means that there was little focus on the how and the why, and there was certainly no time for team buy-in.
One of the first agenda items I had was to get them to understand how their traffic looks, what it means, and how it’s affected by things I do. They could see a direct effect on our traffic and signups based on features they launched, tweets we responded to, and articles we wrote.
Help them understand why they’re important to what I do
This was really key for me. I work for a Continuous Delivery product at a company with incredibly smart developers. I can’t write an article explaining how a Canary Release works, or how to Architect for CD. What I can do is understand that it’s a topic people want to know about and one that I can create a strategy around.
I need my team to help me create content. That means taking time away from their feature launches to write. This feels like the equivalent of asking an introvert to give a speech. It’s daunting and unless I have a compelling reason to ask, they’re not going to make time.
Understand the user together (because the user isn’t you)
My dev team and I set up proto-personas* so we can help identify who our user is and who we think should be our user. This is a great reinforcer that we all have the same goal in mind: to bring a valuable product to a valued customer that we can all be proud of.
One other sly thing that helps me immensely are the support tickets. I get them ALL. The first two months of my working here I loathed my full inbox full of support requests. Then one day, I read them. I continue to read them, and our follow up responses to them. Why? Because I see what they want and what they need. If I see the same request coming in time after time from users, I know we have something to address through marketing or a new feature.
Realize that both teams are the priority and plan from there (a.k.a. Initiatives not Teams)
The most common wall we hit is the priority wall. It’s an endless cycle of “we can’t build that if we do that” and “I can’t do that unless you do this”. The development team wants to push hard to get a feature launched while I need their input on any number of things that require their expertise. It’s easy to think that our issue is the most important, but it’s the absolute wrong way to position it.
The fact is: They are all the same level of priority. Marketing, design, development, etc. All the same. Sorry folks.
What this can do is get everyone on a level playing field and discuss openly how to order these items. We do this daily and keep and follow items on a Mingle board.
And remember: the true priority is the end product and user.We’re all in the same boat, rowing toward the same shore..
Work among your dev team
I traveled to our sunny Recife, Brazil, office from San Francisco for two weeks to work with my team. At this point I felt like I knew them well, having seen them every day on video calls. What I didn’t understand was the impact of sitting at a desk with them day to day and getting regular input. It’s clearly not always possible, so we use Slack and other technology to try and get close to it.
Why is this an ongoing sordid tale?
The process of breaking down these silos are challenging. We make up the rules as we go along and we encounter roadblocks along the way. The great news is, I’m learning more than I have in years, and so are they.
We make things up as we go along; institute ways to make things run more smoothly with our communication, and throw them aside when they don’t work. We fail fast, learn quickly, and move forward.
So I use the word sordid very tongue-in-cheek. I’ve actually gained a lot from figuring out how to work more cohesively with my team, and I totally understand there’s further to go.
I’ve learned how to do a “git pull”, why not to do a “git push -f”, how to use a pipeline to deploy, and I now understand what a YML file is.
They’ve learned how to create personas, understand website trends, and create content ideas from their daily experiences. It’s a proverbial win-win.
I’ve figured it all out, but not really
I don’t have a great roadmap to help any team make this work, but I can say without hesitation, that it’s made me far more effective and confident as a product marketer. I can also say that my team feels more connected to and excited about what I’m doing, too. I know this because they ask questions, and engage, and help.
This type of work strategy isn’t limited to the dev; I work intimately with our Product Manager and Content Strategist, along with a multitude of others. They participate on all the items above.
The reason I’m specifically talking about Marketing and Development, is that on a traditional scale, they’re on polar opposites. Not because they should be, but because how they’ve been treated over the years. But they need each other. Kind of like peanut butter and jelly.
So here are some tips
- Have a weekly or daily standup. Ours tends to go on a bit longer than most, but shoot for 5–10 minutes
- Sit with the team at their table
- Sit with a production person
- Make sure you’re at the team retrospectives and participate, even if it feels “off topic” (psst. it’s not)
- Create proto personas if for no other reason than team building
Things to Remember
- Ask questions. You’ll find out that the smallest details are the unique details that might set your marketing/messaging apart
- Make sure they explain/show things to you so they make sense. It’s our job as marketers to distill all the complexities down.
- Ask them if they have any questions about what you’re doing. I don’t really have to do this with my team because they ask a ton of questions, but it took a while for them to warm up to it
Tools we use to help us along the way:
Mingle for project management and roadmapping
Fuze or Skype for daily standups and one-on-ones
Google Docs to share all the things
Slack for almost all team communication
Ideaboardz for weekly team retrospectives
*proto-personas is an informal and un-scientific way to acheive an understanding of who your user is. It’s created by taking a look at what you know about your users and using educated guesses about them. This is in no way meant to take the place of a persona process, but works quite well for not only team-building but product building.
More about Louda
My career has spanned almost two decades, working in the internet industry on both agency and product sides. I started as an analyst and strategist, eventually starting my own marketing agency to help locally-owned and sustainable businesses stay competitive.
As a ThoughtWorker, I run marketing for Snap CI. I’ve been able to make real impact through this role and excited to provide a great place for people to learn about CD with our tools and through best practices.
On a personal note, I ride motorcycles, I race motorcycles, I talk about motorcycles, I wear lots of t-shirts that have motorcycles on them. Oh, and I like coffee.
