Search Results

In this article, we share a chapter from the latest State of the Developer Nation report, which anyone can access. We focus our attention on some of the key differences between developers in East Asia, including the Greater China region, and the rest of the world. Understanding these differences provides valuable insights that can help shape the strategy for developer engagement programs. For this analysis, we split the Greater China area from the rest of East Asia to provide more regional granularity. In terms of relative size, we find that almost a fifth (18%) of the global developer population is located in either the Greater China region (9%) or the rest of East Asia (9%). Breaking down East Asia into countries, we see that more than half of the developers here are spread across two countries: Indonesia (32%) and Japan (21%). When comparing developers across regions, we can see that just over a third (34%) of developers in the Greater China region have six or more years of experience, which is notably less than developers globally (43%). Furthermore, the Greater China region has a much smaller concentration (4% vs 22% globally) of highly-experienced developers (16+ years). With generally lower levels of experience in the Greater China area, aspiring developers may find starting a career here less competitive than developers in regions with higher levels of experience. The Greater China area has a comparatively low concentration of highly experienced developers State of the Developer Nation Q1 2022 East Asian developers outside China have similar levels of experience to the rest of the global developer population. Both groups have a little more than a third (34%) of their developers with 11+ years of software development experience. However, East Asia’s data are largely propped up by Japan. The developer community in Japan tends to be highly experienced, with almost six in ten developers (59%) having 16+ years of experience. No other country has a higher concentration of developers with this level of experience. With such a high concentration of highly skilled developers, we can expect some differences in behaviour, which we’ll highlight in the last section of this chapter. More than 50% of Chinese Developers have learned how to code via undergraduate degrees in computing State of the Developer Nation Q1 2022 The journey to coding mastery lacks a clearly defined path. Developers typically state they’ve used more than two learning methods on average to learn how to code. In general, the self-taught method is the most popular among developers globally, with more than 60% using this method. However, our data shows that the proportion of self-taught developers fluctuates significantly across regions. In the Greater China area, the most popular method for developers to learn how to code is via an undergraduate degree in computing, with 50% having used this method. This is significantly higher than developers in other regions (41% – 42%). We generally see a higher concentration of professional developers in Greater China (83%) than we do in the rest of the world (70%). It could be that the job market in Greater China more often requires a degree in computing or engineering, which would also explain why self-teaching is used less often in this region. Developers in the rest of East Asia, however, tend to follow the learning trends of developers in other regions. Here, we see the self-taught method is the most popular method (61%), followed by an undergraduate degree in software engineering (41%). Analysing the data at a country level, we see developers in Indonesia are more diverse learners. Developers in this country stated that they used three methods on average when learning to code. Indonesian developers are more likely to learn via self-teaching, online courses, and developer boot camps than any other developers in East Asia. This is quite different from their peers in Japan who are the least likely to use online courses and bootcamps to learn how to code. Instead, developers in Japan are most likely to use the self-taught (63%) and on-the-job training (45%) methods when learning to code. Developers in the Greater China area are half as likely to have a Stack Overflow account than developers globally State of the Developer Nation Q1 2022 Next, we explore how developers interact with the popular online community, Stack Overflow, to understand their engagement levels with programming support. Stack Overflow has become a standard support community for many developers, with more than eight in ten (85%) of the general developer population reporting they’ve used or visited this popular question and answer site. Our focus on developers in East Asia and the Greater China area shows Stack Overflow’s popularity falls below the global average. Developers in these regions are around three times less likely to visit Stack Overflow than developers in other regions. Developers in the Greater China area are the least engaged, with only 19% having an account, and only 11% having earned at least one badge. Developers in this region have other home-grown Q&A site alternatives, such as segmentfault.com, which could be contributing to the lower adoption of Stack Overflow. When looking closely at the rest of East Asia, we again see that developers in Japan are skewing the perception of this region. Developers in Japan have even less activity on Stack Overflow than developers in the Greater China area. Here, only a little more than a third (36%) stated they use Stack Overflow. Furthermore, only about 5% have an account. Like developers in the Greater China area, Our data does show usage of Stack Overflow increases among Japanese developers who have gained experience in software development, indicating that less experienced developers are using other platforms for support. Like China, Japan has other home-grown options like teratail.com where developers can field programming support from their peers, which may be the place new Japanese programmers visit more often to get answers to their questions. That’s just one chapter from the State of the Developer Nation report. There are 5 more chapters you can access. Want more? Download the full report! #developermarket #china #developermarketchinaandeastasia #stateofthedevelopernation #eastasiaandchinadevelopers #developersinchina #eastasiadevelopers

