SlashData has come a long way, as has its DNA. It has pivoted and transformed itself several times. It has moved from a tiny consulting shop shedding light into the future of mobile software – to a leading analyst firm helping the world understand developers.  Our reputation reached all corners of DevRel ecosystem thanks to our Future Developer Summit series, podcast , our Developer Marketing and Relations book written by the who’s who in the DevRel scene.  With every transition, and through every phase we‘ve continued to develop as a business, learning from our mistakes and successes, running post-mortems, and always asking “what can we do better”. And now SlashData is changing yet again. We opened up custom research in 2021 which helped our revenues double over the last year. The market opportunity is growing rapidly, as every software firm is asking how to understand and engage developers who influence the purchase of their software. And it will grow even further, as every company under digital transformation needs to understand how to build and train its newborn developer workforce. After 15 years since founding SlashData, the time has come for me to move on. I ‘m passing on the CEO baton to Moschoula Kramvousanou . Moschoula has been at SlashData since 2017. She’s served the company, leading the Client Relations team and more recently Strategic Partnerships. She’s played a pivotal role in leading the company’s growth, not just in terms of sales and the growth of her team, but also catalysing several changes across the company and forging valuable relationships with clients and partners. She understands our clients and our market intimately, and has helped propel forward every team. Moschoula is now taking the team through the next few years of rapid growth, stellar reputation and carrying forward our tradition of innovation, always asking – “what can we do better”. The company could not be in better leadership hands, in a better shape financially, or in a better place for demand and market growth. Here’s to the road ahead! Andreas Constantinou SlashData Founder #companyannouncement #slashdataannouncement #slashdatacompany #ceo #newceo

Developers have a wide variety of support and learning needs that evolve as they progress through their careers. Here, we’ll look at some of the best ways to help developers build on their skills by answering their technical questions, creating a valuable community that they can integrate with, and providing professional certifications as proof of learning. In a highly competitive job market, vendors can demonstrate value to developers by helping them to build on their skills and get an advantage in the job market. Here, we take a look at data from two of our most recent Developer Nation surveys. In our Q1 2021 survey, we asked developers, amongst many other topics, how they prefer to communicate with vendors about technical topics. In our Q3 2021 survey, we took a deeper dive into developers’ views on what makes great technical certifications and what are the key features of a successful community. The data here is only a small sample of what we collect, so if this sparks some interesting questions for you, then please get in touch. It’s a matter of experience Data from our Q3 2021 survey, which was fielded between June and August 2021, shows that overall, there are more early-career developers (those with 0-2 years of experience) than highly-experienced developers (those with 11 or more years of experience). Developers with different levels of experience undoubtedly have different support needs (and we’ll come to this later), but taking a global perspective on experience levels risks missing some interesting regional variations. South Asia and Western Europe sit at opposite ends of the experience spectrum – South Asia has the largest proportion of inexperienced developers, and Western Europe has the smallest. This means that when creating a regional strategy, not only should you think about the cultural and economic differences that exist between regions, but also, due to their experience levels, developers will have very different support needs. Technically correct is the best kind of correct We see here how developers’ support needs evolve as they gain experience. In fact, communicating with vendors about technical questions becomes more important as developers gain experience – more experienced developers are very likely working on more challenging projects and, as such, more often require expert support. What’s interesting is which communication channels become more important. Email is consistently the most important, regardless of experience level. It seems that the power of direct, asynchronous communication is clear to all developers, though it does become more important to more experienced developers, as well as to older developers (and age is, of course, correlated with experience). On the other hand, other direct but synchronous communication methods such as online chat retain their importance to developers of all experience levels (but fall in importance for the oldest), whilst live interactive coding sessions only fall out of favour amongst the most experienced. Not every communication method is created equally, and neither is every technical question. Irrespective of their experience levels, developers want to engage directly to have their technical questions answered and are happy to do synchronously or asynchronously. Issue trackers and code repositories nearly quadruple in importance for the most experienced developers when compared with the least experienced. Here, you have experienced developers asking their technical questions through established open-source channels that may feel inaccessible to less-experienced developers. There’s definitely scope to widen participation amongst inexperienced developers in this fundamental pillar of software development. We also see that Q&A sites steadily increase in importance as developers become more experienced. That’s not to say that inexperienced developers aren’t going to StackOverflow – they’re still using such sites to get information; it’s just that they are more likely to simply consume rather than ask technical questions of vendors. A sense of community Interacting with vendors or peers through a code repository or on a Q&A site is one of the many ways in which developers interact with their community. Community support is a powerful facilitator of learning and development for many developers and is as much a source of inspiration as it is camaraderie. We see that developers of differing experience levels have very different ideas about what they want from a community, but collaboration and support are two of the most stable and important features to developers of all experience levels. But experienced and inexperienced developers lean on their community support network in different ways. A knowledgeable community becomes more important to developers as they gain experience – here, these most experienced developers likely find more value in a community that can help them answer complex questions. On the other hand, inexperienced developers are more likely to look for strong leadership in a community – they are likely looking to more experienced members for guidance and learning opportunities. Certifiably important Vendor support and community are just two of the myriad ways that developers build their skills throughout their careers, but in an increasingly competitive professional environment, many developers study for professional certifications to get an edge. Such certifications are important to developers at different stages of their professional life – early-career developers are likely looking to distinguish themselves from the masses, whilst seasoned professionals may want to protect their lucrative career or even switch specialisation. Regardless, because of certifications’ wide appeal, developers at all experience levels similarly agree on the importance of certifications being suitable for a variety of learning styles. On the other hand, industry recognition, online availability, and affordability are three of the most important features of a professional certification program, and they become more important as developers gain experience. This demonstrates that as developers mature, they become more focused on the core aspects of professional certifications. We also see how their job-seeking habits change. The importance of recognition on job boards rises steadily from zero to five years of experience before falling sharply afterwards. This suggests that after around five years in the industry, developers have built their professional network and are less reliant on job boards, though the professional credibility of a certification is still paramount. What does this all mean? Here, we’ve seen that there is great variation in the experience levels of developers across the world, as well as between different geographical regions. We’ve also learnt that developers of different experience levels have very different views about the type of support they want to receive from vendors and from their communities, whether they are asking technical questions or becoming certified. Therefore, you should look at the experience levels of your user base and use this to figure out how best to support them. However, experience isn’t the whole story; our extensive research shows that a plethora of factors influence developers’ needs and decisions. Developers’ roles, level of decision-making seniority, industry, and technology choices all impact their needs for support. Understanding developers’ needs and behaviour requires not only a rich set of data but also extensive experience and knowledge to build the personas that inform a robust strategy. Don’t know where to start? Well, at SlashData we have a wealth of experience in understanding developer behaviour through our twice-yearly global survey, as well as through numerous custom research projects with our clients and partners. We also have a deep and detailed body of research on developers through our Developer Program Benchmarking research. Get in touch to find out more. You can also go through a case study that shows how Okta and Mozilla used the Developer Program Benchmarking to bring their developer program among the Top 3 in terms of developer satisfaction. #developerexperience #developersupport #developerprograms #developersexpectations #developerresources #developerstrategy #developers

Developers. Decision-makers. Kingmakers? For several years now, at SlashData we have been helping our clients – some of the biggest names in tech – to understand how their developer programs measure against the competition. Twice a year, we run an extensive and wide-ranging global survey to understand who developers are, what tools and resources they use, and where they are going. Developers share with us their experiences with vendors’ resources – which ones they use, how often they use them, and how happy they are with the experience. We also dig a little deeper into what developers value in vendor support, resources, and communities. Our research shows that developers are becoming increasingly involved in all stages of the decision-making process. Not only are they writing specifications for vendors and tooling choices, but they are also influencing decision-makers and budget holders. If software is eating the world, then developers are writing the menu.  To attract developers, many tech companies are actively investing in Developer Relations (DevRel) teams and developer marketing activities. They are creating an abundance of resources, training programs, technical support, events, and community activities. It’s not always clear which activities should be priorities and how resources should be allocated to achieve long-term strategic goals. We are here to help. Our Developer Program Benchmarking research tracks 20+ of the leading developer programs, and captures developer sentiment across more than twenty developer program attributes, ranging from documentation and sample code to mentoring programs and access to experts. In so doing, it helps DevRel and developer marketing practitioners understand how their developer program compares against the rest. Here, we give you a snapshot of the state of play for these developer programs. We use three KPIs to create a 360° overview of how each developer program performs: Adoption – How many developers use a vendor’s resources Engagement – How frequently developers engage with the resources Satisfaction – How developers rate their experience using the resources We can see that the Market Leaders; Google, Microsoft, and Amazon highly engage and satisfy developers. Their market share – or adoption rate, shown by the size of the bubble – reinforces their market-leading position. In fact, when we take a longer-term view of this data, it becomes clear that Google and Microsoft have long been the market leaders, staying at or near the top of the table for all three KPIs.  Recently however, Amazon has made considerable progress. In fact, Amazon’s developer program has been growing faster than the global developer population, which is currently 24.3M (you can explore more in our developer population calculator ), while Google and Microsoft’s share has dropped slightly. When you take into account the large increase in Amazon’s satisfaction score and their aggressive growth strategy, the top table positions don’t seem so assured. Our data also uncovers the Satisfying Specialists – these developer programs are often small and focused. Unity, Red Hat and DigitalOcean sit firmly in this space. Developers don’t need to engage frequently with these vendors’ resources, but when they do, they have an excellent experience. For these vendors, low engagement is not a cause for concern, though it does come with its own challenges – when developers have fewer touchpoints there are fewer opportunities to speak to them or to influence their behaviour. For these (and other) vendors with low engagement, messaging becomes vital.  The Under-realised Value segment contains developer programs that, although having high engagement amongst developers, are being held back by their low satisfaction ratings. These programs are often (though not always) small, and the vendors here have a clear imperative to improve their developers’ experience. Thankfully, with developers engaging frequently with the resources there are ample opportunities to effect positive change. But what, exactly, to change?  This brings us to the true power of our Developer Program Benchmarking research. Not only do we understand how developers engage with vendors’ resources, but we also know which resources are important to developers, and how satisfied they are with the resources that companies provide.  Though developers’ preferences change and evolve, some things stay constant. Of the twenty-plus resources that we ask about, documentation & sample code, tutorials & how-to videos, and development tools, integrations & libraries have consistently been rated as the most important resources that companies should offer. This shows that developers are focused not only on getting things done, using documentation and development tools to speed up the development process, but they also highly value having the opportunity to learn. We can see this repeated further down the list – training courses & hands-on labs provide the learning opportunities, whilst technical support allows them to lean on experts when they need to. In this way, we can tell which resources developers value, and how their experience matches their expectations. This information, when combined with our wealth of survey data on demographics, firmographics, technology choices, motivations, skills, and much more, becomes incredibly powerful for informing strategic planning. We help some of the leading tech companies in the world to understand precisely which resources need improvement, and which developers will benefit most from such improvements. Have you ever wanted to know how to tailor your tutorials to the right level of complexity? Have you ever tried to decide how to localise your content? What about marketing to enterprise developers, what do they care about?  We also go a level deeper. For many developer programs, we specifically ask developers how they use resources relating to different products or disciplines. For example, we help developer programs to understand whether or not they are vulnerable in the cloud compute market, or what are the specific preferences of developers using IoT resources. Once again, coupled with the rest of our rich and diverse data, this information allows you to create a finely tuned strategy that allocates resources efficiently and effectively. With developers having such power in the decision-making process, this is a win-win for everyone involved. By understanding what developers value, you can tailor your offering to suit their needs, increasing retention, growing your audience, and ultimately, adding to your bottom line. SlashData are the analysts of the developer nation, and we can help you understand developers. You can download a preview of the latest Developer Programs Benchmarking here . #slashdataresearch #developerprograms #google #developersatisfaction #developerresearch #developerengagement #developerprogrambenchmarking #developers #microsoft

Over the last 4 years, we’ve spent thousands of hours building the culture at SlashData, one step at a time. There is no better picture of the culture than the values that underpin it. In this article, I strip SlashData bare, describing in great detail our values and the behaviours that underscore them, that is the blueprint for our culture, who we are, and what guides our behaviour. In his book Traction, Gino Wickman describes values as “a small set of vital and timeless principles for your company…These core values define your culture and who you truly are as people”. Values guide a number of important activities at SlashData: – Hiring: Every person that we hire has to be a good fit for our culture. No fit, no hire, even for the highest of performers. We never sacrifice the cultural fit to hire primadonnas. I’ve made many mistakes hiring people based on performance, thinking that their cultural fit will improve over time. – Reviews: Every six months we assess performance and cultural fit for every team member. We offer guidance on where to improve, how to tap into your hidden strengths, and whether you are observing the company values. We used to have a bonus scheme for how closely a team member would observe values, but we’ve made that depend on performance only for a simple reason. If you’re not observing our values, that’s a deal-breaker, our relationship is not going to work out. – Benefits: Among other benefits, we award people for every year they’ve been with us. The list of benefits is informed by our values; awards include ways for team members to contribute to a charitable cause, to take up a new learning course – How we work with customers: we treat our customers with the same respect, dependability and attentiveness as we treat our colleagues. – Business decisions: Our 3-year business strategy is informed primarily from helping people grow, not from returning a profit to the business. People growth comes before profit, and profit comes before revenues. We’re not VC-backed, so we don’t have to return astronomical growth just because a VC partner asked. Profit takes precedence over revenues, making sure that we run a business that can function well and can spend time on developing people and having fun together. And people growth takes precedence over profit. For people to grow, their role has to grow, and as a small company, that means our business needs to grow to create new opportunities for our team members. What are the values and the behaviours that underscore them? Here’s the full, unfiltered list. If you ‘re competing with us, go ahead and copy us. And if you like what you see come and join us. High Performers Behaviours: We ‘re a team of high performers. We pay attention to detail, always striving to deliver top quality work. We are adaptable: as part of a growing team, we try out new things, we create new processes, and we adapt ourselves as the needs of the business change. We focus on what’s important and stick with it. We define our team and individual goals every year and every quarter so that every team and everyone knows what to focus on. Each of us has their own, effective system for organising their work on a daily and weekly basis. We continue raising the bar with every new person joining the team – every person we hire has to be better than the average of the team. We start with the end in mind: to get to the bottom of the issue, we start with what we are trying to accomplish. We trust each other to be dependable and deliver on our shared goals. We deliver to our clients as we committed so that they continue to trust us. Each of us assumes responsibility and doesn’t blame others or the system. We play like a sports team. If I score and the team loses, I have lost. Always Learning Behaviours: We strive to grow as individuals, both personally and professionally, to realise our full potential. We are restless to take the company to the next level. We invest in our personal development by reading books, attending courses, seminars and conferences. We learn from our projects by running post-mortems and understand what went well, what went wrong and what we can improve next time. Errors and issues are there to help us improve. With each issue that we spot, we fix the process so that the issue doesn’t happen again. We are a diverse team and value the uniqueness of each individual. We like to learn from each others’ experiences and perspectives. We treat every challenge as an opportunity, whether it’s about people or projects. We challenge our assumptions and the way we do things. Play as a team (was fun) Behaviours: We help each other out when in need. We are dependable and accountable. We agree and we commit. Once a year at our team event we spend 2-3 days in strictly no working time together to have fun, create memories and bond. The entire team gets to meet and catch up once a week on video. We strive to maintain a positive, fun and engaging place to work. We hire people that we are proud to work with, people that we can have fun with solving complex challenges together. We take time out to get to know each other, create friendships and enjoy the moment. Humane Behaviours: We are kind to our team members. We are thoughtful. We are compassionate. We support our team members when they come to us for help We welcome and support new team members. We have an extensive onboarding process, helping each new member acclimatise and feel comfortable. We trust & respect each other, even if we have different opinions. We practice flexitime around our core working hours, allowing everyone in the team to manage their work/life balance. We actively listen and practise empathy. We take the time to listen to what someone is trying to say – and understand how they feel – rather than thinking how we will respond. We criticise in private, we praise in public. Always. Transparent Behaviours: We are transparent with every aspect of the company’s operations, except for financial information. That information is available from the day someone joins our company. We are clear in our communication. We make sure everyone has understood, and has been understood. We share feedback for each other immediately – within hours or days, not holding it back for months. When there is a conflict, we are transparent about stating how we feel, good or bad We systematically communicate with the whole team where we stand with respect to our goals and tasks We communicate proactively when things don’t go as planned. If a task is likely to be late we give adequate notice to our colleagues or clients – as much notice as the delay. Data driven (Data driven) Behaviours: Data beats opinions in every argument and in every decision. Any investment that we make is measurable – so that we always know what to do more of and less of. We ask the questions to help us understand what drives the business forward. We measure the efficiency of our major meetings, how well our managers are doing, and through bi-annual staff feedback reviews, we measure how well the company is doing for the team. We listen to our customers’ needs every day and we measure customer needs every six months. Every Voice Matters Behaviours: Everyone in the team has a right to express their opinion on how the company works or should work. We have regular internal reviews where everyone can voice their opinions on our culture, our managers and our performance. We don’t just read them, we act and we feedback to each other We openly debate and we stand up for our opinion. We disagree and commit. We can disagree while a decision is being made, but once a decision has been made, we put our personal opinion to one side and commit to it. Our CEO organises breakfast meetings with each person in the team making sure every voice is heard. Everyone can provide regular feedback about our company and raise issues anytime. #slashdata #culture #management #values #datadriven #leadership

