marketing: your allies in the fight for devops – full text (devops days minneapolis 2016)

Marketing: your new allies in the fight for devops

SARAH GOFF-DUPONT • ATLASSIAN • @DEVTOOLSUPERFAN

FOR DEVOPS

Good morning! I'm Sarah, and the reason I'm up here talking to you can be traced back to a really crappy experience my husband had a few years ago.

“Hi, I’m Sarah.”This is what we’re fighting for.

- So, this is my family: the aforementioned husband and our two kids. And not only is this a shameless attempt to molify the audience with pictures of adorable children, it gets to the heart of why I care about DevOps.

- This crappy experience I mentioned involved the sales team at his company. They landed a huge deal with a huge client. Sounds great, right? Except the things they sold the client on hadn't been built yet – they were in the works, but definitely not ready for release. And the timeline those shiny new features was promised on? Totally out of touch with reality. I mean, as far as anyone could tell, the sales team didn't even ask the development team how long it was projected to take.

- You can probably guess what happened next: mandatory Saturdays.

- Audience poll: how many of you have seen this movie? (And by "seen", I mean "lived"...)

- At the time, our first child was just over a year old and having Sam sequestered away working all Saturday put the hurt on the whole family.

“Hi, I’m Sarah.”This is what we’re fighting for.

- To say that I was pissed off is an understatement – and not just about the logistical pinch I was feeling.

- Here I was, a newly-minted marketer having just come off 8 years in engineering, and super-excited about my new role. And these stupid people at my husband's company were perpetuating every stereotype engineers have about us.

- It was frustrating in just about every way imaginable. And as the show of hands just now proves, this situation is not uncommon.

- I thought "There's got to be a way to avoid this kind of crap." So I started looking for ways to do just that. And that's what we'll be talking about for the next 20 minutes or so.

- But lemme back up a step.

Marketing: your allies in the fight for devops


FOR DEVOPS

MARKETINGENGINEERING

- P. DUBOIS

Again, my name is Sarah and I'm on the marketing team at Atlassian. This is my 4th time attending DevOps Days. I learn so much at these events and I'm honored to be able to give back and share a few things with you.

W h a t I S th e At l a s s i a n v o i c e , a n y w a y ?

Agenda

Vo i c e v s . t o n e

Wo r d s t o c h o o s e ( a n d w o r d s t o l o s e)

At l a s s i a n’s v a l u e s

Minnesota? You betchya!

And I'm especially excited to be here in particular because I'm a Minnesota native – grew up just down the road in Mankato. So I'm stoked to be with my people this time!

One of the reasons I'm so enthusiastic about DevOps is that, despite the fact that I no longer even have Git installed on my laptop, it's such an inclusive community that there's still a place for people in roles like mine.

And that’s the core of what I'm going to talk about today: ways people in technical roles (particularly those on product development teams) can forge closer relationships with the people who market and/or sell those products.

CAMS

Automation

MeasurementCulture

Sharing

As you may have guessed, this is primarily and “culture” and “sharing” talk.

In my experience, and in the experience of other software people I know, engineering and marketing often have a strained relationship. There tends to be sort of a power struggle over whether the company culture is dominated by sales/marketing, or engineering.

Why is that a problem? I mean, what are we even trying to solve for here?

Page title here

• Level One• Level Two• Level Two• Level Two

• Level One

In engineering-led companies, it's not uncommon for the product team to build out a bunch of features and fixes that don't necessarily align with any kind of theme – or at least, not with a theme that you could take to market and turn into some kind of campaign. Let me show you an example of this:

I used to be the product marketer for Bamboo, Atlassian's continuous delivery server. It's an installed behind-your-firewall type product, so it has versioned releases.

There was this one release that was had some great improvements, but was potpouri of stuff that would look totally random to customers. So I saw this and was like "Oh my god, how am I going to craft any kind of story with that?" I was absolutely stumped.

Now, the release happened to be right around Valentine's Day, and several elements in that release were things customers had been asking for, so...

Page title here


• Level One