When asked about why we do what we do, there’s always one response: we love solving problems for the industry and our clients. Our mission is to help our clients understand what the market looks like, what developers need, what excites developers and what doesn’t and what they expect from our clients’ products and the developer programs that go along with them. So, when we are approached with a request for some custom work, we roll up our sleeves and dive deep into the data. In this blog post, we’ll look together into such a request and: What the client asked How we approached it What we offered How the client solved the problem. Let’s see how this client, a household name we’ll call “Client”, which is a company among the Top 5 in tech and one of the largest in the world, worked with us to improve their Developer Experience. Knock knock – The Question The client chose to work with us to address developer experience. They already had access to our research showing how their satisfaction level compares against their competitors, but what they wanted was to understand what drives developer satisfaction with their product and what they can do to improve it. What was the goal/challenge you were looking to accomplish? The product we wanted was a custom project. We’re always really interested in the health of the developer experience. And so we use the Developer Program Benchmarking report as one of the indicators of the health of the Client developer experience. Within that, we are also interested in the adoption and engagement [of our product]. But within my team, we mostly focus on satisfaction as a proxy metric for developer experience. When we decided to do this custom project last year, it really was to understand “what is moving our satisfaction up or down?” and “what are some of the levers that we can adjust in order to improve our developer experience?” Some of this data is confirming things that we already know. And some of it is providing new insights. Both of those are valuable use cases for us. This report helped us not look at developer experience in a vacuum, but benchmark it against the industry. Client representative Why did you choose SlashData? Part of that is the sample size. And I think the trusted relationship we already have. Also, I think this ties back into why do we choose the Developer Programs Benchmarking report. The competitive analysis in that report is important to us. While we didn’t focus on that in the deep dive, I do think that is one of the reasons why this data is helpful so that we’re not always looking at Client experience in a vacuum, but we can actually as the report says “benchmark it against the industry experience” as well. The answer After we looked at what questions our client has, we took a step back and looked at the data points that could help us find the answers. There were several data points to choose from, as we survey 30,000+ developers annually on 11 areas of interest. How did our data solve your problem/challenge overall? The area where we found it most useful is getting that cross-section of region, experience level, and product area. So we looked at that data. The place where it becomes a little harder in our process is making those insights actionable within our company. Part of our job is to provide the data and then folks act on it themselves. I think that Client Developer Relations, as a whole, is still thinking about “how do we make this data digestible and more centralised?”. SlashData is a big data source for us. But there’s a lot of information always coming in at us, around developer experience. We’re still trying to navigate how we make that useful and easily actionable for our people. I don’t think we’re there yet. I think we’re at the point where we’re thinking “I want data to do my job better”. And then, we’re at “wow, okay, well, there’s a lot of data. What do we do now?”. What decisions did you make using the data/research? What we wanted to focus more on were the top three things that are important to developers this year. I don’t always have visibility into the TA level on what decisions might be made from this data. That’s also something that we want to do better. It’s also hard though because we don’t always expect that there will be a leader who’s going to take this and say “I now declare, we all must focus on this”. We are equally happy if a single engineer sees this data and then goes and makes a change in the parts that they affect. That alone makes the overall developer experience better. There’s this interesting intersection of leadership use and individual contributor use. We know that there’s value to both sides, but we don’t necessarily track what that value is. Working together Seamless cooperation is key to bringing in good results. That’s why we wanted to know how our client felt about working with us on this project. What did you like about the process of working with SlashData? I think that Slashdata is a good partner. Especially when we focus on discovery. We had a case last year when we didn’t necessarily know what we were looking for. Your response was to try out different things. Even when we asked for a random data table, you did not only deliver it, but you also provided a comprehensive analysis and different ways that we could look at the data. Last year we focused a lot on regional topics but we also broke it down by product area. And then at the end of that, we decided that we didn’t care so much about the region. What we needed to focus on more is the product area. We have that partnership where we can do some exploration, and then have things work out well. Even if they don’t work out well, we continue from there. That’s a really important part of this piece. The flexibility is really important to us, and just as much, your responsiveness. How would you describe the service quality? I think that’s excellent. We’re not always super buttoned up on what we want and that causes a lot more work on your end, but it’s handled well. I feel like you have helped us navigate that a lot. What are the things you found challenging when working with SlashData? We don’t always know what we’re looking for. We are relying on you, the data analysts’ expertise to help guide us. We need the expertise, but you don’t know the business goals. And it’s challenging to try to find that middle ground where I can articulate the business goals well enough for you to provide the expertise and help us decide on the right metrics or analysis that would prove to be useful information for those business goals. This interview is part 2 of the “How we work with our clients” series. The product this client worked with was a custom project, along with Developer Program Benchmarking data. You can also see how Okta managed to broaden its developer network using our Developer Program Benchmarking. Working on a new initiative or want to make sure your product will win developers’ hearts? Talk to us. #developerexperience #slashdatadeepdives #slashdatacustomers #developerprogrambenchmarkingdeepdives #casestudy #deepdives #usecases #developerprohrambenchmarking

The 22nd Developer Nation global survey from SlashData reached more than 20,000 developers in 166 countries. Its findings are bundled in a free “State of the Developer Nation” report. This research report delves into key developer trends for Q1 2022, taking a particular interest in the following: Language communities – An update Understanding developer personalities Who is using low-code/no-code tools? Spotlight on China and the rest of East Asia How developers generate revenues Emerging technologies Here are some highlights from the report, guaranteed to intrigue your curiosity: Language communities – An update JavaScript remains the most popular programming language for the tenth survey in a row, with close to 17.5M developers worldwide using it. Python has remained the second most widely adopted language behind JavaScript. Python now counts 15.7M users. Go and Ruby are important languages in backend development but Go has grown more than twice as fast in the past year in absolute terms. Rust has nearly tripled in size in the past 24 months, from just 0.6M developers in Q1 2020 to 2.2M in Q1 2022. State of the Developer Nation 22nd Edition Spotlight on China and the rest of East Asia More than a quarter of developers in Greater China (26%) and the rest of East Asia (27%) don’t use Stack Overflow, which is more than three times the rate of developers in the rest of the world (8%). The Greater China area has a relatively low concentration of highly- experienced developers (16+ years of development) when compared to developers in the rest of East Asia and the rest of the world. More than half of Chinese developers have learned how to code via undergraduate degrees in computing, which is about 10 percentage points more than developers in the rest of East Asia and the rest of the world. How developers generate revenues Contracted development is the revenue model of choice across all industry verticals, used by nearly a third (31%) of professional developers. Less than one in ten (7%) professional developers are generating revenue from selling data. Usage of the advertising revenue model declines as companies grow in size. Developers working for large enterprises (5K+ employees) tend to use multiple revenue models less often than developers in smaller companies. Below we have included a few graphs that illustrate some of the findings. You can download the full report for free and access all data and insights within. If you need additional information or looking to understand developer preferences’, please get in touch with us and we will dive into it together.

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