What do developers value in open source? How have their needs changed due to COVID-19? The 19th Developer Economics global survey wave ran from June to August 2020 and reached more than 17,000 developers in 159 countries. Hot off the press “ State of the Developer Nation ” report presents developer trends for Q3 2020 and beyond. The report is free  to access and focuses on six major topics, providing answers to questions like these: Developers’ extra needs due to COVID-19 Programming language communities – an update Why do developers adopt or reject cloud technologies? Who is into DevOps? What do developers value in open source? Emerging technologies Some highlights to spark your curiosity: Developers’ extra needs due to COVID-19 Four in ten developers report that they need more flexibility in working hours/workload as a consequence of COVID-19. Developers responsible for tooling specifications and for approving budgets and expenses are in the greatest need of increased security, performance, and cloud space. What do developers value in open source? Developers appreciate collaborating and interacting with the open-source community more than contributing to open-source projects. South Asian developers highly value contributing to open-source projects, positioning this region to drive the next wave of open-source development. Developers who are building apps and extensions for third party ecosystems, on average, value contributing and forking more than developers in other sectors. Who is into DevOps?  DevOps has reached mainstream adoption. The vast majority of professional developers (more than 80%) are involved in DevOps in one way or another. Continuous integration (CI) and continuous deployment (CD) are two of the most common DevOps practices, but only one in four developers use both to fully automate their workflow. Download the full report here . The report is free to download for all community members including developers and industry enthusiasts. #devops #covid #opensource #languages #developers

Too many challenges with corporate culture are down to accountability. Let’s say you work in a medium-sized firm. A colleague you depend on has disappeared for the last week and won’t answer your emails. Then a VP from another team comes to you with a request you had no idea about. And your boss is too busy and can only book you in, in two weeks’ time. Have you “been there, done that”? I used to once run a company like this. But I was doggedly determined to improve things. Over the last 4 years we ‘ve built a culture of accountability at SlashData. I ‘d like to share the lessons we ‘ve learned along the way, hoping that more business leaders can learn from it. We ‘ve built a culture that treats people as adults, and expects people to behave as adults. So where do you start to build a culture of accountability? Right seats first I started by setting clear expectations of where one person’s role ends, and another person’s role starts – an accountability chart. Before the accountability chart, our roles and responsibilities were people-centric. We would first choose the right people, and then allocate them the right seats i.e. responsibilities. I realised how this was the wrong way round, after reading Gino Wickman’s Traction book, which was recommended to me by a fellow entrepreneur at EO. In what it terms the Entrepreneur Operating System, Wickman proposes a strategy of “first right seats then right people”. That change introduced much-needed structure and clarity around people’s roles. We no longer had role overlaps, or multiple people talking to the same customer. I also found that several important roles within the company had no single person taking responsibility, and that meant that while many people were responsible for e.g. marketing, no one was accountable for it. That led to miscommunication, frustration, missed deadlines and confused customers. With fixed seats in the accountability chart, we also started to see how people could evolve in the organisation, and what career path we could offer to new people coming in. It also meant people felt much safer about their roles and responsibilities. For the history books, this is the first rendition of our accountability chart: Today we have a clear accountability chart, where we start with the seats and then select how people will evolve from seat to seat. We also leave seats empty for future hires. Based on the top layer of that chart, soon after I put together the leadership team, consisting of the people leading the individual teams – marketing, product, tech, and so on. Today, we have a leadership team made up of seven people, including myself, and the individuals leading partnerships, product, marketing, sales, technology and people/finance. The leadership team is solely responsible for making decisions on the company’s 3-year strategy all the way to the 3-month team goals. And my role in the leadership team is not to manage (I hate that word) , but to integrate and enable them to make timely, aligned decisions and stay true to their commitments. I prefer to “lead from behind”, helping ask the right questions, rather than lead from the front, pointing the way forward. At the leadership team, our role as leaders is to bring the best out of our people. And shine the light onto their hidden strengths and help them grow. Image source. OMG, no pool tables? When VC-backed tech companies talk about culture, they advertise pool tables, dog biscuits, and gourmet coffee. Yet this is only at the very top of the pyramid or hierarchy of our needs at work. At the base of that pyramid are the safety and clarity of everyone’s individual role, their shared goals, and how their role contributes to the company’s short term and long term objectives. Goal setting and alignment is core not just to a well functioning remote team, but also to a sense of direction and purpose for everyone in the company. Having set the record straight with the right seats, then the right people, I set out to create alignment. I’ ll never forget when four years ago we published a paper that was destined to be a flop; it was led by two different leaders in the company, who each had very different perceptions of what the research paper set out to do. Their individual goals were pointing in very different directions, and they hadn’t realised until I pulled them into the same room. By that time the work was wasted, but an important lesson was learned. If the goals of the people are not aligned, you ‘ll end up like a boat with oars moving out of sync, and going nowhere. We started by getting all the leadership team in the same room and debating what we should achieve in the next year. We used Objectives and Key Results (OKRs), in what I thought was a major innovation at the time. That was four years ago. Today, our goals setting process stretches from 3-year goals for the company to 3 month goals for individual team members. I ‘ve talked a bit about how that process works here. One important aspect of goal setting and alignment is avoiding conflicts and negative surprises along the way. For example, if the partnerships team depends on a piece of tech integration to be built, it can say so, but unless the tech team commits to building it, that is a recipe for failure. Today, every team lead in the company needs to explicitly state for which OKRs it depends on other teams, and secure that team leader’s commitment in reciprocal OKRs. That ensures we don’t have any phenomena like “I ‘m too busy with my goals and I can’t help you” type of response. Goal setting creates alignment across the company, in a top-down fashion and is a key ingredient of an accountability culture. We treat everyone as adults, including the leadership team, expecting each member to propose and then commit to shared goals. And see these goals to fruition. We still use OKRs to transcribe our goals, but only as a form of notation. OKRs are not a process, they are the syntax of setting goals, making sure that you know where you are going, you can check if you ‘ve taken the right steps towards that direction, and that you are transparent about it. We also track OKRs every week at the leadership team level, expecting every team lead to be transparent about whether a goal is on track, falling behind, or at risk of failing. Early warnings are always better than late surprises. In fact, the very reason I’m writing this blog post is that I ‘ve committed to it in the eyes of the leadership team, and I don’t want to let them down. Oh, and I love working on our culture, and helping other entrepreneurs build theirs. Which country are you working from today? One of my colleagues is a traveller. She could be visiting friends in Poland this week, and then seeing her family in Lithuania next week, before returning to her home in Athens. While most tech companies would expect her to be working from a fixed seat at a fixed desk, in a glamorous building made of steel, concrete, glass and sprawling with teak furniture, we expect her to be accountable to her goals and work from wherever she feels comfortable. Another colleague often works from Antiparos, a greek island where her husband runs a coffee shop. We used to be skeptical when people asked to work from home, but now we actually prefer that people work from wherever they feel most comfortable, as long as they are accountable to their goals, and are available at a time zone that their colleagues can communicate with them. We trust and respect our team, they are here because they want to be, not because they have to be – and we trust them to be capable of managing their own time and place of work. Photo by Neil Soni @ Unsplash I know where you were last week Not too long ago I used to rely on ad-hoc, infrequent meetings with my direct reports. It was the time before my divorce, when I spent practically every night waking up to attend to my younger son who hated sleeping in his own bed. Those sleepless nights, over several years, ended up destroying my memory, a causal effect I only discovered much later in life. At work, I was often teased for not remembering what we had agreed only the week before. Thankfully, at EO, I served on the board of a friend entrepreneur who was passionate with structured meetings (admittedly, in an OCD kind of way). Soon after I saw the benefits of turning all my work meetings into a variant of the level-10 meeting agenda, with clear accountability for past actions, and put those meetings in motion at a fixed time and date of the week. A fixed day/time of the week has numerous benefits as described in the Effective Manager book, notably accountability, predictability, but also a sense of safety that your team’s concerns and issues are being addressed in a timely manner. Today, almost every meeting we run at SlashData is recorded in a Google Doc, where we can easily scroll down to track past actions, and hold people accountable for what they committed to in the previous week. A key component of that agenda is the Parked Issues, where, during the days leading up to the meeting any participant can raise an issue to be discussed. That means, instead of interrupting their colleagues for important but non-urgent issues, those issues will get the quality time they deserve, and the attention they need to be resolved and translated into actions. With level-10-like meetings, accountability happens as a natural byproduct of the meeting process. We expect people to behave like adults and deliver on the commitments they ‘ve made, and we treat people as adults, checking in once a week, and getting the hell out of their way all other times. The first 182 days As the company was growing, we had to put a lot of thought and planning into onboarding new employees. To start, we had to learn from our mistakes. I “fondly” remember one of my colleagues recall how she found her “new” laptop having breadcrumbs the day she joined. Thankfully, we ‘ve come a long way since then. It’s not just the equipment, the IT setup, the induction tour, or the personalised welcome pack that each new starter at /Data receives. Each person that joins is immersed into our culture one step at a time. The first 6 months, or 182 days, is the introductory period. A new starter is assigned a buddy, a person who will guide them through how things work here, and help them find the right person, or the right information. In addition to the standard weekly 1-2-1’s, the manager will also check-in with the person at the end of the first month, then at 3 months, and then at the end of six months, to see how they are doing, whether their initial expectations matched up with the role in practice, and any additional support they may need to meet the expectations that were set out in the job description (borrowing from the TopGrading methodology). That way, the new starter is introduced to the culture of accountability, while the hiring team makes sure we can take out any obstacles, and help the new hire succeed. Treating people as adults Treating people as adults is making them responsible for their own goals, where they work, giving them the tools to succeed, and taking all the obstacles out of the way is part of our culture at /Data. We ‘re on a long journey to build a role model of a culture, one brick at a time. Join us. #accountability #culture #slashdata

SlashData to join the Fellowship19 initiative As a developer economy analyst firm, SlashData is a mediator between the developer population and the network of thought leaders in developer marketing and developer relations. Our primary aim is to help the world understand developers and developers understand the world. Such a role enables us to see the immense value in communities, and what power the tech industry as a community can generate to continuously drive itself forward. Industry answer to COVID-19 – Fellowship19 In light of current events caused by the global outbreak of COVID-19, we, along with many others, have to make hard business decisions from postponing events and suspending field client visits, to shifting our annual strategy. While we’re forced to stock up with patience and resistance to not be taken away by the circumstance, SlashData’s team remains determined to give back to our community and clients, as well as, extend our effort to support others in the industry. That is why SlashData is joining a kind initiative called Fellowship19 with a clear mission: “Tech is our family. We help our family overcome the Covid-19 crisis, for free.” Together with other tech professionals, we will offer our help for free to support tech companies of all sizes stay afloat during the global crisis we are experiencing. SlashData will support the tech community by offering advice on content marketing, event planning (shifting from offline to online) and thought leadership. “We rise by lifting others.” — Robert G. Ingersoll This is a great reminder of how community members can empower one other in the most unpredictable circumstances, and hold on together even in the face of a global crisis. Whether your business already has its own content to share with their community or not, there are many ways to give a hand to your industry peers digitally. Here’s how we do it: While our Future Developer Summit has been postponed to October, we provide additional resourceful online content for our community of professionals in developer relations, experience and marketing in the format of newsletters and webinars. We combined our expertise and love for developer marketing into a DevRelx, a hub for professionals and enthusiasts in developer relations, experience and marketing, with multiple free resources for your professional growth such as podcast with experts in the field, industry news, job openings, the latest trends of the developer ecosystem and more. As remote-first techie team, we have built a strong organisational culture and have valuable insights to share on how to manage a remote team while nurturing not only the productivity but a human element as well. Tips, tools and tricks – all disclosed in a write-up and video by SlashData’s CEO Andreas Constantinou. Submit your question, find more experts who are ready to help, or offer your expertise on Fellowship19 website: https://www.fellowship19.com You can also send your inquiries directly to Viktorija – Events & PR Lead at SlashData. #coronavirus #COVID19 #techindustry