"Feel the love with Bamboo 4.4".

That is some weak sauce right there, but it's the best I could come up with. Let's just say I didn't exactly nail my renewal and evaluation goals for that release.

On the flip-side, in sales-led companies, it's not uncommon for engineering to get steamrolled.

Maybe what you'd really like to do this quarter is pay down some technical debt before it becomes crippling. Problem is, there are revenue goals to meet. The sales team are in danger of missing their quotas! And they can't sell bug fixes or refactors or faster builds.

So you build some new shiny stuff instead.

Or if you're really unlucky, you're sent on a death march like my husband was.

I don't think it's healthy for a company to be engineering-led or sales-led. I think there's a middle ground where marketing and engineering can come together.

Because we need each other. If one of us is always subservient to the other and doesn't get a chance to shine, we're all out of a job.

So let's look at about 5 or 6 steps we can take towards each other. Everything you'll hear about has been battle-tested and proven worthy by at least one product team at Atlassian – and in many cases I'll be speaking from personal experience.

Note that, because this room is heavily dominated by people in engineering and operations roles, we'll focus on ways technical teams can take some initiative. (And next time I speak to a room full of sales and marketers, I'll encourage them to take the initiative.)

Page title here


• Level OneCo-location

Starting with... agile stuff.

(Is everyone here practicing some flavor of agile?)

I never got the chance to do this becuase when I was a product marketer, my product team was split between two cities, neither of which I lived in.

But! I have seen succeed with many teams at Atlassian is having the product marketers sit amongst the product developers. This is classic agile: co-loacation.

Proximity makes the heart grow fonder.

MarketerMarketerGeneral Manager

Developers

Designer

Here's the Atlassian ecosystem team – they build the Marketplace site when you can find (or sell) add-ons, and work a lot on our add-on platform and APIs.

You can see developers sitting along side marketers, a designer, and the general manager of the ecosystem business.

The Bitbucket team follows this same model – they are fully co-located. Other product teams co-locate to the extent they can, but some are limited by being spread across two offices.

Page title here



There is nothing like physical proximity when it comes to fostering collaboration and empathy. If your product marketers are in the same building as you, or on the same campus, consider inviting them to sit with your team.

Even 2 or 3 days a week makes a big difference. We marketers tend have pretty simple equipment – have laptop, will travel. Far more mobile than most developer workstations I've seen, which frankly look like a cross between NASA's mission control and something from The Matrix.

It's not that sitting together means your project work is suddenly going to overlap a bunch. It just means that you'll become more familiar with the world in which they operate, and vice versa. My marketing teammates who do this say they now have a much better understanding of why it takes longer to turn out fixes or new features than you'd think: they hadn't appreciated the extent to which a seemingly simple change can introduce risk or lead to fundamental questions about how the product is architected or supported.Developers report pretty much the same. They now understand how hard their product marketers work optimizing content for search engines, planning and executing and ANALYZING campaigns. Generally, how not-fluffy modern marketing is. (Spoiler alert: the days of 3 martini lunches are long, long gone.)

Page title here



It’s not that sitting together means your project work is suddenly going to overlap a bunch. It just means that you'll become more familiar with the world in which they operate, and vice versa.

My marketing teammates who do this say they now have a much better understanding of why it takes longer to turn out fixes or new features than you'd think: they hadn't appreciated the extent to which a seemingly simple change can introduce risk or lead to fundamental questions about how the product is architected or supported.

Developers report pretty much the same. They now understand how hard their product marketers work optimizing content for search engines, planning and executing and ANALYZING campaigns. Generally, how not-fluffy modern marketing is. (Spoiler alert: the days of 3 martini lunches are long, long gone.)

Demos

If physical co-location isn't possible, bringing sales and marketing into your sprint demos is another good option. I used this technique with the Bamboo development team for a couple years and it really helped me stay on the pulse.

We had an extra challenge, tho. I couldn't just waltz into the conference room where their demo was held. Nor could I join via video conference. This dev team is split between Sydney, Austrailia and Gdansk, Poland – whose work days just barely overlap during the northern hemisphere's summer, and don't overlap at all during our winter.

