Recommended
Recommended
More Related Content
Viewers also liked
Recently uploaded
Recently uploaded (20)
Marketing: your allies in the fight for DevOps (DevOps Days Minneapolis 2016)
- 1. Marketing: your allies in the fight for devops SARAH GOFF-DUPONT • ATLASSIAN • @DEVTOOLSUPERFAN FOR DEVOPS
- 2. “Hi, I’m Sarah.”This is what we’re fighting for.
- 3. “Hi, I’m Sarah.”This is what we’re fighting for.
- 4. Marketing: your allies in the fight for devops SARAH GOFF-DUPONT • ATLASSIAN • @DEVTOOLSUPERFAN FOR DEVOPS MARKETIN G ENGINEERIN G - P. DUBOIS
- 5. What IS the Atlassian voice, anyw ay? Agenda Voice vs. tone Words to choose (and w ords to lose) Atlassian’s values Minnesota? You betchya!
- 8. Page title here • Level One • Level Two • Level Two • Level Two • Level One
- 9. Page title here • Level One • Level Two • Level Two • Level Two • Level One
- 12. Page title here • Level One • Level Two • Level Two • Level Two • Level One Co-location
- 13. Proximity makes the heart grow fonder. MarketerMarketer General Manager Developers Designer
- 14. Page title here • Level One • Level Two • Level Two • Level Two • Level One Co-location
- 15. Page title here • Level One • Level Two • Level Two • Level Two • Level One Co-location
- 16. Demos
- 19. Roadmapping
- 20. Roadmapping
- 24. Page title here • Level One • Level Two • Level Two • Level Two • Level One Tools
- 25. Page title here • Level One • Level Two • Level Two • Level Two • Level One Tools
- 27. Page title here • Level One • Level Two • Level Two • Level Two • Level One Information
- 28. Show and tell, part 1.
- 29. Show and tell, part 2. X,XXX
- 30. Conversation provides context. Context breeds collaboration. And collaboration is everything. #devopsdays
Editor's Notes
- 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.
- 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.
- 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.
- Again, my name is Sarah and I'm on the marketing team at Atlassian. We make some tools that you might use like JIRA, Confluence, and Bitbucket. 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.
- 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.
- 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?
- 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...
- "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.)
- 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.
- Here's an example of a team that does this really well. This is the Atlassian ecosystem team. Their product is the Marketplace site for add-ons, as well as the core add-on platform that all our products use. Their marketers’ job is to encourage 3rd party developers to build add-ons, and encourage Atalassian customers to use those add-ons. So their role is a little different from, say, the JIRA team. You can see developers sitting along side marketers, a designer, and the general manager of the ecosystem business. And I believe some of our developer advocates will soon be sitting with them as well.
- 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 a typical developer workstation with 2 or 3 monitors.
- 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.
- 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 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.
- 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 Amazon virtual private clouds. The dev team added it to a release almost as an afterthought, but it was a huge boon to Bamboo's "CI in the enterprise" story.
- Then there's roadmapping. 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?
- 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 mental level was having that conversation and understanding why. 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.
- I love this way of mapping out releases because it works so well in a continuous delivery context. JIRA Service Desk delivers updates to Cloud customers every week or so, and they have about half their marketing team dedicated to Cloud-first marketing. Having this information readily available (and always up to date!) means those marketers understand the longer-term trajectory of the product, and are able to craft broader campaigns around larger feature sets – not just the incremental improvement we shipped this week. (Tho that new improvement will get some extra attention, to be sure.) So that wraps up the agile-themed stuff. The other collaboration theme I want to talk about is…
- Kindergarten. Why kindergarten? Because one of the most important things about kindergarten is learning to share. And sharing is hard! Nonetheless, sharing is so important that it’s almost universally recognized as a pillar of DevOps.
- 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. 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.
- I understand that, working at a company that makes team collaboration tools, I can it for granted that marketers, developers, sys admins, and everyone else have access to all the same systems. And at other companies, that may or may not be the case. Or there may be an extra cost associated with creating accounts for your marketers to use. Keep in mind that shared tooling doesn’t have to eat into your operating budget. Between Google Docs, Evernote, and open source issue trackers and wikis, there are loads of free options. So if cost is a concern, consider using free tools as kind of a pilot program for sharing before pay for more seats in JIRA, or Basecampe, or whatever. It’s ok to be scrappy at first.
- 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? This kind of sharing is like the grown-up version of show and tell.
- 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 that information 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.)
- Here’s an example wallboard from the Bitbucket team. This one shows a snapshot of what the service is doing right now. There’s also a wallboard next to it with aggregated data on bugs, uptime, load, and capacity over time. Having easy access to this kind of data helps marketers understand release plans. Like, why we're shipping 2 features and 10 bugs fixes this release instead of 10 features and 2 fixes. As a marketer, I might be disappointed, but at least I've got context. 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 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. And even though we usually aren’t held responsible for customer churn, we still care about it because high churn and bad word-of-mouth makes landing new customers a lot harder.
- Anyway, from marketing's side, we find it's useful to share information about sales (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 feature that slipped or why they keep asking you to give something higher priority on the roadmap. At the very least, if you’re paying attention to the info being shared, it’ll start some conversations.
- 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 we're at odds about one thing, there are still pieces of common ground we can stand on together. Start inviting. Start asking. And if all you hear is crickets chirping, or you face resistance, reach out to someone else. It might be a matter of finding that one person who is interested in connecting, and working with them. Once you’ve found them, make them your champion. Their teammates will catch on and join in before too long.
- I'm going to leave you with that thought. Check out any of these places for more ideas and perspectives on DevOps. And if you hate it, send feedback directly to me because there’s a good chance I either wrote it or edited it.