We’re currently on countdown mode. The Future Developer Summit is coming on April 7-8 to help developer marketing and relations leaders engage open-source developers. But to us and our participants, it’s more than that. We are not just creating an event unlike the rest. We are creating a community of handpicked professionals who work together to push the boundaries of developer programs. As we are designing all aspects of the event, from working with speakers about their presentations to the music that will play as directors and industry leaders go through their challenges with their industry peers, we try to have all our efforts answer the trickiest of questions: How will we deliver real, tangible value to our community members to empower them to shape the future of developer programs? and Why would someone want to come to our event? Well, here’s the answer: It’s an exclusive, invite-only event. This means you have the chance to share best practices with other leaders in the developer marketing and relations world, as senior peer-to-senior peer. Experience the power of a community of director-level professionals who design developer strategies together. The Future Developer Summit is building a community for developer marketing and developer relations leaders, who acknowledge and embrace the value of collective effort and its impact on individual work. After the event, you will get back to work enriched with insights, new knowledge and ideas to maximize the impact of your developer program. It’s a full pack learning experience. And it’s definitely not an endless line of slide after slide. We have designed a variety of sessions so that you can make most of your time onsite. We have prepared for you 11 lightning talks, 4 keynotes, 3 fireside chats, 3 panels, and 2 interactive workshops where you will work in groups side by side with your industry peers. Plus: it is participatory. We want you to share your ideas or challenges. Polyphony is the only way forward for us and an integral part of our community. It’s aligned with the industry pulse. Each Summit covers a different aspect of the developer marketing and developer relations industry and aims to start a meaningful conversation for the community and its leaders. For April, the theme is focused on engaging open-source developers. It’s a platform for new ideas to grow. The interactive workshops combined with a diverse attendee roster help plant the seeds for innovative ideas to turn into strategies and push towards the future. From the 2017 Future Developer Summit, the “ Developer Marketing and Relations: The Essential Guide ” was born and is now, with its second edition, the most inclusive book and go-to guide for anyone who seeks to navigate and advance their career in the developer marketing and relations industry. It’s personal . A great opportunity to know the people behind the roles. People with whom you face the same challenges, in the same industry. People you can teach and learn from. Plus : The speaker lineup is outstanding! All Future Developer Summit speakers are developer marketing and relations leaders in the world’s biggest organisations such as Microsoft, IBM, Facebook, GitHub and more. We take pride in designing an immersive developer marketing learning and community partaking experience. Our latest Future Developer Summit earned an NPS score of 94 and put smiles on many faces, including ours. Why such a high score? We’ll let our attendees answer that for us: “ I met some awesome people, derived practical and useful knowledge, and felt a lot of love from folks who listened to my talk. You created a wonderful, safe environment that allowed for a real, candid conversation. I think the focus on D&I was a major factor in this. ” – Tim Falls, Digital Ocean “ This was an awesome event because the attendees are all leaders in Developer Relations at their company. Great networking and data-sharing opportunity! Thanks /Data! ” – Larry McDonough, VMware “ Future Developer Summit is an excellent resource for learning and networking with developer marketing leaders #HighQuality ” – Jason Fournier, You.i TV “ My annual moment to reconnect with a community of like-minded practitioners in a meaningful, focused manner. ” – Katie Miller, Google “ Great event – I have learned so much and met amazing people. ” – Amanda Whaley, Cisco Want more? Watch our video (warning: it’s a big teaser) and head over to futuredeveloper.io . 2019 Attendees #developermarketing #devrel #devrelevents #events