And for me in SF, what little overlap there was happened at about 3am for me.

So we found a work-around.

For each sprint demo, we set up a page on our intranet with links to all the user stories and bug fixes being demo'd. The developers in Sydney would meet and run through their demos live, and the team in Gdansk would do the same.

They would also record a screencapture of each demo, post it to a private account on Vimeo, and embed it on the page. Each recording was password-protected, just in case any competitors came poking around.

So between meeting live, and the online component, everyone is able to stay up to date on how the next release is progressing and get to know the features pretty deeply. We also had customer support looped in on this, by the way. Cross-functional collab for the win.

It was great for me as a marketer because when I worked the booth at trade shows and such, I was able to answer people's questions in greater detail.It also helped me refine product messaging. There were a couple instances where I noticed something in the demo that maybe wasn't a marquee feature, but related to a larger marketing story. Like when we added support for automatically scaling up build power using Amazon virtual private clouds – pretty boring on the surface, but it was a huge boon to Bamboo's "CI in the enterprise" story.

It was great for me as a marketer because when I worked the booth at trade shows and such, I was able to answer people's questions in greater detail.

It also helped me refine product messaging.

There were a couple instances where I noticed something in the demo that maybe wasn't a marquee feature, but related to a larger marketing story.

Like when we added support for automatically scaling up build power using Amazon virtual private clouds – pretty boring on the surface, but it was a huge boon to Bamboo's "CI in the enterprise" story.

Roadmapping

Then there's roadmapping. I think every product development and product marketing team at Atlassian has a different way of coordinating on this – with varying levels of sophistication.

When I was doing product marketing for Bamboo, I would have a bi-weekly sync with my product manager and lead developer. We'd talk about the roadmap for the next 6 months or so and all the major pieces of work they were planning. It's the simplest thing in the world, but it was effective for two reasons:

First, I got a jump-start on thinking about how I was going to bring the next 2-3 releases to market. How do the collection of changes comprising each release fit into a theme? What kind of story or messaging can I craft with them? Being able to think that far in advance gave me a jump on writing long-form announcements like blogs, short-form announcements like emails, and super-short-form stuff like ad copy. And if you've ever tried your hand at copywriting, you know that the shorter the content, the harder it is to write!

Roadmapping

Second, that head-start let me identify releases where there really was no story. The potpuri of features, like that Bamboo 4.4 release I mentioned earlier.

And because we were looking several months into the future, I had the opportunity to ask whether we might rearrange some items on the roadmap to better group related features together.

Sometimes the answer was yes, and we rearranged a couple of release plans. But often, the answer was no: the features have to be built in a particular order for technical reasons, and the marketing story will simply have to suffer a bit.

And ok: I can accept that. What really mattered on a practical and emotional level was having that conversation and understanding why.