This is a transcript of the audio episode from our podcast. You can listen to the episode here. [Jo] Welcome to “ Under the Hood of Developer Marketing “, a podcast from SlashData. I’m Jo Stichbury, one of the senior analysts in the team and today I’m joined by Adam Fitzgerald. Adam, we’ve not met before. So I’ll give you a short description of my background and then I’ll ask you to tell me and the listeners about yourself. I have a fair amount of experience as a developer. I’m a mobile developer and since back in the early days, dealing with software for Symbian and I’ve also worked for Nokia plus a number of publishing companies. These days, I’m into technical writing, which I started when I realised just how difficult it was to find good explanations of difficult subjects. I’ve worked with a number of teams to grow developer portals and developer content to attract and retain developers. We worked together recently on the book “ Developer Marketing: The Essential Guide ” but we’ve not really met before. [Jo] So perhaps could you tell us a bit about your bio and your background? [Adam] I work for Amazon Web Services and have done so for the last five and a half years. I’m responsible for a few things at Amazon, including developer marketing, technical evangelism; I also am responsible for startup marketing and some aspects of enterprise strategy as well. So, a handful of things to do. I’ve been in the developer marketing and relations space for most of the last 15 years at various companies. And, I think developers are an incredibly important part of not just the technical ecosystem, but overall, for the general business. I think developers are the future for all businesses and that the companies that embrace and understand developers are the ones that are most likely to be successful. It’s a great place to spend your energy trying to help developers become successful. That’s been my big motivator for the majority of my career. [Jo] So, before you were in your current role, what did you do? Where were you? [Adam] Well, yeah, I’ll give you the express version. I started off as a mathematician at the University of North Carolina. But eventually, I grew a little bit tired of the academic work and I was already writing software for fun and as part of my research. A friend of mine had a startup that was teaching software development, as well as building an object-relational mapping tool. He asked me to join and I went to work for him. Shortly after I joined the company, we were acquired by BEA Systems and I worked for them for seven years. Starting off, I initially started teaching Java development for a few years. And then a bit server administration, business process management, web services and service-oriented architectures, all that kind of stuff. Eventually, I wound up becoming an evangelist for BEA. In fact, I wound up being the Demo Guy for web logic server for about a year, working directly for the CTO and doing demos at large events like JavaOne and BEA events. That led me to take over the developer marketing responsibility for BEA or the program we called Dev to dev, the DAB. At the time, there weren’t that many other companies that had developer marketing programs, pretty much Microsoft, Apple and us. So, it was a very small universe of companies that were really dedicated to thinking about developers. I left BEA in 2007 to join Spring Source, which was an open-source Java company created by Rod Johnson. There was created the Spring framework. It was a fantastic time. Super exciting for me. Spring was totally disrupting and changing the Java market. It was a great opportunity to go to a place where developers were the forefront of what mattered to the business. So, I worked with Rod and the spring source team for several years. We were acquired by VMWare in 2009 and I took on the responsibility to run the developer relations efforts with VMWare across their business. That later became product may now know is Cloud Foundry. I was part of the spin-out from VMWare to pivotal and I left not long after that, in 2013 to join AWS, largely because, you know, AWS was a company that spent a lot of time thinking about developers and, developers where clearly a critical part of their business. I knew a few people that were already working with Amazon and I had a chat with them about it and it was a great opportunity to come over and join a company that sought developers on their critical paths of success. And it’s been a really fantastic and engaging last five and a half years working for AWS. [Jo] Yeah. Sounds amazing. And you really have worked your way up from development all the way through. So I think it makes a difference. Some people say you don’t really need to be a developer, but I do think if you’ve been there yourself you have a different perspective and maybe a different way of talking, which can help with communication. When you were a mathematician, did you think you’d end up in this kind of area and how do you think your self would see you now? [Adam] No, there was no way, as a mathematician, I would have thought that this was ever going to work out. My concept of myself didn’t look anything like this. I was very much on the academic path; looking at faculty positions, teaching undergraduate mathematics, that kind of thing. The earlier version of myself wouldn’t recognise where I am now. But there is something that does -sort of- bridge across the two. And that was again, mathematics. There’s an awful lot of value in understanding the abstractions of different types of mathematics. Lots of people get caught up in the details of mathematics and way down in the weeds and implementing individual tasks or looking at particular numerical analysis or understanding particular partial differential equations. But my strength was always in mathematics, looking at the more abstract elements and sort of taking commonalities across a whole class of different things and looking at them in a different way. And that’s very, very true in the technology space. If you look at the big movements, over the last five or six years, whether it’s in machine learning or containerisation or serverless computing, they’re all really abstractions away from the individual implementation details to get to higher level constructs that allow you to operate more effectively. So, if you’re not afraid of diving into the details, but willing to see through the trees to see the actual forest, then that becomes really useful. And I’m far from a hands-on keyboard coder these days. I’m not going to be implementing very much. But my background, both mathematical and technical, I think it gives me the ability to sort of get in touch and organize the new technology logically in my mind, in a way to make sense for me. I think that’s where the mathematics has been a strength for me. [Jo] I think I took a similar path to you. I was in academic chemistry. And I was spending hours a day standing in the lab cooking up various things. And it just happened that I was reading the Guardian one Saturday and there was a job advert I saw in software and I thought “I should give this a try”. They offered me a job and I switched and in many ways it was a fantastic opportunity, but because I didn’t have a degree in computer science, I didn’t have any real qualification with C. So I sat in the library at Imperial College where I was first cooking in chemistry, now learning C, and I always felt like… It’s got the label “imposter syndrome” these days. At that time, I didn’t really know what it was, but I never really felt like I knew what I was doing and everybody else did; because everybody else, must’ve learnt it at university. Looking at, it now, the thing that I really want to tell my younger self is that – actually- nobody else really knew either because the subject itself was evolving. C hadn’t been standardised at that point. So nobody knew what it was. What do you think you would tell your younger self? The mathematician who’s just starting to teach people Java in your friend’s company? [Adam] I would say…I think there are fundamental parts of this, which is probably -maybe I’m generalizing too much here- but are kind of true for all of the developers that I know. And that is, curiosity. Curiosity is the most important part of being a developer. Technology moves so quickly that you can’t just sit there and be like “I’m only going to do exactly what’s being done for the last 10 years”. You’ve always got to learn something new. Maybe it’s a new language, maybe it’s a new framework. Maybe it’s a new area in which the technology is operating, maybe it’s a new platform, whether it’s cloud or mobile or whatever it is. But it doesn’t matter. There’s no sitting still. No technology is sitting still. If you’re a curious person, if you’re interested in looking and learning about something new, then this is great. This is a great thing to be doing. And that was, that was me in a nutshell. I was very restless in academia. I was always looking for something interesting and I basically got that first job because I self-taught me on how to build a website and pull and put myself though all the database stuff and I actually ran a fantasy football website off the math department computers for like three years without anybody knowing. That’s what got me the interview with my friend’s company. He saw all the things that I built and that I was self-taught and that gave him the confidence that I could not just be an academic but somebody that works in technology. So I really think that thinking about what is the next thing you want to learn, what are you curious about, what are the opportunities to develop and extend yourself, is really the driving force for a lot of developers. And I’ve been very fortunate at Amazon. It’s a great place to do exactly that. Not only because the platform – AWS is very, very broad and covers a whole spectrum of services and areas. We’ve got over 140 services that cover IoT, robotics, machine learning, data analytics, mobile, about anything you can think of. But it’s also the culture here. Amazon really invests and thinks about people that have this curiosity element to them. And there’s a collection of leadership principles Amazon espouses. One of them is the “learn and be curious” leadership principle where we expect the people that work at Amazon to take the time to go dive deeply into new areas and work out what’s happening now, understand it and how it applies to what they’re working on. It’s a driving force for the people that work at the company. I would say curiosity is the one thing I would keep reinforcing to my younger self. [Jo] That’s a good one. And I should have told myself that too actually. I shouldn’t feel guilty about sitting in the library learning C – that it was definitely the right thing to be doing. So, I think I mentioned imposter syndrome, which I see as a big challenge that I’ve had to overcome. What would you say is a challenge that you’ve had? I mean, the book, when we wrote it, it was all about challenge. It was all about the journey in developer marketing. We ask every author in the book to describe not just the things that went right, but the things that went wrong, what they learned from them and pass on, basically, everything that is their primary experience. What would you say has been your biggest challenge? What have you learned from that? [Adam] So I’d say, overall, the biggest challenge I’ve faced over the multiple places I’ve worked is getting businesspeople to understand the value of talking to developers. For those of us that have done software development or understand or believe that software is central to the innovation and the capability of today’s modern businesses, it would seem self-evident that developers are on this critical path of business success. For us it’s the obvious thing to do. But quite often, you wind up in situations where people are not aware -it’s not that they don’t understand; situations where business leaders are like “I’ve got to make the number”, “I’ve got to hit this target as a sales thing”, “there’s a Wall Str expectation”, “there’s something we need to deliver”. When you say “well, I want to go talk to developers” they respond with “well, what does that developer worth to me? What does that mean to me? That doesn’t help me. Why aren’t you helping me achieve some other kind of goals? They’re not buying anything”. I’ve been fortunate in some places such as Amazon Web Services and Spring Source where they totally understood that developers are a critical factor. Or other places I’ve worked where like “yeah, yeah, do your developer marketing thing, just help me get to my sales number and I won’t bother you”. The biggest challenge has always been saying “No. You really need to understand that talking to developers is a critical part of what means business success. A developer actually means something to you and might even mean that the solution you just sold your customer is actually going to get implemented in the right way and become successful for the customer or it’s actually going to result in more usage of your underlying product because developers actually operate at scale”. Developers don’t just say “Hey I’m using this one thing.” they say “All right, I’ve made this thing work. Now let’s use it a thousand times.”. Potentially, by engaging with developers, you actually open up your ecosystem to expose yourself to new customers and new opportunities that you wouldn’t have before by adding a new API or adding a new interface to whatever it was you’ve created. Helping the business understand the value of developers has been the biggest thing that I have faced again and again in lots of places. Even in places as forward-thinking as AWS or Spring Source, it’s still a very reasonable question to ask “what does the next developer mean on this platform? What is their value? What do they actually mean to us?” So understanding developer value has been sort of the crux of my introspection or the biggest lesson learned I’ve had in the years I’ve been doing developer marketing. I’m in a really concrete understanding of what that value means to the business and is the key way to talk to οther members of the business team and the key way to talk to leadership about how to fund programs that really engage with developers. “Helping the business understand the value of developers has been the biggest thing that I have faced again and again in lots of places.” [Jo] I see. Yeah. I was writing a blog post last week about developer relations and developer marketing and one of the things I was trying to write about was how you measure success. Certainly, with developer relations, that’s a very difficult one because you’re talking about building connections. It’s not a particularly measurable activity. Do you have metrics? What is your view or on KPIs and metrics so that you can talk to the business about the value of individuals or groups of developers? [Adam] I think it’s really important for people in developer relations and developer marketing, not to the religious or overzealous about “this is the right thing to do because it’s the right thing to do and therefore you should listen” to come with a business sensibility. For most organizations, you’re a cost centre. You’re costing the company money either by your salary or by the program you’re executing or something, you are costing the company money. So, you should understand that the things you do have to deliver a commensurate value back. The KPI and the value depends upon how your company is structured. What does your company sell? What does your company do? What is it that matters? For example, if you’re selling packaged software, then what does one developer mean? Are they a buyer of that software? Are they an implementer of that software? Are they somebody that can access and make the software successful so you can get more revenue for the customer or sell more licenses? Here’s a great example of this. Like I said, developer relations has been around for a while. It wasn’t done by very many companies, but when I was at BEA, I remember chatting with some people at Microsoft and they were very clear that developers are important because they produced more people consuming Windows licenses and they actually had a model at the time that said one developer produced the sale of seven new Windows licenses because the people consuming the software created and that put a characteristic value around that developer, that they can then go take to the business. In the form of “we know how much seven new licenses of Windows software is to us. Therefore, going and grabbing a developer or engaging with the developer, we know what the value is for that developer.”. Similarly, when I worked at Spring Source, you know, Spring Source is an open source tool, right? It was used freely by millions of Java developers around the world. So each individual developer wasn’t actually that valuable to the business because the business wasn’t selling Spring. The business was actually selling an industrial-strength version of Tomcat for enterprises to use. It was much cheaper than Web Logic Server or Websphere. So, the value of the developer was very small. But the value of the developer audience aggregate was the path through which we could go sell Tomcat because by using Spring, it made Tomcat equivalent to these bold-fledge JTV containers. All we needed was Tomcat. You didn’t need all the heavyweight application server. So understanding what the developer meant to that business was very different than the Microsoft case. And then if you look at things like AWS, each individual developer winds up creating an account on AWS. There’s a generous free tier, but it expires after a year. So at a certain point, your credit card is going to get charged for the things you’re using with AWS. So AWS understands what your charging characteristics are, we understand what the average spend is on the account, we understand what services you’re using. So it’s very much an as-a-service model where we can define our customer lifetime value for that developer. The question about what a developer is worth can be answered much more empirically than we could have done in either the Spring Source example and the Microsoft example, right? You know, it depends on what business you’re working for. Do you understand what is the key performance indicator? What is the critical measure that you’re interested in? For me, you’ve got to be able to answer for the business “What is the next incremental developer worth to the business?” If you can answer that question with some kind of accuracy or some kind of real knowledge, then you can use that as your argument to the board or the CEO or your leadership and say “Hey, this is what the developers are worth. This is what they do. This is what they deliver to the business. Therefore, in order to gain more of these developers, you should fund me at this rate. You should give me these resources to accomplish that task.” You can use the same argument about writing documentation or running events or doing webinars. They all have something, some incremental value that changes the way the developers engage. If you know what the value of the developer is to your business, then you can use that to work out what you’re going to be doing to change those different channels or invest in those different channels. For me, that’s not much of a KPI because I’ve given you a “depends” answer, but it really depends on who your employer is. It depends on what your businesses is. You’ve got to be able to work a lot of those things out. There’s not one answer in all of developer relations. “If you know what the value of the developer is to your business, then you can use that to work out what you’re going to be doing to change those different channels or invest in those different channels.” [Jo] That’s right. And it seems it’s very much about the business recognizing that and recognizing the value of developers. [Adam] Yeah, which is why I feel like I’ve had the same argument at every company I’ve been at, which is: developers are important and this is why. And this is why. That’s the conversation you have to have. If you’re in a situation where, the leadership doesn’t believe that, then you’re going to have a hard road. You’ve got to do a really good job of convincing them why developers really matter, and it depends upon what the product is. You know, each developer is very, very different. Each individual developer is very different. I see a lot of businesses these days are in this as-a-service model, right? So whether it’s a software-as-a-service or platform-as-a-service or infrastructure-as-a-service, and you actually think the, as-a-service model is a lot easier to compute developer value because you do have this customer lifetime value computation you can do, on trailing spend over multiple months. So those things are very, very easy to start thinking in that direction. But there’s still plenty of companies that sell packaged solutions or solutions to mobile, libraries that are delivered on mobile devices that just don’t look like that. Or it could be companies that have a partner ecosystem and so, they’re looking at developer relations to build integration points, then allow other partners to integrate with them. And the model there is completely different than thinking about it as an as-a-service model. There’s a lot of different challenges in developer marketing and I wouldn’t pretend to understand, you know, each market’s individual challenges. I would say “what is your business?” then let’s sit down and talk about your business and work out what does a developer mean to your business and then we can start talking about what your KPIs are, what things really matter to your business and how you demonstrate the value you’re providing. [Jo] That’s really interesting. Yes, thank you. I think you’re going to have a queue of people wanting to talk to you about that. [Adam] Well, you got to understand your business. Sometimes, that’s kind of our issue too. [Jo] Yeah, absolutely. Let’s move on to talk briefly about the book “Developer Marketing: The Essential Guide”, it’s been a number of months since that was published at the Future Developer Summit 2018. It’s a book that pulls together a huge range of experience from a number of people that work at different companies, representing either the company or just talking more about their personal experience. We’ve had a range of contributors come on the podcast, like you. You worked on the foreword for the book. [Adam] Yeah, yeah, that’s right. So actually I was at the Future Developer Summit in 2017. When Andreas, Nicholas and I were talking after the event, having a glass of wine. This is the first time I’d see all these real leaders across all these different companies that are brought together to talk about developer marketing. The idea of the book kind of got hatched out of that and Nicholas was super engaged and super excited about doing it and really drove the creation of that. And so I was like happy to help out in any kind of way I could. Unfortunately, I didn’t have the bandwidth to contribute to a chapter, but I was happy to write the foreword because I felt like the foreword sort of answered what I’ve been already talking about: the biggest challenge, which is how one goes to convince people that developers are the most important critical audience for the 21st century business. That’s something I believe. I believe technology is the driver of business innovation, first of all. So that can evolve. The masters of that technology are the developers not somebody inside the business. Third of all, the way that technology consumption has changed in the last 10 years, means the power of technology decision-making has shifted out of the IT department into active development. It’s because people, companies expect more out of their technology. They expect the technology to be more responsive to the business. And that same response is from customers saying “hey, why can’t I do this with my mobile phone? Why can’t this happen more quickly? Why can’t I just do this while I’m sitting on the train instead of by having to log on somewhere else?”. Consumers are expecting more agility out of their companies, out of the companies they do business with, out of the governments. They do, have responsibility for fast digital experience. The companies that don’t understand that, are not going to survive, they’re not going to become successful. The companies that do understand that, are going to realize very quickly that developers are the critical part here, and that’s why moving quickly and helping developers understand what your product or your technology is, and using developers as your competitive difference-maker, is so incredibly important. That’s one of the things I wanted to reinforce in the foreword: developers are at this point, because of the way the business has changed in the last 15 or 20 years and the power is in the hands of the developers. Understanding how to communicate with them and having a strategy for being able to communicate with them, better become an integral part of every business strategy. Because if they don’t, they’re going to lose out to the ones that do understand that element. For me, that was why I was super interested in writing the foreword; because it feels like it’s commensurate with the argument I’ve been making for the last 15 years about convincing business leaders about why developers matter. Basically, if you don’t believe that premise, then the rest of the book doesn’t mean much to you. You’ve got to believe that developers matter, in order for you to think there’s value in developer marketing. “Developers are the critical part here, and that’s why moving quickly and helping developers understand what your product or your technology is and using developers as your competitive difference-maker, is so incredibly important.” [Jo] Yes, and see the value of the book. As I edited the book, I saw this common theme come through every chapter and it seems like the commoditization of development, it’s become something that everybody expects. As you say, consumers have these expectations and developers have to follow through on that. The book has done remarkably well. We’ve gotten to 10 five star reviews on Amazon you’ll be pleased to hear. I think a lot of people are picking up on that, we’ve had a lot of feedback. And that’s why we’re having another edition with more chapters which echo a very similar theme. I want us to move on because we’ve been talking a lot about the business side of it and developers and developer communities is something that we’ve been talking a lot about on the podcast. I want to talk a little bit about diversity. How we can encourage people of different identities, how we can encourage diversity in a developer community. I wondered if you had any thoughts or if you’ve worked in any particular area to cover this? [Adam] I think there are two parts to this that are really incredibly important. One is that diversity actually really increases the success of your business, whether it’s diverse viewpoints or diverse perspectives or diverse backgrounds or representation of the diversity of your customer base. It’s incredibly important in making sure that you’re building things for all people and anytime you have homogeneity you can totally miss on those opportunities. Actually having diverse representation inside your business, is good for your business, first of all. Secondly, technology has really suffered from the lack of diversity and I think it’s super important that we acknowledge that and try to address it. There are lots of things that Amazon does, where we’re trying to move in this direction. “Diversity actually really increases the success of your business, whether it’s diverse viewpoints or diverse perspectives or diverse backgrounds or representation of the diversity of your customer base.” At AWS in particular, we try to engage with diverse groups. We’ve sponsored multiple diverse nonprofit organizations over the last several years. We run diverse workshops inside the business. We engage very closely with various different programs. Externally, we run a diverse speakers bureau where we can identify excellent speakers from diverse backgrounds around the world. There’s a lot of parts where we think about that, but the most important part for me and somebody who runs an evangelism team is to try to think about how do we get those diverse voices public and visible to the people that are aspiring or interested or looking to join in technology. We want to make sure that it’s okay and very, very clear that’s fantastic to be from a diverse background. And there are two parts of that. One, we’ve got to find the people that are willing to be those champions and support them. If you are public and talking about these issues, the environment can get very, very taunting very, very quickly and we should have very strong stones, everybody in technology, so we’ve very low tolerance for that kind of behaviour. The brogrammer, the bro Programmer mentality, it’s just not okay. You know, I see this with people that I work with that are from diverse backgrounds that are in public-facing roles and I see sort of the backchannel and the DM messages that they receive from certain people with this stuff. This behaviour is just not okay and it’s from a lot of people who are across a broad technology spectrum. And the more we can acknowledge that that is not tolerated, the better off we’ll be. So, I want to encourage people to be very vocal and visible from diverse backgrounds and talk about their successes, but they should also talk about what their challenges are and we should surface those and have no tolerance for any other sorts of bad behaviour that I see too commonly in a technical environment. [Jo] I totally agree, I think that’s a very important stunt. Another interesting thing I was reading a couple of days ago, it was about how you can encourage the employees to participate. So a very good example is that working women have got their time set aside to work, but the rest of their time is potentially taken up with family, childcare, whatever. They may have less time and opportunity to participate, say in open source or hackathons than other people who don’t have the additional second or third shift that often falls to women. So it looks like it needs to be part of the time that they devote to their work, that they can offer a slice of their time to an open source community for example, while they’re actually on the job. Is that, is that something that Amazon does? Because obviously, Google has their 20%. Does Amazon have any kind of policies for encouraging open source participation just to get your diverse workforce out there? [Adam] We’re all active participants in open source and lots of different areas. I don’t think it’s necessarily rooted in diversity. We actually think open source as an incredibly important part of the technical ecosystem. It’s something that our customers really care about and we think is an important place where innovation occurs and you know, new ideas happen and it’s a way to build really collaborative environments where we work with other people. You can go to AWS at aws.amazon.com/opensource and actually, there’s a whole list of the ways that we contribute and participate in the open source community, whether it’s foundation membership, actual code contributions, open source projects that we lead. There are lots of different areas where open source matters and we’re active and actively engaged with them. This may be an assistance for diversity, but that’s not its primary purpose. I think the more important thing for diversity is that you want to make sure the internal culture of the company has the tools and mechanisms that make it very, very clear within the workforce that diverse interests, viewpoints and backgrounds are all completely the norm and anticipated at the company. I will say that AWS, it’s become a really great place for me as a parent and a family member. It’s a very understanding place when it comes to work-life balance. It’s a very understanding place when there’s a lot of work to be done, things need to be done. It’s very understanding when it comes to making sure that there’s enough appropriate representation across staff in various different roles, whether it’s gender or racial diversity. There are lots of different programs involved in Amazon that make it a great place to work whatever your background is and it’s something that we continue to focus on. [Jo] Yes, that sounds great. I’ll definitely be looking for a few hackathons to come. [Adam] Well there are lots of other challenges about hackathons. But there’s a collection of programs that we run. In AWS in particular, if you look at our events we’ve got a Code of Conduct Policy that’s very, very clear for all of our in-person events. We’ve got programs or large scale events, white summits and reinvent which is a cost event, but we have mechanisms for encouraging different diverse groups for attendance to those. We have programs at reinvent as well to help nursing mothers for example. So there are pieces of all sorts of programmatic support that goes into our marketing for technical communities. We’re trying to make an effort. I’m sure we can do better and I’d love to hear ways we can do better. We’re trying to make the effort to make it clear that any diverse background is accepted, welcome and encouraged to attend AWS events. [Jo] Fantastic. Well, thank you very much, Adam. It’s been really interesting to talk to you. You’re clearly really passionate about developers and developer marketing and we really appreciated your contribution to the book, as well as kicking it off in 2017. Thank you and thank you to the listeners for listening to Under the Hood of Developer Marketing, the podcast devoted to developer marketing and relations. If you want to listen to more episodes. You could subscribe at developermarketingpodcast.com or follow us on Twitter at @SlashdataHQ for regular updates. #developermarketing #developerrelations #devrel #transcript

The data from our latest Developer Economics survey give all the answers in the recently published State of the Developer Nation Q2 2019 report, which – as always-  is now available for free download! What’s new in the dev world? The report highlights the latest insights from the developer ecosystem, based on responses from 19,000+ software developers of all profiles: professionals, hobbyists and students, working across all major areas: mobile, web, desktop, cloud, IoT, AR/VR, games, machine learning & data science. It focuses on 6 themes: (NEW) Developer psychographics: how do developers perceive themselves? 37% see themselves as introverts and only 4% describe themselves as being able to make a killer cocktail. Programming language communities: Is JavaScript getting comfortable on its throne? Updated estimates of the number of active software developers using each of the major programming languages Emerging Technologies: What turns interest into adoption? Game Streaming: Developing for live-streaming. Are we there yet? Third-party platforms and ecosystems: App developers are unlikely to work solely on one third party platform. Mobile cross-platforms frameworks: Mobile development has matured enough to embrace cross-platform frameworks, allowing building apps that can run on multiple platforms. The full report is available for free download at sdata.me/fr_SoN17 Software developers who want to have their voice heard in the next State of Developer Nation report, can join our next survey that starts on Nov. 22nd, 2019. All survey respondents enter a draw to win amazing prizes and Developer Economics donates $0.10 for every complete response to the Rasberry Pi Foundation. #developerpsychographics #developers #extroverts #introverts

(edited by Stathis Georgakopoulos) A look back on the 2019 event. On September 24 & 25 we opened the doors to the fourth edition of the Future Developer Summit. With Diversity (openness & inclusion) as the overlying theme, we welcomed 60 participants from 30 companies across industries and had prepared for the 1,5 days full of keynotes, two fireside chats, 12 lightning talks and two workshops, including some fun, interactive games. Experience sharing is a must in the Future Developer Summit and we strongly believe in learning from each other’s mistakes and real career experiences. Let’s see how that went. Day 1 Open source as a drive for decision-making Willie Tejada (VP and GM of Developer Relations and a Chief Developer Advocate, IBM) kicked off the Summit with his keynote and what better way to do it than talk about open enterprises and how companies benefit from using open-source software. He also mentioned IBM’s “Call for code” initiative that addresses climate change and natural disasters. Inclusion in your DevRel team Remaining close to openness, Maru Ahues Bouza (Director of Developer Relations and Advocate for Diversity and Inclusion, Google) followed the keynote with a fireside chat. Maru had her story to share: – When Maru started working in DevRel, she was the only woman and the only Latina (she is from Venezuela) in a team of 40 ; – Today, in a team of 100, more than 25% are women and people of colour ; – Specific diversity and inclusion goals have been set in hiring ; – When it comes to strategic hires for building her DevRel team, she first hired developer advocates (called them “engineers with social skills”), then a program manager who created a programs team, followed by the operations team, and the strategy team. What does “diversity” mean to Maru? She wants everyone in her team to feel included and to feel that their contributions matter: “I don’t think you can do diversity well if you don’t focus on inclusion. Hiring is important but making sure everyone in your teams feel included is critical. It is super important to set your people up for success.” How do you build a developer community from scratch? That’s the question Diego Moreira (Director, Products & Partnerships, Facebook) took on answering with tips to build a 200k+ developer community from scratch. He pointed at educating, helping the innovation process, and bringing people across the globe together as the three main components of Facebook’s strategy. He also shared Facebook’s initiative in Sudan.  How can diversity help your team? “Diverse developer relations teams serve the needs of diverse developer communities around the world” said Lori Fraleigh (Senior Director of Developer Relations, Samsung). Here are some more hot takes from her speech: – Developers in certain regions (Japan, China) prefer materials to be translated into local languages whereas in other regions (Germany) developers are fine with English ; – DevRel teams need to be sensitive to local and cultural norms, even when planning the start and end times of meetings ; – Failing is learning. Lori also shared her personal failure story about how she made it to TechCrunch, with a funny twist. While at Motorola, her name was attached to an article referring at the upcoming Motorola device and mentioning it would not be reflashable. Developers were not kind in their feedback, but as she said “failures make for good stories down the road” ; – Ensuring diversity within an organization takes constant work. Different people and cultures have different expectations, and you should never underestimate a minority faction. Building an inclusive developer community Leandro Margulis (VP & GM of Developer Relations, TomTom) was all about offering real tips we can start using as soon as possible: – In the sign-up form, instead of asking for first and last name, just ask for full name and do some smart processing in the background to figure it out ; – Localization is key ; – When possible, use inclusive maps with place names in local languages ; – “Your developer program should cater to real persons and people – not to the typical, and wrong, stereotype of a developer one gets from the movies” Leandro said. DevRel team, assemble! What have your failures and successes taught you about building four developer relations teams? That was one for Tim Falls (Director of Community, DigitalOcean). He stated that “systemic organizational issues are fixable – if they are acknowledged as broken” and shared a story about revising a team compensation structure that was unfair and misguided. Inclusion is always key, so he offered tips and lessons learned from working with a team member with mental illness: acknowledge and honor the need for accommodations related to their mental health, make sure HR is in the loop and seek help and feedback from mental health experts when you need, be open and understanding and always try to learn as much as you can so you can meet the needs of your team members. “Some teams are too good to stay together. You need to foster an environment that nurtures individual expansion and attracts talented people to achieve healthy retention” he said about having such an environment that helps people excel and grow, even if they leave to join another company or start their own. The first day was wrapped up in a relaxed atmosphere with dinner, wine, and a Silicon Valley sunset. Day 2 How and why to engage Millennial developers Diane Prescott (General Manager of Business Planning, Microsoft) kicked off day 2 of the Future Developer Summit with a sociocultural approach towards millennial developers. – Millennials (currently 23-38 year-olds) form 33%+ of the US workforce and 50% of the global workforce ; – They are more likely to work in organizations that have been operating for less than 10 years; – They are more likely to be primary decision-makers for cloud-only apps ; – They leverage the community and their personal networks, significantly more than earlier generations ; – “It is best to meet customers and developers where they are, with all their unique preferences and attitudes and developer programs need to take this into account.” Diane said and emphasized that it is equally important to look not only at your customers but also learn from your non-customers. What does “relations” in developer relations mean? The second fireside chat of the event was led by Quinton Wall (Senior Director of Developer Marketing, Twilio) who took over in placing “relations” in “developer relations”. – “Developers don’t necessarily associate themselves with a company, but rather with a technology and a community – even if developers change their employer, they remain loyal to the technologies they are familiar with” ; – When it comes to diversity and inclusion, he made a point of looking beyond university graduates and has made hires directly from hackathons – people who learned to code without a university degree ;  – While it is important to grow your developer community, it is equally important to look at empowerment and activation: how to make your developers successful. It is paramount to understand what your developers are doing and how they are using your platform. They might even use it for completely different purposes than what you built it for. The community manager and others should constantly monitor developer feedback and pass it on to product teams ; – People talk to people, not companies. First focus on hiring strong developer advocates – people advocating FOR the developer inside the company – and then community managers developers can talk to ; Developer trends That was one for us. As the analyst of the developer economy, we /Data, through our data scientist Michael Carraz, presented the latest on developer trends: – Who developers are ; – What they buy ; – Where they are going ; – What are the top development areas ; – What lead to the success of Kubernetes ; – Which are the developer persona characteristics ; – What are the upcoming trends in development ; – What are the features each successful developer program should offer.  Workshop time: How to build a developer program from scratch with $2 million. After being updated in all industry trends, it was time for our first interactive workshop. Time to put words into action – or even more precisely, put our money where our mouth is. We asked the participants to spend a virtual budget of $2M towards building from scratch a developer program within 12 months. They needed to prioritize and decide where they would invest in people and activities. Teams came up with various scenarios based on their assumptions and constraints.  Time to talk (developer) personas We’ve talked about developer personas in the past. We even run webinars on it. Luke Kilpatrick (Senior Manager, Developer Marketing, Nutanix) discussed the four types of developers they take into consideration when it comes to segmentation: – Marketplace developers (they build apps and sell them) ; – API consumers (the integrators) ; – Tools (developers with purchase power) ; and  – Developer Required (you need developers to sell your product). He also discussed developer program success KPIs and gave us all the early hires that are needed in Developer Marketing: content writer, evangelist, researcher, community manager, support engineer. Luke also offered a few quick tips on how to build a developer program from scratch, from the chapter he wrote for our new book “ Developer Marketing + Relations: The Essential Guide  .” Overcoming corporate hurdles Developer program leaders often ask how we can help them get the corporate buy-in. Francisco Romero (Head of Open Innovation Programs, Amadeus) addressed this and gave us a peek on how to overcome corporate hurdles to build a developer program. Changing the mindset of top management is a series of smaller achievements including: setting goals that are aligned with the company’s goals and bottom line, creating internal alliances and partnerships on a 1-2-1 level, building the support at different organisational levels, communicating the risks of no action, managing risks and expectations by preparing beforehand to have the means to deliver what is promised.  Lightning talks, lightning tips These are the hottest tips from the lightning talks of day 2: – To create successful developer events, you need to address all areas: audience, branding, content, location, logistics, staff, and marketing. | Sidney Maestre (Head of Developer Evangelism, Xero) ; – Diversity doesn’t come easy, you need to implement various diversity initiatives to really add gender diversity to the engineering teams. | Sara Chipps (Director of Public Q&A, StackOverflow) ; – Within your developer marketing team, you really need to manage expectations, build real relationships, and win as a team | Nick Schwartz (Sr. Director, Financial Technology Developer Engagement, Banco Santander) ; – At Cisco, the ideal is to create a diverse DevNet community where software meets hardware and software developers meet network engineers. At the same time, if you want to build great API experiences, you need to listen to developer feedback and create a customized API style guide along with an internal API community and tools. Amanda Whaley (Sr Director of Developer Experience, Cisco) ; – Being customer-obsessed boosted our NPS by +20% in just one year. You need customized API strategy for each developer type, you need to earn the right to invest in future value, and ecosystem obsession is a team sport. Acknowledgement, action, and transparency are in the secret sauce for customer satisfaction. | Cassie Divine (Senior Vice President, QuickBooks Online Platform, Intuit) & Jarred Keneally (Director of Developer Relations, Intuit) ; – The evolution of a developer platform has these stages: early days, crossing the chasm, growth and maturity. When moving from the early days to crossing the chasm, users expect easy-to-use apps from your program and developers expect easy-to-use tools and infrastructure. When moving from crossing the chasm to growth and maturity, users expect rich quality experiences and developers expect to be able to run a successful business. The developer relations role sits in the intersection of technology and people. | Ellie Powers (Director of Product, Platform | Slack). The first 5 people in your DevRel team. Back to work. For our second workshop, participants had to staff their DevRel team with its first 5 people. Loads of combinations were presented, but most included: community manager, partner engineer, developer marketing manager, tech writer, developer advocate, support engineer, and partnerships manager.   To conclude Brad Meiseles (Senior Director of Engineering at VMware) delivered the closing keynote. The focus was on the Kubernetes community best practices and how it has changed and is still changing the way we work. Kubernetes is now one of the top open-source projects ever and it took 5 years to reach to the top. The reason behind its success is very simple: its community of kindness, open to all, created by developers for developers. Nothing makes diversity sound better than a live Latin jazz band to accompany the closing dinner. In retrospect, the Future Developer Summit 2019 had a lot to offer to the Developer Marketing and Relations world, more to those who attended it. We hope to see all of you at our next Future Developer Summit where the theme will be no other than Open Source. Stay tuned for the event date! #devmarketing #devrel #developermarketing #futuredevelopersummit #developerrelations