Like so many other relationships we have (or don't have), the key to keeping (or making) them heathy is to just keep talking.

Now remember: I'm telling you a story about an installed, versioned product vs. a continuously-deployed SaaS product. But the principles apply in either scenario.

Roadmapping

And it's likely that you, the people sitting here in this room, are gonna have to be the ones to initiate conversations like this and initiate that closer contact with your marketing and sales teams. So when you do, the way to sell them on the idea is to talk about how it will help TEHM work smarter. Here's a little cheat sheet:

“Hey, <marketer / sales rep>! I wonder if we could take an hour every couple weeks to sync up on what’s coming up in the next few months. I think it’d be a good thing for both of us to walk through the roadmap together and make sure we really nail the messaging.”

"Hey <marketer/sales rep>, I wonder if we could take an hour every couple weeks to sync up on what's coming up in the next few months? I think it would be a good thing for both of us if we walked through the long-term roadmap together and make sure we really nail the messaging."

So that's the caveman way of collaborating on roadmaps.

I also love the way the JIRA Service Desk team does it. The lead product manager set up a kanban board where each column represents a month, and each swimlane represents a workstream or theme for the product.

Then he populates the board with all the epics on their roadmap, placing each one in the column for the month they intend to have it ready for release.

Then inside each epic issue, there's a link to more information: user stories, requirements pages, designs, etc. Lots of info that helps the marketing team wrap their heads around the changes. Which is really important in this case because the marketers are mostly in San Francisco, and the dev team is all in Sydney.

So sharing information asyncronously is critical in keeping everyone's work flowing smoothly. I mean, the same is true even if you're sitting in the same building, but if you're across the world from each other, it's even more helpful.

I love this as a way to map out releases in a continuous delivery context. And it complements the fact that JSD's marketing now caters primarily to Cloud customers, who are getting updates delivered to them every 1-2 weeks.

Obviously, tight cycles like that don't lend themselves to release-based marketing. Having this information readily available (and always up to date!) is critical for marketing a continuously delivered product.

It means marketers aren't simply reacting to what's coming up the the next release. They understand the longer-term trajectory of the product, and are able to craft broader campaigns that highlight, for example, everything about JSD's SLA management features – not just the incremental improvement we shipped this week. (Tho that new improvement will indeed be mentioned, to be sure.)

I understand that, working at Atlassian, we can take it for granted that marketers, developers, sys admins, and everyone else have access to all the same systems because we make all those systems.

And that at other companies, that may or may not be the case. Depending on what tools you're using, there may be an extra cost associated with creating accounts for your marketers (assuming they don't already have one).

But do consider it.

Or consider putting together a quick n' dirty agile board using Trello or Pivotal Tracker as an experiment or pilot before paying for more seats in JIRA, or Rally, or whatever.

Which is a tidy little segue out of agile world, and into... kindergarten. Why kindergarten?

Sharing is caring.

Kindergarten. Why kindergarten?

Because one of the most important things about kindergarten is learning to share. And sharing is hard! It's pretty much the opposite of what we're evolutionarily programmed to do!

Nonetheless, sharing is a big part of DevOps. It's so important that sharing is almost universally recognized as a pillar of DevOps.

Page title here


• Level One Tools

And one of the ways to foster better coordination with marketing and sales is to share tools.

You probably don't need to give marketers access to your repos, and for the love of God, do not give us root.

But tools for issue tracking (JIRA, Trello, Pivotal, etc) and document sharing (Confluence, SharePoint, Basecamp, Asana) should be shared.

I could wax philosophical about transparency and visible work and a culture of trust. But really, this is about practicality.

Without shared tools, collaboration hacks like virtual or recorded sprint demos, or an agile board representing your product roadmap are so painful and cumbersome that they're almost guaranteed to fail.

Collaboration hack: review blogs & web copy

For example, shared tools make it way easier to provide feedback on drafts for blogs or landing page copy – which is another solid collaboration hack. If the content goes into detail about your product's features, it's helpful for someone who built those features to review the copy for accuracy.

You'll be happier, Marketing will have more confidence in it, and customers won't be accidentally mislead, which means customer support will definitely be happier.

Page title here


• Level One Tools

Ideally, your whole company is standardized on common tools for project tracking and document sharing already. If that's not the case, you'll likely need to start by granting folks from marketing access to your tools, and requesting that they grant you access to their tools. There's a bit of overhead involved, but I think you'll find that the benefits outweigh the annoyance. And you may converge on a single tool eventually anyway.

And this isn't something that necessarily has to eat into your operating budget. Between Google Docs, Evernote, and open source issue trackers and wikis, there are loads of free options.

Which means you may not need approval from on high before you can give shared tooling a try.

So in short, shared tools are worth it, can be free, and therefore don't require executive sponsorship. There: all your excuses are gone.

Know your classmates.

Now, sharing your toys is one kind of sharing we learned in kindergarten. The other kind is sharing things about yourself – sharing information.

Within the context of this talk, sharing information isn't necessarily about showing off your accomplishments. It's really about helping one group understand where another group is coming from.

What are their goals? By what standards is their performance measured? What are they struggling with? What are they kicking ass at?

It’s like the grown-up version of show and tell.

Page title here


• Level OneInformation

From the dev and ops side, we've found that it's helpful to share data on alerts, uptime, and technical debt (especially user-reported, or user-voted bugs).

This is stuff that you measure and track for your own team's information, so sharing it with marketing probably isn't hard. You can give them access to an online dashboard, or turn it into a wallboard if you've got a big monitor or TV you can mount.

The hardest part is probably getting over the emotional hurdle of revealing that much about your team's work and trusting other teams to be cool and not use any exposed weaknesses to score political points.

(And if your workplace has that kind of vibe, come talk to me later because Atlassian is hiring, and we have a very low tolerance for BS like that.)

Show and tell, part 1.

Here’s an example wallboard from the Bitbucket team.

In my experience, having easy access to this kind of data helps me understand release plans. Like, why we're shipping 2 features and 5 bugs fixes this release instead of 5 features and 2 fixes.

As a marketer, I might be disappointed, but at least I've got context.

And context goes a long way in turning around any kind of adversarial tone in the relationship between marketing and development.

Without this kind of context and communication, it's really easy for marketers to think devs care more about having perfect code, or tinkering with some new technology, than they do about delivering value to the customer.

Similarly, it's easy for developers to think all marketers care more about shiny new features and quick sales than they do about offering a quality product and maintaining a good relationship with the customer.

Show and tell, part 2.

X,XXX

So from marketing's side, we find that it's useful to share information about bookings (if you can) or leads, progress toward the revenue goals, page views, social chatter… whatever.

Seeing this kind of info helps development teams understand why marketing is so damned stressed about a release that slipped or why they keep asking you to give a certain feature higher priority on the roadmap.

Page title here


• Level OneInformation

Case in point: I mentioned earlier that I'd been on the Bamboo dev team's case to prioritize the feature that would support a "CI in the enterprise" angle. The feature in question was support for over 100 build agents, which was the max you could run at the time, and our larger customers maxed out pretty quickly.

Anyway, one of the reasons I was on them about it is that we wanted to rank better for some search terms related to continuous integration in enterprise-scale companies.

In this particular instance, SEO opportunity wasn't enough to pull that feature up to the top of the backlog. But being open about my goals as a marketer allowed us to have a conversation about how I might meet them.

Just as being open allowed us to have a conversation about balancing market opportunities with paying down technical debt.

Conversation provides context. Context breeds collaboration. And collaboration is everything.via @DevToolSuperFan #devopsdays

If my presentation here today prompts you to take one action, let it be conversations.

Because conversations provides context. Context, in turn, breeds collaboration. And collaboration is everything that DevOps is about at it’s core.

So just start talking to each other. Yes: it is both that simple, and that complex. And keep talking – even when you're at odds about one thing, there are still pieces of common ground you can stand on together.

Successes

Such as celebrating successes. Celebrations are a very fertile piece of common ground. Doesn't matter if you've just shipped a big release, hit a goal around technical debt, or are just kicking back for the sake of kicking back.

I encourage you to invite the people from sales and marketing that you work most closely with – we are part of your extended team. So are customer support, technical writers, and designers! (I mean, if you're gonna have a little party, you might as well make sure everyone is invited, right?)

Like everything I've talked about today, I'm talking about technical folks taking the initiative to reach out to marketing folks and invite them in.

Is it fair for that burden to rest solely with engineering? No. But who cares? That's not the point. It'd be tragic to miss out on a better relationship and better coordination just because both sides are too stubborn to make that first move.

Start inviting. Start asking. And if all you hear is crickets chirping, or you face resistance, keep asking.

It might be a matter of finding that one person who is interested in connecting, and working with them. Make them your champion. Their teammates will catch on and join in before too long.

Marketing: your allies in the fight for devops


Q & A

We're almost out of time, so I'm going to leave you with that thought, and open it up for Q & A.

Reading list

blogs.atlassian.com

developer.atlassian.com/blog

www.atlassian.com/devops

marketing: your allies in the fight for devops – full text (devops days minneapolis 2016)

Software