Listen to the audio episode. [Intro] Hello and welcome to “Under the Hood of Developer Marketing”, a podcast from SlashData. This is a podcast to come to for best practices and insights from the developer marketing world. In each episode we meet a different guest each with a background in technology. We’ll share their experiences, success stories and lessons learned. We are /Data and our mission is to help the world understand developers. Stay tuned for more episodes by signing up at www.developermarketingpodcast.com .  [Jo] Hello and welcome to “Under the Hood of Developer Marketing”, a podcast from SlashData. I’m Jo Stichbury, one of the senior analysts in the team and today I’m joined by Katherine Miller. Katherine and I worked on a book together recently, Developer marketing: The Essential Guide . We published the book in September last year and it aims to be the de facto text on the up and coming field of marketing to software and hardware developers. I have a fair amount of experience in this field as I’ve worked as a developer and in marketing for Nokia, Sony, Ericsson, Symbian, and in various publishing fields. More recently, I’ve moved into technical writing, working on documentation for developers and those that want to attract them. But Kattie, tell me about yourself. What’s your bio and background? [Katherine] Thank you so much Jo for having me on the podcast. I am currently the lead of the events team within the Cloud developer relations organisation at Google. I’m going on about 13 and a half years now at Google and have worn many hats, across our ads and agency and developer marketing and developer relations businesses. Today I am here on behalf of myself and I’ll be speaking about my experiences that I’ve gained through my years at Google as well as in my other experiences. But prior to Google, I actually had a career in higher education. I ran the admissions office at a dental school in Boston. What I really like to think is the common thread that runs through all of the work that I’ve done, whether it be developer relations and marketing, ads, customer service or convincing people to go to dental school; It’s all about building programs and communication experiences that help people get the information that they need to make decisions and be successful. Whether that’s where they want to become dentists or what technology they want to use to build their applications. [Jo] Okay. Wow. That is quite a journey though, isn’t it? Did you think that you’d end up in this area? How do you think your younger self would see your current role? [Katherine] I reflect on that a lot particularly, and I’m going to age myself now. I’m coming up on my 20th reunion for university and I reflect back on what I said I wanted to do when I graduated and, amusingly, I would have jokingly said I wanted to be the education secretary for President Hillary Clinton and run the Boston marathon. So, I guess I had some foresight back in the late nineties. Fortunately I have completed the Boston Marathon, so that’s that. But my initial career did take me down the path of education and that’s actually what brought me out to California in the first place. Working in the tech sphere in any capacity would have been so far removed from what I was doing in the late nineties. In fact, not only did much of this technology not even exist for us to comprehend, but also when I even look at the journey that I’ve had over the last 13 and a half years, the vast majority of the technology that we’re talking about and that we’re marketing didn’t even exist at the time that I started at Google 13 and a half years ago. [Jo] So that is quite the journey. So, within Google, what would you say has been your biggest challenge in your roles there? [Katherine] That’s an interesting question and I don’t even know if I would say that this is something specific to Google or is just something specific to tech, which is, I think twofold. I think the first is how as a brand and a product suite, we can really think about not just differentiating offerings, but really thinking about how to do so in a way that really is thoughtful and sensitive to the user. So, really putting the user at the center in the heart of everything, and helping them really understand the benefits of why to pay attention to what we’re saying in the first place. So, really that user centric journey. And then, I think the second is – again, more of an observation across the broader tech sphere and not specific to my work at Google – how we really think about bringing diversity and inclusive experiences into the products that we build, the events that we create, the marketing experiences that we put forward out into the world. I think that those are two really interesting challenges when I just reflect on the 15 years I’ve spent in Silicon Valley as a whole. [Jo] That’s really interesting. I’ve actually just been writing about women in tech. When we’re talking about diversity, it’s one that I think a lot of people would immediately think of. Though obviously not the only one. I was quite surprised to see that there was about one in 10 developers at the moment women. I thought we go beyond that now. And that it was more parity, but it seems not. That’s a global figure. I’m sure things are a bit different in your part of the world. Would you just say so or, or is 1 in 10 still kind of a common statistic? [Katherine] Observing the events that my team has run and the events that I’ve been able to attend and participate in, I think it varies quite considerably across the platform and across the geographic location. A lot of what we see, and this is again observational, and observe in tech is really related to what we see and observe in terms of diversity in the workforce as a whole within those particular regions and cultures. [Jo] Yes. I think that must be very true. Let’s go back to the challenges that you’ve experienced. Something that we were very strong about when we wrote the book was that we didn’t just want the glitz, we wanted the mistakes, we wanted the secrets of how you overcome the obstacles. What would you say is your biggest mistake? And what did you learn from it? [Katherine] That’s such a good question. I have 13 and a half years to dig into. And even beyond that, if I think about early stage career. I think the biggest mistake is… And this applies across the board and I can’t think of necessarily one specific instance. I’m two and a half weeks out from a major event, so I’m probably being very self critical of all of the things I haven’t done in preparation for that event. I would say it’s that, I haven’t taken the extra five to 10 minutes to ask the questions and to listen and to really understand the audience and the stakeholders when I wanted to do that. In that true tech mindset, run fast, fail fast, act and ask for forgiveness. And every one of those instances, taking that extra bit of time to pause and say, “what are we really trying to accomplish here? Who are the people that we’re trying to reach? What are the goals of this? Is this the best strategy? What are the trade offs of what we do?” And I think in those moments we’re in an effort to just keep pushing, pushing, pushing, and to meet deadlines, sometimes there are moments in there where maybe we should have paused. Maybe it would have been a deadline slip, but in the end it would have been the right thing for the internal stakeholders and for the event attendees. [Jo] Yeah. I see exactly what you mean. I think as a technical writer I’m guilty of much the same in that. Sometimes in my rush to get down what I want to write, I stop thinking about what the problem is that I’m trying to solve for the reader or even who the reader should or would be. And certainly in, you know, in my past career as a tech writer, we Symbian, perhaps I was always solving the wrong problems. We were writing to the converted rather than looking at the external developers and trying to pull more people in. Because of course Apple came along and Google with your Android devices and the Symbian platform just wasn’t really ready for third party developers in the same way. And I was the one that was writing the content for a lot of developers at the time. So absolutely, the problem that other people are trying to solve has got to be right at the top of the list, isn’t it? It’s not always the problem you’re trying to solve, unfortunately. [Katherine] I love the way that you reflected on that because it really made me reflect on the experience of collaborating on the book and on the chapter where it was a lot of me getting down my ideas and experiences and you all were really pushing me to think about the readers and all of those different angles. And so, in many ways that’s what made the experience of working on the chapter so positive. [Jo] Oh Great. I’m glad you enjoyed working on it because your chapter was so much fun to review because I learned so much about, well why don’t you tell us, what did you choose to talk about in your chapter? [Katherine] So my chapter was about producing events for developers. In my time at Google thus far – and that is really where I have built up the muscle around developer events – even though again, the perspective is my own. I have worked on everything, from small meetups up to large tent pole marquee events. And so, it was an incredible opportunity to share the wisdom, the strengths, and the failings of the work that I’ve done to hopefully open people’s eyes and minds to what developer events truly can be. Oftentimes, people think about events as very difficult to measure. Very difficult to measure. They can be expensive. What’s the ROI out of them? And I really truly believe they’re such an incredible vehicle for delivering other programs, other initiatives, other campaigns, and in a really human way. I’ve been really lucky that over the last 13 and a half years, events keep coming to the top of what I’m doing within my particular roles. And it’s just a real passion. It’s something that I really believe in, in terms of it being an effective mechanism of developer marketing. [Jo] Absolutely. So, this week I think is GDC in San Francisco. I’ve got very fond memories of that event. It’s one of my favorites and also WWDC at the Moscone Center. Those are two really iconic events I think, in the developer calendar. But what do you think makes them so attractive? [Katherine] Such an excellent question. When I reflect on events like that, when I reflect on events like Google IO, even some of the more emerging ones that you have, Facebook has F8, Amazon and Microsoft have their events, the ones that have been done really effectively are the ones that really understand the different audiences and craft experiences and content that match the needs of those audiences. So that, you know, as an attendee, whether you’re there as press, whether you’re there as an analyst, whether you’re there as a partner, whether you’re there as a practitioner, there’s a place for you at the event and you know how to find it. And you feel, when you walk away from the event, from an ROI perspective that you have gotten out of the event that what you’re looking for. And I think for those ones that are done really well, people are going looking for deep technical content. They are looking to connect with one another. They’re looking to connect with the experts. They’re looking for that balance of wow in amazement because oftentimes the attendees are also fans of the consumer brands, as well as the developer brand. And so, just that sense of being respected as brand ambassadors on both the consumer and the developer side and that they’re able to walk away and say, “I was inspired, I was shown what was possible, but that I also now have new information to do my job better. And I’ve made really personal, meaningful connections to help me do my job better, to help me think about my next step in my career, to feel supported, to feel recognised”. And I think all of those iconic events understand the different audiences. They understand the type of content and experience for them. And when you go, you get out of it what they intend for you to get out of it. [Jo] I think that’s so true. I think, you said in the book that you should come away only understanding 2/3 of the technical content if you’re a developer and it gets you fired up to learn more. And I think, certainly with WWC DC you would by far exceed that in terms of not understanding things. I definitely walked away with a very long reading list. I’m not so sure about connections for everybody though. I think there’s quite a perspective that developers are introverted and certainly I find in my experience I’m definitely an introvert and I don’t always find it easy to make connections at developer events because I’m in my own little bubble and I don’t really want to talk to people and it’s a bit embarrassing and I’m British and all this. How do you go about bringing people together so that they do actually interact and engage with one another or engage with the staff that you’ve got on the booth or doing the teaching so that you find that people do actually get the most out of it? [Katherine] That is such a fun question. Ιt’s something that I really keep top of mind. I’ll answer it in two ways. One is more on the technical experiences side and one is more on the community and social experience side because I think they’re in many ways equally important. On the technical side, when I reflect on the events that we do, we’re really thoughtful about the staff that we choose to be present at the event and really rely heavily on individuals from developer relations. And there are people who are known within the community and by bringing them there and bringing them in, attendees can relate to them because they’re the same. They get one another. And these developer advocates and developer engineers really know how to both create digital technical demos and experiences that welcome and invite people into the conversation. Then, once they established that, they have a sense of how to communicate and relate with one another, I think that’s a really important part of it. On the social and community side, it is really about creating those spaces and making sure people can find them. If it’s birds of a feather, having a very visible and obvious schedule that’s pushed out to them so they know where to be and when and who’s going to be present. And even in the social events, and this gets to the inclusivity piece, is thinking through how are all the different ways people like to interact. And that comes down to everything, from as simple as drink choices that are available, to having quiet spaces within, an event that it’s not one type of social interaction or activity. So I would say that those are ways that I’ve really approached it both in terms of connecting from a technical standpoint and connecting from a social and community standpoint. [Jo] Yeah, they sound great. I’ll definitely be coming to one of your events. [Katherine] I hope you will. We still need to meet in person! [Jo] So before we turn to smaller events, because we’d been talking about some real flagship events, I wanted to talk about possibly the most, glitzy event of the technical calendar, South by Southwest (SXSW), which also happened fairly recently. It’s definitely kind of next generation in many ways, or maybe even like a Ted event. What do you think are the hottest trends in events and, where are we going to get to next, when it comes to the developer events so that we can mimic Ted and SXSW a bit more closely? [Katherine] Really good question. I will be frank. I’ve been to SXSW. That was in 2012 while I was still in the ads organization and I gave a lightning talk on the porch of a house on innovations search ad formats. I was in Austin for 24 hours and it poured the entire time. So I had a quite uniqueSXSW. Following along with it in the media, when I think about the developer experience and I think about the type of experiences that are created there and that really resonate, some of it is pushing the boundaries. And while developers are incredibly pragmatic, I think when boundary pushing technology and ideas are presented in a really authentic way and in a humble way, it really does resonate with them. I think that one thing, one lesson that I take from those things is at events that we do, we can’t be afraid to push the envelope, but we need to do it in a way that shows humility. This, again, is my personal reflection, that it needs to show humility. It can’t necessarily promise the world. It needs to be put out there and say, “we’re going to try this thing and we think that this is the direction”. So I think that that’s one element to really take from those, which is: we want to armor attendees with really practical information to do their jobs and be successful, but without losing that they are technologists. And part of what this space is, is always thinking on the bleeding edge and in balancing the innovation and the opportunity. That’s one thing that I think to take away. About the second, I love the use of space at SXSW. I actually really reflect on a time that I spent in Edinburgh Scotland during the Fringe Festival, which for those listeners who haven’t participated in it, it’s a month-long festival of festivals in Edinburgh, Scotland. And one of the most special things about it is where the content is delivered, where the performances are, could be everything from a pub to the basement of a church, tο a car, to a street. I like the different use of spaces and really thinking about how to create large vs intimate, loud vs quiet, learning and connection experiences through the use of space. That’s the second one that I think as I’ve gone to a melange of events at the Moscone Center in San Francisco, is really seeing how the producers of the event are using space and bringing, instead of a city, how do you recreate that within the confines of a conference center or conference space. In terms of the TED talk piece, that’s again, really thoughtful attention to the curation of content. It is that balance of deep technical content, right? Recognizing that people need to free up their brains and learn in different ways. Dipping back into my education pedagogy from that time in higher ed is people’s attention spans are limited and the ability to continue learning diminishes pretty quickly. I can’t remember if it’s at the 40 or 50 minute mark within something. So, having a really nicely curated content list, where people will use their minds and brains in different ways depending on where they are at the stage and their conference journey is really important. I think that’s something that SXSW and Ted do really, really well. The mix in how content is delivered in and who’s delivering it. [Jo] I see. Yes. I think your point about humility is absolutely right. And it goes back to your point of making the people that are attending, the ambassadors, really. You’re always speaking to them and saying, well, what do you think? You know, where should we go next? This is not us telling you, it’s us working together. And I get the sense that Ted is very much the same, it’s a conversation isn’t it? And light wires coming together and as much it’s done behind the scenes, it happens in front of the camera as if it were part of the presentations. I loved the use of space you mentioned and looking for different venues. I mentioned this on the last podcast actually, but I’ll share it with you as well. There was a game developer event recently in Finland, using quantum computing emulators and they were working in the Saunas and on a Ferris wheel. And I think that’s got to be the most bizarre pairing of locations to work. But you know, why not? [Katherine]  You know, there’s that line that everyone shares, that the most important track at a conference is the hallway track. And your point of how do you help people connect when you have people who run the scale of extroverted to introverted at an event? It is by creating those spaces in nooks and crannies. If somebody knows they’re going to be more relaxed on a Ferris wheel, create an opportunity for a couple of people to sit together and have a Ferris wheel journey. And I am sure that the quality of those conversations, if they were in their zone, must’ve been incredible. [Jo] Absolutely. Yeah. So let’s turn a bit to smaller events now, because in some ways they must be more difficult in the scope. You know, when you have a smaller group of people to work with. I’ve done events, for example meetups, where it’s a startup, so it’s all hands to the pump. Everybody has to be involved from the most introverted kernel developer through to the marketing team. Everyone’s got to get out there and press the flesh and take names and it was uncomfortable for us doing that because some guys, had never been to an event before. You know, the young actors, they’re not really into it. So how do you, how do you work with a meetup and get people to come together in the same way that maybe a more professional team that’s had that experience, would automatically sort of dive into things. How does this event work? Say if you had a group of people that said “hey, we want to do a meetup on something. We’ve all got day jobs, but we’re all fascinated by code and computers and we want to work together”. How do you guide them? [Katherine] That’s a really good question. I feel like in the moment, we’re quite spoiled and how we answer that because platforms like meetup.com have come to be what really facilitates that connection and that discoverability. Even reflecting on what the experience would have been like 5 to 10 years ago, I think my answer would have been quite different. When we think about community work, we think about all of the things that you just said: which is what is the minimally viable product (MVP)? What is the time, the location, the space, the food that is going to make people want to take those two hours out of their evening to come and spend time with one another? Really having that critical mass of individuals who have a shared affinity. My experience with meetups has been quite fortunate, not only because of the platform technology side of things, but it’s been done through other larger scaled community efforts, whether it be through Google developer groups or having event managers who are supporting different chapters of open source communities. So, my experience is probably a little bit different, but I think my advice for people would be to really leverage platforms, things like meetup.com because the search functionality makes it discoverable, to really leverage connections and relationships within networks. I think that becomes such a huge piece. If, you know, someone knows someone who works there, “Hey, can you ask if we can get that space?” And especially if it’s at larger companies or incubators and shared coworking spaces, many of them are now set up with event request processes to actually make it quite easy and somewhat turnkey for those meetups to come into this space. And so, probably in the same way that folks deliver career advice, I would give very similar advice back from the meetup space, which is, really to think of the folks that you’ve met throughout your journey, introductions and connections that they can make, to give you that space and that foundation to then be bringing people together. And then, I think as well, on the content side, many of the large tech companies want to be finding scaled ways to get into these communities as speakers, as contributors, as community builders. And so not just to be tapping into the network for space, but also to be tapping into them, because companies are really hungry to be present and to help foster and grow these groups. [Jo] Yeah, that’s very true. I think people don’t realize just how much help they’ll get if they ask for it. It can make a big difference between people coming home and say, you know, I met somebody from this company and I asked a question and I now understand why this book hasn’t been fixed or why this speech is being delayed. And they’ll go back and they’ll keep going back because, that’s what you want, isn’t it? You want people to give up their time and come to my event. It’d be awesome to think that, you know, if we’ve talked through this, that maybe somebody listening is inspired to run a user group meeting or a meetup and, you know, just give their hands to it and see who turns up. I’m almost tempted myself I must admit. So yes, if you’re out there listening and you’re interested please let us know on Twitter it will be fantastic too. Anyone that wants to set up an event, particularly if they want to tell us about it or get any advice. I think we’re pretty much closing Katherine. I suppose I wanted to ask you before we go, what do you think the hottest trend will be in developer marketing couple of years, from your observations over your 13 years prior to that? [Katherine] Wow, that’s a great question. I know I keep saying that, I must sound like a broken record, but this is just really fun. I enjoy being challenged with these questions. [Jo] For example, do you think it will be Ferris Wheels? [Katherine] Uh, I don’t know about Ferris wheels, but when you challenged me to ask that, and this is actually the historian in me that says – actually what I studied in university is – I actually look back over the years that I’ve done developer marketing and developer relations to say what has and has not changed in terms of the practice. And, to me, perhaps this isn’t where I see it going, but more where I hope to see it going. I think the things that have really worked and that have really stuck have been when, when technology is really invested in by a company or if it’s something that’s very experimental, that it’s really positioned as such. I think that there’s such an opportunity to lose trust from developers. If something doesn’t work or doesn’t have longevity and isn’t stable. And so, to me, my hope for the future, if you will, is just companies and platforms continuing to focus on that. That again, it’s kind of that really, really radical pragmatism if you will, just continuing to make sure that it comes down to what do the users really need to be successful? If I extrapolate on that, where I hope to see that trend is, is really thinking about what those next million or billion users are both from the consumer side of how do we think about how technology is used globally and how people can access that technology and make sure that we’re developing platforms and APIs and tooling that allow developers to actually create experiences that can be used globally. Whether you’re a farmer in Kenya that has a weak mobile signal or somebody sitting in the luxury of Silicon Valley. That’s one, one direction I hope to see it continue to go. And then I think the second is in terms of building up those next million or billion developers is really inviting and welcoming into the fold a diverse and inclusive set of technical practitioners. That’s the way. We’re not just going to get there and making technology pervasive and accessible and thoughtful by having the platforms that work globally, but also making sure the people building that technology, understand and think and know who those users are and what they need. And, and the way you do that, is having a diverse and inclusive set of developers. So those are the trends that I hope for. [Jo]  Yes, yes. The people and communication. It’s such an important part of it. And let’s hope that you have this wish granted, even if you didn’t get to work for President Hillary Clinton, at least this is one thing that does come true. [Katherine] That’s what drives me every day when I come to work. So… [Jo] Well, it’s been fantastic talking to you. Thank you so much for taking the time out to take part in this “Under the Hood of Developer Marketing” podcast. And it was a pleasure working with you on the book and I’m sure we will be updating and continuing to write great content about this topic for many, many, more episodes to come. So thank you so much. I will close now by saying thank you to the listeners. Thank you for listening to “Under the Hood of Developer Marketing” a podcast devoted to developer marketing and relations. If you want to listen to any other episodes, you can subscribe at developermarketingpodcast.com and follow us on Twitter at @slashdataHQ for regular updates. Thank you. #google #GoogleCloud #developermarketing #KatherineMiller #Podcast #developerevents #UndertheHoodofDeveloperMarketing

Listen to the audio episode here. [Intro] Hello and welcome to “Under the Hood of Developer Marketing”, a podcast from /Data. This is the podcast to come to for best practices and insights on the developer marketing world. In each episode we meet a different guest each with a background in technology, who shares their experience, success stories and lessons learned. We are /Data and our mission is to help the world understand developers. Stay tuned for more episodes by for signing up at developermarketingpodcast.com . [Jo] Hello, welcome to “Under the Hood of Developer Marketing”, a podcast from /Data this is the very first episode and today I’m very lucky to be joined by Mary and Andreas, who are both heavyweights in the world of developer marketing and developer relations. I will get them to introduce themselves so Mary, perhaps you could tell us a little bit about yourself, what you do and your career to date and your book. [Mary] Sure, thanks for having me today. My name is Mary Thengvall and I’ve been working with various developer communities for a little over a decade now. I started at O’reilly media have a lot of experience around DevOps and the performance basis there and then worked with Jack infrastructure, working with their community team, a company called SparkPost here in San Francisco as well which is the email API company building their DevRel team. I have noticed a lot of patterns and trends along the way, over the last few years especially, as developer relations cannot come into its own. And so, for the last year and a half now I have been working with consulting companies that are trying to figure out what developer relations is and how to build these technical communities. I have been helping them build a team or work on a strategy or figure out the business value of what there are doing, building a community with their developers, with their technical audience. And released a book back in October, called the business value of developer relations, that’s split half and half between how to define the business value for your company and how to figure out what that is. So, that you have the metrics and you have the value you can take back to the stakeholders. As well as practical application now that you have a DevRel team, what do you do? How do you handle it? How do you connect with the community? Some best practices along the way. [Jo] Thanks I’ve been looking at your book. And I have to ask, I was gonna ask later but I have to ask now. What is it with the avocados? [Mary] Sure thing. When I was back in SparkPost, about three years ago, we had one of our product managers who had a hard time saying developer advocate when she got to talking quickly and so would come out developer avocado every once a while. And all on our team loved avocados so we kind of embraced it and it became our internal team name. And then couple of us where sitting chatting about it one day and realized that there’s an actual analogy around it that might help our coworkers understand the value of developer relations and what they can get out of that. The basic idea, and I have a blog post about it is that and giving a talk about it this weekend, is that DevRel can be viewed as a kind of fatty department or an expensive department with sponsorships and swag and community events and all these things. But used in the right time, in the right ways, in the right combination is incredibly healthy for both the company and the community and beneficial to the longevity of the product. [Jo] I see, right and yet it’s only stone hard on the cover. [Mary] The avocados on the cover of the book are folks that I did case studies with throughout the book and I have snippets for each of those case studies throughout the book with that particular person. [Jo] I see, well the cover is very remarkable and memorable, and we’ll put a link to the page of the podcast so people are able to see that and read more about the analogy. So, Andreas turning to you now. I know a little bit more about this because I worked with you on it and it’s got a more more post-modern cover I would say and can you tell us a bit about what’s inside it and how you came to write it and about yourself please. [Andreas] Yes I’ll start with myself. I used to describe myself as a developer once, I also was a strategist, these days I am more of an entrepreneur and CEO. So, the book came out of probably a conference. Our Future Developer Summit ( futuredeveloper.io ) which we run for the second time in 2017 and there we had a few folks who were giving talks in what was essentially a relatively small audience. It was invite-only as well we didn’t publish any videos. We thought how we can get the word out to a wider audience. And I think it was one of the attendees that mentioned it together with the Nicholas Sauvage, my co-editor for the book. And so we said let’s find the medium through which we can spread the word more widely for what speakers in this conference, the future developer summit talk about. At the conference we had quite a few senior practitioners, director level people, VP level people, your usual suspect companies, the big platforms speaking on whatever they were an expert on, whether it is email marketing or hackathons or building communities and so on. So, we thought let’s invite them to write a chapter of the book each. So, we created a book that essentially is best practices from the experts. And that’s how the book came about. It was published at our September 2018 conference. We are also working at a version 2 I should say as a teaser that will come out in the next few months. Basically, it is as close as it gets to a definitive guide on developer marketing, by the experts and the practitioners in our field. [Jo] I am, yes we have two very different books about a similar kind of build. There is a developer marketing book from experts in the development marketing stage and then Mary your book with the case studies is something that you wrote solely with a technical reviewer Jojo Bacon, a very well known in the field. Looking at the two subjects, DevRel and developer marketing, Mary how would you define the difference between? [Mary] I think there’s actually a lot of overlapping as I’ve been reading the developer marketing book. There’s a lot of times that I’m sitting there nodding saying yes I say the same thing to people all the time. One of the interesting things will developer relations and one of the things a lot of companies struggle with, is where it fits within the company. There are pieces of marketing in there, there are pieces of product in there, pieces of engineering in there and figuring out where DevRel fits is difficult. But I think because of that there’s things that we can learn from marketing, there’s things we can learn from product, there’s things we can learn from engineering. The focus on developer marketing is fascinating to me because it is helping marketers who don’t have a tech background and aren’t necessarily too tech savvy, understand how to approach a technical audience, which is huge and that’s what has been a problem for years in tech companies, that developers don’t trust marketing team because they don’t know how to speak their language. So, I’m excited to see the impact of the developer marketing book on the industry as more people start to read it and more people start to apply the principles in it to see how that changes the trust balance between developers and marketing teams. [Jo] Do you think there’s a different skill set or a demographic required for that kind of work or do you think it’s something that anybody could pickup given that we’ve now got two books on the subject? [Mary] I think it is something a lot of people could pick up and I think developer relations depends on the role that you’re pursuing. So, someone who is excited about technology and interested in doing some research and getting to know specific communities can absolutely pick up a technical community manager job or some of the other related jobs within developer relations. Developer advocates usually come from a developer background or a coding background of some sort, as they are those who really dig deep into the code with many members. And, while a technical community manager is absolutely expected to carry on a conversation, a technical conversation, that’s more of a high level than “I’ll pull up my laptop and open my terminal and code into the API alongside the community member.” I think there is a slight difference there of when someone can just step into a role versus having some things in their background that qualify them for it. But I think anyone who is interested in meeting the needs of a developer audience and is willing to invest in the time that it takes to learn the technical aspects of that can absolutely step in at least in some of those roles. and at least in some of those rules. [Jo] Andreas I bring you in here, you have your own views I’m sure, for the differences and the overlaps. What do you say is the biggest area where there is an overlap? [Andreas] First let me talk about marketing vs relations. I’ve been grabbing with that distinction for a while and we’ve talked about it with Jo, doing a blog post on this. To me, it maps roughly as marketing vs client relations would map any other field. In other words, marketing vs sales. Sales has a bad reputation in some developer circles as well and I think the closest analogy would be marketing and client relations. Marketing in my mind is about defining target audience, market plans, outreach channels. How are you going to reach those developers, the product marketing side, marketing communications and so on. Relations is all the field work, in other words working with developers to help them understand how to use your tools to build better apps. That’s one that’s going from the company to the developer and then it’s the opposite side which in some companies and circles is called specifically developer advocates, because it’s about going from a developer to the product manager in the company saying “I’m getting very strong feedback from people who use these tools that we should actually include feature X or Y and is very often the case that the product managers not get to listen to that feedback because a) they don’t have the means or b) because they are based on the words of big customer feedback and they won’t hear the guys in the long tails. So it’s a very important role, advocating on behalf of the developers to the product managers on the next features our product should include. [Jo] I can see Mary’s nodding along to that. [Mary] I completely agree. There’s a mantra that I tell people often: to the company I represent the community, to the community I represent the company and you have both those interests in mind at all times. So, it is a balancing act at times because you’re constantly going back to the company with feedback from the community or constantly turning around and explaining to the community why a product road map looks the way that it does and why those are the decisions you’ve made and there’s also some industry though-leadery tight pieces in there as well, as you’re explaining why we’ve made these decisions or what best practices are we following, here’s the reason why this fits within the current landscape of the tach industry. And so it’s kind of a mixture of all those things. There’s a lot of storytelling in there, not from a telling a white lie storytelling, but from making what you say fit to the perspective of the person that you are talking to. Taking the feedback from the developer audience and the technical audience and communicating that in a way that the product team and the stakeholders and the company are going to understand and vice versa, taking the business speak from your product team and the stakeholders and communicating that back out into the community in a way that they understand and because you are that bridge, you build trust on both sides. The biggest thing that I see developer relations being responsible for is building connections, both community member to community member and community member to coworkers. Then making sure that those connections are strong and then stepping back and letting the other people do their jobs. I’ve been calling that DevRel qualified leads along the lines of MQL because it’s a business phrase that people understand. But I’ll make an intro of a community member to a recruiter and it’s not my responsibility whether or not that person gets hired but I’ve mad that connection so I can claim that connecting piece or connect the community member to someone at the marketing team, a community member that is active in our forums and is posting the longer posts in there and they might be able to write a blog post but it’s not my responsibly if that blog post actually gets published on the site, There might be a three-month long for content or that community member might not have time to do that but I’ve made that connection and is a qualified connection that could bring value to the company and so focusing on how many of those connection can make how many of those connections am I responsible for vs what’s the actual work output so we aren’t getting saddled with sales numbers or marketing numbers or traditional business metrics that don’t really fit within the developer relations structure. [Jo] I see. It sounds like you are doing a fantastic job there and clearly love it. We came up in our book with some experts we thought represented the best of developer marketing. Which companies or individuals do you think are doing a brilliant job in the field so that, for example, if you were building a new team, the stars, the key players that you would want to put on that team? [Mary] This is a hard question because there’s so many good people in the field right now.  It’s been really exciting to see as the industry has grown, people have become more passionate about it and more understanding of the value that we bring to the table. To see the people who are really leading the industry in doing really really awesome things and pushing the industry forward. I don’t know, narrowing down that list difficult. [Jo] Yes, no need for names of course because somebody always is forgotten. What do these guys and girls have in common? What could you say really makes them shine? [Mary] So what I think is the biggest thing is they’re passionate about their community. Those who want to enable the developers and community they are working with to do their best possible work. That comes up in different ways. Might be best practices for APIs or best practices for incident response or any variety of things. But they’re very passionate about how I mean how do I make this the best possible experience for them so that their job is easier, their life is easier so that they have a work life balance, any of those types of things. That passion leads them to give talks about best practices or connect more people because they’re interested in digging those relationships within the community. And so it leads to all of these someone going down a rabbit hole and researching a topic because a community member is really passionate about it and now I want to understand how that fits into the overall structure of everything that we’re doing. That passion for their community really drives and then you can see it on the technical work they’re doing, and the community work they’re doing. [Jo] I’m gonna move to Andreas now about the book. We published “Developer Marketing the Essential Guide” in September last year, so technically just before Mary with her book. So ours was kind of the first book on the subject. Why do you think there weren’t books before and why now is the right time to be publishing this book? And why is it so important? Why has developer marketing become so important? [Andreas] Firstly, developer marketing practices are substantially if not fundamentally different from consumer marketing or even if you take B2B marketing in any vertical. One of the reasons is that the audience is extremely technical, extremely demanding and critical of any marketing activity. I would say much more critical than any of all other audiences. It’s often recognized that if you have experience in developer marketing, then any other marketing field is downhill for you, it’s much much easier. It’s exactly about developing a practice of client relations by supporting and not selling to the community. So, this subtle way of creating friends and advocates and evangelists within the community is much harder than actually getting people to buy something. The reason why there wasn’t something like that before? I guess the field started practically when Windows was introduced with Microsoft pioneering this platform economics model and Steve Ballmer dancing on stage with famously “developers, developers, developers”. But, most people saw the opportunity as a business model to start with and there has been tens of papers in the academia on how you build platforms and innovation platforms, if not hundreds of papers, but not on how do you get the these people, that community to engage. Because you’re not buying an audience hitting people with ads. We need people to interact, to engage. People who contribute back in most cases.  I think that aspect of the community engagement was largely underhyped and not paid enough attention to. This has changed perhaps in the last year or two, because it’s not just the big platforms that are in this game. You know, the likes of Microsoft and Google and Facebook and Amazon that we have authors from in the book. Its many more smaller companies, companies across verticals, you have car makers, you have sports companies, lifestyle companies, retail and so on, all creating developer communities. Because they now see that their APIs or whatever they have out here, their SDKs are now getting action, they say “cool, how can we get more of that? How can we get 10x, 100x the traction?” I can see communities being created in the wild. I was talking with a payment service provider recently and they said “We have use cases of our API out there which we had not thought of and are very cool. Can we have more of them? How can we market to get more developers building those use cases systematically?”. The practice of developer marketing is new because we just hit that inflexion point going from early adopters to mainstream if you like where companies are realizing that this is a systematic process, a process that can be systematized in building developer communities.  [Jo] Yes everyone’s a software developer these days or having software development teams. We had the example in in our book about a bank creating a software product. And I guess all of these companies need the expertise. Not everybody has it, not everybody gets it the right way.  Mary? Do you have any examples of when you go to a community site, one that appears to be failing? What you look for in a good site or a bad site and how do you spot where the problems are? [Mary] One of the biggest or the easiest ways to spot a company that isn’t investing in it, is companies who set a developer site and then it’s static and not updated. There are many companies who say “what we need is developers.company.com and it will maintain itself and developers will see we’re on their side and we never have to do anything else for that”. So, you go on a site and it’s very obviously a static site, hasn’t been updated in a while, there’s no activity, no investment. It’s very easy for developers to see that a glance, they checked that box and walked away; and go see someone who is investing in the community on a regular basis. But it’s interesting to see, I think you asked Andreas about it, the timeliness of these books and I think there’s been a lack of resources for the last few years there’s a stat I always like to go back to “Why is developer relations such a big thing now?” it’s had a classic hockey stick growth over the past few years, because startups have become a big thing again. A lot of the startups that are coming up aren’t consumer audience startups. They are B2B, working with other companies. The developers are now responsible to build that software and make that integration. And there’s a stat from 2015 that basically says there is a new startup about every second or around that amount. Not all of those succeed of course but out of that amount even if we say 10% have a developer faced audience, the amount of companies who need to market to developers and need to build relationships with developers just need to skyrocket. I had an interesting conversation with a client the other day, I was trying to get at the bottom of why you’re really wanting to build a community into the foundation of the company. Which is a question I ask all my clients, to make sure they’re not just checking the boxes, they actually have a direction they need to be going and why they want to include this. And his response was “I know that I can absolutely build a successful company without a community behind it, but that’s not the company I’m interested in creating” like “I want to build a company that has a solid community, I want to get feedback, I want to be selling to people’s needs and I want to be solving these problems for people. You’ve got a lot of startup founders these days, especially in Silicon Valley where the founders are developers themselves. So the focus is shifting to knowing that type of marketing is not working that type of sales isn’t working, that type of relationship building is not working. We need to be connecting with developers one on one, we need to be building those relationships. Or else, no one will even think twice about using our product because they know we aren’t investing time in them and why should they invest their money on us. [Jo] Yeah absolutely. I’m not gonna ask you to give away all your secrets of how to build a strong community and from my own experience, I’ve worked in a number of companies where we set up communities, some more successful than others.  I recently did an interview and they were saying that, really, you don’t need a huge amount of documentation, you don’t need a forum, what you need are answers. A knowledge base. This is a problem you might experience, this is how you solve it. Some on your site and a really solid StackOverfolw presence. So the people can go there and see all the different manifestations of their problem and how to solve it. Would you agree that less is more? What would you think would be the basic quick wins to build a strong community? [Mary] I definitely agree that less is more if your resources are limited. Focus on the top questions people are asking and more importantly than answering those questions over over, fix those issues within your infrastructure. So if you’re seeing the same questions pop up all the time on all support sites, then your documentation isn’t great on your website or maybe there’s an easier, clearer way to communicate that in the actual work flow, setting up an integration. So paying attention to what are the common questions, not just to prove the documentation but to improve the developer experience overall. One of the fascinating things that I always love hearing from clients and always a very interesting conversation afterwards is when they say well we don’t have a community, we need to build one from scratch. And my answer always is, unless it’s a brand new company that hasn’t even gotten started and has a long way to launch the product yet, “you do have a community, they’re out there you might just not be engaging with them”. They will be on StackOverflow, they will be on Twitter, they will be on Facebook, Reddit, they will be in all of these different places talking about this company and talking about the issues that they are having or the experiences they are having, bad or good. Whether or not the company is connecting with them is a whole other question. Your community is out there so it’s just a matter of how and when you’re going to engage with them and engaging with them where they already are, is your starting point. Then bringing them back to your site or creating a forum, if that’s even necessary, is the next question to ask. But figuring out where your community exists is the first step in where they’re already talking so you can be engaged in the conversations of the platform where they already are. [Jo] I see, yes. Andreas you have a different overview of this because /Data surveys 40.000+ developers a year about developer resources among other things. What people typically tell us about what they value from a community. [Andreas] I’ll answer that straight away let me first add a comment on Mary which directly popped into my mind as she was going through her story. I remember, probably 2008 or 2009, Nokia days and Nokia had a developer program, at least early stages, or very early stages, I think it was probably only documentation. The prevalent thinking was that “developers would come to us” because at that time Nokia had 40% market share of mobile phones globaly. It was number 1 and was no number 2. And of course, they assumed that developers would respect that market share. And of course, it was nowhere near that and the fundamental reason that Nokia and to an extend Windows lost was because of lacking developer love and developer traction. I think people still will make the same mistake and saying “ok, we’re kind of big enough, no need for developer APIs because we exist, and we have investors” and whatever else. But that’s not the case. Back to your question Jo, on defining the most important things, a developer marketing or relations effort is nice to have and I think it’s extremely clear and very stable in our metrics. We run this study we call Developer Program Benchmarking and one of the things we measure is the features or marketing initiatives a company needs to offer to support developers. Among the top ones you have, documentation is core, which is hygiene. Then you have tutorials and how-to videos, answers in public forums like StackOverflow you mentioned and dozens of others and non-English speaking parts of the world. You have development tool integrations, training courses, official forums, technical support, more and more with that. And the most interesting is that the types of developers that go to each, vary a lot. So for more experienced developers, hackathons aren’t resonating as they are with newer developers. Documentation becomes more important as you are an experienced developer the more experience you have. Same goes for technical support so whereas it’s a set of hygiene factors if you like, they differ a lot by the kind of developer, the region and in some cases if you’re talking about IoT or cloud, or machine learning and so on, there’s a disciplined audience to target. [Jo] Something that came across while we were writing the book, we had a chapter from Qualcomm talking about hardware developers and that really struck me how different are hardware developers from a software developer. It’s just one word and it doesn’t really seem like it makes a lot of difference but the background of people coming from and the kind of assumptions they make about writing code are very very different. Mary, have you had that kind of observation? [Mary] I’ve seen that a little bit, I’ve more heard about it in startups where a hardware startup gets an investment from a software VC and the advice that they are given and the ways that they’re told to approach things doesn’t fit their community, doesn’t fit their audience at all. Like you said, it doesn’t seem at a first glance that it should be so much different but it really is a different audience. And there’s people mixing them both, there’s a Venn diagram there, but I think the way that it’s set up, the types of events that you’re at, the types of places that you’re going to meet your community members can be very very different between hardware and software. [Jo] Thank you. We’ve got to wrap up soon, so before that I’d like to ask you both for your top tips of the hottest trends in this space in 2019. So, where do you think we’re heading and what new things we’re going to see. Mary I’ll let you jump first. [Mary] I’m actually really really excited about this year and next year as well to see what happens and where we go. I think we’re finally hitting a point in the industry where people are starting to understand this is necessary. They might now understand why, but that’s the next piece and at least we’ve come to a point where companies go “ok, now we need developer relations, we need someone building a community here or checking that box and the next question that they’re starting to ask is “why do we need? And what does it do? What’s the value there?” and we’re starting to get more and more resources about it as well. So, I run the weekly DevRel newsletter and I did just a quick analysis of the data that I pulled in from my first year, based on the tweets and the blog posts and the things that I was collecting on the span of one year. It was fascinating to see some of the patterns and one of them was job skyrocketing throughout the year consistently. Another one was topics like burnout highlighted in April, which is after the first set of conferences for the year and then again in December, which absolutely makes sense. But, as we hit the end of last year there was a lot of pushback particularly on Twitter around the value of developer relations and “what is DevRel anyway? Is it really necessary?” and stuff from other technical community members, honestly. They weren’t understanding.  That went on for a while which was kind of discouraging but interesting to watch. But the fascinating thing that came out of it was that there was a whole slew of people posting about “here’s my experience with developer relations”, “here’s what I do”, “here’s why it’s valuable”, “here’s how it helped me”, “here’s how it helped other community members”. Direct feedback from community members of particular companies. How we were incredibly valuable in helping them use our product or make their jobs easier, all these different things. As more of those stories surface, more people start to understand where that value really is and the value in those DevRel qualified leads, the connections that we’re making. I think it’s not only continue growing as an industry, but there’s actually going to be an understanding of the value that we provide to companies and the advantage of building a community from the start and not just tacking in on at the end because “Oh, we don’t have a community and we need one t able to succeed.”. But the value of creating it from the start and making it a community-centric company and the advantage that this gives you over your competition. [Mary] Yeah that sounds fantastic it’s exciting when you put it like that. I’m gonna share mine now and I’ll come to you Andreas. I recently spotted a quantum computing games jam in Helsinki which combines two of my favorite things. But the trend I was particularly excited to see was that the guy sat on a Ferris wheel writing code. So they went round and round on the Ferris wheel and occasionally hopped off and jumped on again, all the while writing games using a quantum computer emulator. I think that’s fantastic, so let me put my pitch in what I hope should be the hottest trend in 2019. Now Andreas I’ll come to you. Have you got anything more crazy than that? [Andreas] The hottest trend that actually very few people can understand and code, right? I hope it gets more popular. I’m much more of an industry observer, always had a knack for that so I would point to three trends. I think that probably within two or three years developer marketing will be recognized as a field of B2B marketing, because of the sheer innovativeness of the domain. In developer marketing and with that I include relations, we have so many innovative ways of engaging people that no other industry has tried simply because it wasn’t that hard to engage an audience. Developer marketing has and will have much more than others fields of marketing. I was seeing in the news today that Salesforce is giving out its tools for training employees, including trailhead which is how it trains developers. They were selling those as an add-on on top of Salesforce. It’s a sign of that move or lending of experience and best practices from development marketing to other fields. That’s one trend. The other trend I see again from an industry perspective is that we now have the big five consultancies move into developer marketing. The first company I’ve seen do that is Accenture and they have a formal team. Last I knew it was over a dozen people, working with enterprises and their developer programmes. It’s visionary of course but I think it’s just a sign that the big consultancies and again the big enterprises as well are looking at this very very seriously and there is a demand for that. The third trend I see relates who developers more and how their needs are addressed by a developer program. In our research, the most and that’s by far the most under-funded marketing activity above all is answers in public forums such as StackOverflow. What developers tell us versus what development program managers tell us is that there is a huge discrepancy. For developers is very important to get peer support through public fora for developer marketing and relations folks it actually doesn’t receive a big part of their budget and this comes on comparing two surveys against each other. Because of it being such a fundamental need, I think we’ll see many more “StackOverflows” emerging, especially in countries where English is not the primary language. We’re seeing already there are companies with Q&A platform products and they’re successfully selling those. And I think we’ll see competition for where the person go to get supported by their peers. [Jo] I think that’s very true and I think I am. It’s one of those things that will absolutely be growing constantly. I’d like to thank you both Mary and Andreas. We had a great conversation here and I think it’s time to wrap up, but if you would like to leave any questions, I am sure we can find a way to get them, maybe Twitter? Is this the best way to ask questions of you Mary? [Mary] Sure, my DMs are open so feel free to send me a message my handle is @mary_grace [Jo] Anyone listening out there that has any questions for Mary, direct them through Twitter. Andreas I guess the same? [Andreas] Yes mine is @andreascon. [Jo] Ok, and I am Jo Stichbury and I’m @fluffy_macoy on Twitter. Thank you both, it’s been great chatting to you. [Outro] Thank you for listening to Under the Hood of Developer Marketing, a podcast devoted to developer marketing and relations. If you want to listen to other episodes, you can subscribe at developermarketingpodcast.com or follow us on Twitter @SlashDataHQ for regular updates. #developermarketing #devrel #marketing #marketingtodevelopers

Missed Part 1? Read it here. How important is your community? Only the core of all your efforts. Community is probably the #1 theme that came up in our podcast episodes, coming strong even from the first one. As soon as a product/service is available, a community will be created with regard to your product. Mary , Adrian , Jeremy , all DevRel professionals, agreed on what “community” means. It’s people who interact or work with it and get together to seek information on how to best solve problems or talk about features they love or hate. The strategic decision is where you will choose your community to live. Are you going to leave it “out in the wild”? Andreas asked in our first episode. Jeremy discussed how running a coffee shop helped him better manage a community in episode 4 . You just have to offer a space that people will want to visit and make sure you take different tastes into consideration. Adrian gave us the basis for all communications with your community: be authentic. Mary sums it pretty well: “Your community is out there so it’s just a matter of how and when you’re going to engage with them and engaging with them where they already are, is your starting point. Then bringing them back to your site or creating a forum, if that’s even necessary, is the next question to ask. But figuring out where your community exists is the first step in where they’re already talking so you can be engaged in the conversations of the platform where they already are.” Do you need to be a developer to become a Developer Advocate or work in developer marketing? Short answer – no. You don’t need to be a developer. But you need to be tech savvy and have the 4 skills we mentioned in Part 1: passion, curiosity, empathy, inclusion. Curiosity will get you started. You need to be curious so you can understand how your product/service works and what users have to say about it. Passion is a must. DevRel is based on being in the middle: between the company and the community and you need to be passionate in bringing those two to work together effectively. Empathy is also crucial, if you don’t understand the struggles or concerns developers have in using your product/service, you won’t be of much help to them. Inclusion is key, make sure you are taking care of all members of your community and offer a welcoming space for the newest members. Is every developer valuable? Absolutely. Every developer is valuable as they add to your community and help it grow. Adam adds the business value of each developer: “Talking to developers is a critical part of what means ‘business success’. A developer actually means something to you. It might even mean that the solution you just sold to a customer will be implemented in a correct way and become successful.[…] By engaging with developers you open up your ecosystem to expose yourself to new opportunities and potential customers.[…] If you know what the value of the developer is to your business, you can use that to work out what you can be doing to change or invest in those different channels.” How do I engage my community? For this question, we will rely on wisdom collected from all episodes. To keep engaging your community, you should offer a space that serves your community’s purpose. A space where all developers can interact, share and solve problems. Communities are self-sustained when built but you need to be there and help Make sure you remain authentic and inclusive, the community should have a place for everyone. Stay up to date and make sure your space is tidy – trolls are everywhere – but to offer real value, focus on content that helps developers be and work better. If all goes according to plan, the result will be a community that functions independently and you should only take action when and if needed.   Hopefully, it will be one that even your engineers will want to crash their meetups as Arabella says in episode 6. Season 2 will be coming soon. If you like what you read in these posts, make sure you listen to the episodes . There are a lot of insights that couldn’t fit in these blog posts. If you want to join as a guest in season 2 or want to be notified for new episodes, check out our podcast page at developermarketingpodcast.com