Years ago, I had the good fortune to learn assembly language programming as one of the very first CS classes I took as an undergrad. I loved it and I aced the class, but after graduating in the late 80’s with an advanced degree in computer science, I ended up in research and coded only rarely. In hindsight, I now see that as a mistake, as women in tech especially benefit from their coding skills.
Fast-forward 25 years later, after a career spent mostly in graphics and media tech standards, product management and marketing, not only are my coding skills rusty, but worse, I’ve pretty much forgotten common computer science algorithms and systems architecture.
So, it was quite the experience working my way through Human Resource Machine’s 40 odd levels, called “years”. Humbling, and at times frustrating, I started the game in early January while on a flight overseas, and just finished this week. I found I mostly only had time to play while away from work/home/family obligations, needing at least two-hour blocks of time to think through the exercises without seeking online help. YouTube has many Human Resource Machine “tutorials” but they decrease a bit as the levels increase, as they generally get increasingly complex. You may be wondering why I wanted to even play (if you can call it play!) this particular “learn to code” game? I had already recommended the game to several non-techy friends who asked me what games to get to interest their kids in learning to code. But I said to myself: “Rita, you really shouldn’t recommend anything coding related until you tried it yourself” – as all too often, experienced developers find these coding exercise games trivial, but for some who have had no exposure to computing algorithms, and no experience writing code, even the simpler learn to code games can be off-putting, especially to children. This ended up being the case with Human Resource Machine, at least from my experience. My stepson, a straight-A high school student, for whom no subject seems difficult, said the game became just impossible for him after a few hours of playing and I know of others whose kids quit after around level 20 or so. Year 22, the Fibonacci Visitor, where you have to output the Fibonacci sequence up to, but not including the inputted number, is where/when the game starts to get challenging, at least in my opinion. From there, the complexity escalates with a few minor “breather” years in between.
I digress, and this post is really about programming with Post-its, something I had never considered before, but which worked out surprising well for me, especially considering the quite limiting assembly-language-like syntax of Human Resource Machine. The code is entered into a narrow vertical field to the right of the game scene, which gets frustrating to scroll through as the lines of code increase along with the complexity of the problem being solved.
So, by the time I got to level (Year) 28,I knew I was in a bit over my head. Enter the Post-it notes, which I think I got the idea from after sitting through so many meetings over the years where we would wall-paper Post-it notes to whiteboards during our scrums. Firstly (and for the first time since starting the game), I broke down and went online to find a sort-3 algorithm, quickly choosing this box-trick algorithm from the CS 201 class at Michigan Tech, just to wrap my head around the problem and try to solve it quickly in a way that made sense to me.
This image with the orange Post-it notes pretty much illustrates how I broke out the three subroutines for the sort from the main program, (one section each for whether A, B or C was the lowest valued number).
I ended up with 70 statements and went over the speed challenge, but at least my code was clean and made sense without crazily looping around itself. Designating smallest number “A”, largest number “C”, with middle number “B” I basically coded the six permutations of ABC, as you can see (if you look closely enough) at this Post-it:
Note that I have used five Post-its, one for each of the mini-routines to test for each of the permutations above, except for A, B, C, which falls out neatly from the main program block.
My second biggest challenging level was Prime Factors, Year 40. I quickly got that 2 is the lowest prime factor, and considering how many inputs were shown, I tried to take a shortcut by simply dividing by 2 in a loop, and when I got to the first negative number, I dumped the number out as a number w/o prime factors. Of course, the game then presented me with the number 15. Bomb! Then, I rewrote it to try to find the small possible factor by cycling through, testing and recording the lowest prime factor (in 15’s case, it is 3 of course). I later discovered there are a number of solutions for this one online, but I’m pretty happy with mine.
At the end, I did a quick tally based on the game challenge thresholds given in the hints for each level, and I think I would like to refactor Years 11, 13, 14, 20, 24, 28, 34 38 and 39 if I ever get the time.
You can see all of my Years’ results (some good, some not so good according to the designer’s size and speed thresholds) on my GitHub page.
I would recommend encouraging students to play Human Resource Machine in a beginner high school computer science class, or as a warm up to an assembly language class, if they still exist ;).
Frequently when I speak with folks in the graphics industry about product management, questions about developer’s issues come up in conversation. Any kind of large-scale software development project requires support, so it’s not surprising we’re seeing the establishment and growth of developer relations programs in many tech companies.
This got me to thinking how they’re interrelated: in a very black & white nutshell, I see managing product a bit analogous to inbound marketing and developer relations as somewhat analogous to outbound marketing.
This is overly simplistic, but I think it helps frame the discussion for how to maximize developer relations’ success with the goal of shaping, shipping, and managing a successful product (for example, be it an API, a complete SDK, or perhaps even a game engine & editor).
It’s important to note that most managers involved with developer relations for software products hold a firm belief that anyone hired to work with developers on behalf of the company need to be as skilled (or almost as technical) as those very developers. I hold a slightly different view because I’ve had the fortunate experience to work with both sales engineers and technical marketing support folks in both software and hardware firms. Support from great sales engineers and excellent technical marketing people are as important to developers’ success with your product as your developer relations outreach efforts.
In my experience, I have not seen much in the way of formal processes in place around gathering customer information and requirements from developer relations engineers but I have seen plenty of process and even worked with some awesome applications for managing inbound leads as well as outbound marketing practices – many of which were inspired by developers using the product.
It may be worthwhile to apply some of the marketing industry’s best practices to engineering product management and good ole’ fashioned developer relations.
A keen awareness and repurposing of the various tactics, techniques, and tools from the marketing technology industry can help provide a framework for successfully managing the developer relations’ process in such a way that it effectively optimizes product. But first, let’s take a look at some key similarities and differences between the two fields: marketing and developer relations.
Establishing trust between company and partner/customer is first and foremost for both. In any relationship, be it born of a marketing outreach program or ad hoc developer-to-developer relationship, one must first establish trust.
I came across this great post on Quora based on the writings of “trust expert” Charles H. Green, who describes the 4 ingredients of Trust in (Understanding The Trust Equation). Here’s the conclusion, but I suggest reading the aforementioned Quora post if inclined, as the comments are also noteworthy.
Conclusion: Reducing perception of Self-Orientation is the greatest lever to increase trust in relationships. Ask more questions. Listen. Don’t fill silences. Let the other person feel that their point of view, their feelings, their presence here are as important than your own. Charles Green also has a pretty cool infographics on trust on his blog.
Establishing a sense of trust and actually being trust-worthy are essential for any business to succeed, but seem particularly important in the sales and developer relation’s role. I think this is why marketing and marketers often get a bad rap from engineers: they are just too far away from actual customers, and therefore the trust variable may not factor in as seriously as in developer relations or business development. In fact, I do not think it’s too much of a stretch to say that I have seen many folks in business development with strong technical backgrounds take on the role of developer relations as well, especially in start-ups and smaller companies.
Okay, now that I’ve gotten trust taken care of – which may be the most obvious outlier that differentiates marketing programs from developer relations programs, let’s take a look at what they really have in common.
Key tenets both Marketing and Developer Relations share:
- Opportunity to share your vision with the community that you think will either entice them heartily to engage with your product and/or solve their problems
- Proactively listening to what the community needs and filling developer needs with concrete help and support via any conduit possible
- Providing an easy to find, easy to use conduit for developers to offer you feedback, e.g., using social media’s ability to bring market feedback back into the mother ship
- Analytics tools to measure outreach and feedback success. Note that marketing seems to have more tools at their disposal than developer relations. Still, any developer relations program can be strategically planned to take advantage of some great marketing and sales tools if architected thus.
Okay, now that I’ve drawn some hopefully useful parallels, let’s take a look at some of the better-known developer relations programs out there today from the likes of Amazon, Apple, Google and Microsoft, just to see how they shape up in terms of “best practices.”
I’ll start with Google’s Scalable Developer Advocacy program:
From Google’s Reto Meier on Quora: https://www.quora.com/What-is-the-Scalable-Developer-Advocacy-team-in-Google-Developer-Relations:
Scalable Developer Advocacy is part of the Developer Relations team — whose role is to be the interface between developers and Google’s developer offerings.
More specifically, Developer Advocates on the Scalable Developer Advocacy team are engineers who operate at scale to inspire and teach developers about Google’s developer platforms, ecosystems, and APIs.
They are responsible for crafting a narrative based on developer and product needs and priorities; creating engaging, discoverable, and useful developer content (including training, videos, blog posts, social media, web sites, and conference appearances); and delivering and distributing that content at scale to as many developers as possible.
The team also receives and analyzes feedback from the developer community, and advocates on behalf of developers with Google’s product and engineering teams to adapt and improve the underlying platforms and APIs.
Google’s “content tsunami” pretty much sums up Google’s perspective on developer outreach, which while awesome in many ways, and certainly useful when searching for specific content help, may be a bit overwhelming to some. That said, a few years back, I was very happy to have the Chrome daily builds and plenty of blog posts about their new WebGL support around when testing some WebGL code.
As Google is well known for holding the bar of rigorous technical hiring standards very high, it’s probably safe to assume the content and support coming out of Google is best-in-class. Last June, Reto Meier also wrote a great post, “The Core Competencies of Developer Relations” on this very subject. He says: “… a thriving developer ecosystem needs a trusted Developer Relations team made up of engineers who are the interface between 3rd party developers and the engineering and product teams building the underlying platforms.” This perspective will surely enable experienced developers on their platforms, but it may be a bit intimidating to developers just getting started on their software and platforms.
Next up, let’s take a look at Apple’s best in class developer programs:
Apple’s developer outreach and developer relations are today considered by many to be best in class; just go to https://developer.apple.com/ to see how succinct, streamlined and efficient it is for developers to get the info they need – to a point. The point being their developer support ecosystem is deeply meshed to point developers straight to developing and submitting for their respective operating systems.
Education is a bit buried but it’s still there, and their interfaces to information are second to none. I think Apple does a very nice job welcoming beginners and newbies as well to their platforms and OS’s.
Education is a bit buried but it’s still there, and their interfaces to information are second to none. I think Apple does a very nice job welcoming beginners and newbies as well to their platforms and OS’s.
And now Microsoft:
Microsoft’s generic website is a tad disappointing from the developer relations perspective, but a quick search for “Microsoft developer relations site” brings Microsoft’s top hit to Microsoft Edge, (screen shot shown below with my clicking on the drop down menu ‘Developer technologies’ at the top of the white bar).
To be blunt, outside of Microsoft’s deserved success for the Visual Studio IDE product line, crafting clever marketing terms such as “Edge Dev” when you really mean “developing with Microsoft for the Web” just adds unnecessary overhead for developers IMHO. Why not just call it “Microsoft Web Dev” or something easy to remember and find like that? I’ll probably never remember the word “Edge” again…
In any case, finding Microsoft developer support and information is not hard, and probably useful enough, thanks to Microsoft supporting developers for decades, as well as being fairly ubiquitous in the software industry, but it’s not something I’d want to model a new 21st century developer support program on.
Last, but far from least, is Amazon’s developer relations and outreach found at https://developer.amazon.com/public/solutions and from where I clicked on “Getting Started,” shown in the screen shot below.
Amazon does a great job segmenting support portals for their various markets including platforms (e.g., PC/Mac, iOS, their own Android OS based Fire, HTML5, even game engines such as Unity), devices (e.g., Fire TV), to services (e.g., Alexa). Beyond that, but quickly findable from their developer home page, it’s easy to find resources such as API help, resources, and more support.
Extra credit for their Flipboard style home page:
But what about that framework I discussed earlier that takes advantage of marketing technology to support best practices for developer relations?
There is not much on the internet in the way of research on how to best manage your developer relations program but I did find this data focused article helpful from the London based agency Metia, because their report shows just how solitary is the work of a developer, how frequently they do the majority of their work from home, and how reluctant they can be to engage off-line, and if they do, it’s generally for key conferences and off-site training to enhance their learning. I have found this to be true in the game development world in particular.
Some of the marketing industry’s best tools can be put to effective use in the developer relations discipline if these programs can be repurposed to bring together connections and content to support your (developer customers’) code development process.
Thanks to the enterprise cloud computing era we find ourselves in now, many of these “marketing tech” SaaS tools provide the perfect test bed for in-house management of developer relations best practices. If an organization approaches management of developer outreach and relations similarly to how it manages product launches, this may enhance the developer’s experience with the supporting company, as long as there is no resulting marketing-like overhead to the developer.
What kind of tools can help?
CRM tools are of course now ubiquitous, but CRM is NOT DRM (repurposed here to mean ‘developer relationship management’), but… there are times a combination of a few great tools can be close to what is needed. Whether it’s community (forum, bug/issue tracking), or content (SDKs, code snippets, white papers, FAQs, etc.), “there’s an app for that” – and usually the one your developer end-user wants is open source and cloud based. Similarly to cloud-based applications such as Salesforce being nearly ubiquitous for business development professionals, applications such as Github, Bugzilla, Slack, Trello, Jenkins, etc. are where developers turn to for code access and maintenance, bug-filing and tracking, communication, build support, and twitter, StackOverflow, LinkedIn, etc. for community, education and help. You might even consider adding one or two good project or product management tools to the mix too if that makes sense. A nicely curated product management tools list can be found on Product Hunt but I think this Quora post has a more comprehensive list; still I found no applications really targeted at managing developer relations. There always seem to be plenty of project management tools as well. Capterra’s new 2016 list of top project management tools is worth a look.
From my own experience, CRM tools like Salesforce, Eloqua and Marketo can all be customized, to a point, to support developer outreach and developer relations programs, but I have yet to come across any marketing technology tools used specifically in a developer relations capacity (in practice). Finding, tweaking and using the best tools can help your organization create best practices for managing their developer relations team.
But what about hiring former developers as DevRel managers?
Too often (and with the best intentions), corporate managers tend to hire former and current developers for their developer relations team – and developers tend to do what they do best – write or tweak code. This is great and on the surface makes perfect sense, but it’s also important (even on a very limited HR hire budget) to hire at least one developer savvy marketing or business development professional. Today, many people in marketing or business have been working with engineers for years, and many have even dabbled in their own development projects. However, perhaps more important than technical ability or deep insight into the product is the skill to bring empathy and then trust to the table, coupled with the skills learned through years of marketing technical products. These skills, applied to developer outreach and relations, can be very valuable to the company’s stakeholders.
Experienced individuals who’ve worked in marketing for a while generally know well how to craft information in an engaging way, how to message it, and how to track results, but may not be as tuned in to the developer mindset as an experienced developer relations professional (with development experience). Joining the two together on a team can be very productive. A two-way symbiotic relationship between marketing and developer relations can bring out the best products for developers that are not merely self-serving the company’s bottom line – something we see all to often in marketing programs.
Marketing to engineers and software developers is growing increasingly more common as many new products entering the marketplace are for use online, in gaming or some kind of alternate or mixed reality space (e.g., AR/VR), all of which come with APIs/SDKs/ADKs and toolkits to access or enhance end users’ experience with the core product offering. Metia, mentioned earlier in this article, posted a blog on Venture Beat a while back that makes a lot of sense: “Software CMOs, meet your toughest customer: developers.” Beyond documenting some of the obvious ways developers are more discerning from other non-engineering consumers, perhaps the best takeaway here is the fact that companies marketing to software developers need to be “… prepared for their enterprise-class expectations in terms of ease of use, documentation, service levels, and reliability.”
Think of it this way: assume the software developer has a need to absorb your true value-add in a faster, more coherent way than what any traditional marketing campaign can deliver, delivered in a way that is counter-intuitive to the usual hype, rhetoric, or splash of a traditional marketing campaign. Work with actual developers both in house, and outside, to craft your messaging and deliverables. As the Metia blog post says, “The resources most highly valued by developers originated from product teams, including documentation, critical updates, SDK, sandbox, and test tools. The least valued — loyalty programs, vendor news, and product brochures — typically originate from marketing.”
Get developers what they need when they need it; use marketing tools to help deliver and manage your efforts but leave the fancy go-to-market plans for the end-user’s products.
Lately I’ve been asked a few questions about how to reach and connect with those developers who are so deep into writing and debugging their code, so dedicated to their own vision that they never ask for feedback once they’ve been tasked. Then, in the off chance late in the development stage they are asked to change direction, they either refuse, or become so difficult your job as product manager or program manager becomes a living hell. Sometimes, they even quit, which may be your worse case scenario.
To be frank, I’ve seen this happen many times on projects I’ve worked on, whether it be in product management, shepherding a specific program pre or post-launch, or just trying to help business development when they bring questions back to the engineering team. After many years working with software and hardware engineers, I’ve found three key ingredients are necessary to build a mutually beneficial bridge between engineer and customer. The first is empathy (for the engineers and their work), the second is trust and the third is respect. In fact, I have found them to cascade from one to the other. The second is actually a byproduct of the first, and if it continues in a productive manner, you are then able to build respect. Without their trust and respect, you won’t get very far with engineers.
Developing empathy, definitely a key soft skill, is easiest if the product or program manager has a keen sense of what needs to be done technically. Empathy is gained by focusing on mutual interests and a shared stake in the value of the work at hand, but is nurtured by listening, truly listening to the engineer first, and the customer second. I know this sounds paradoxical as the engineer is there to develop a product the company wants to sell, and the customer’s (or stakeholder’s) requirement should come first, but if you don’t listen to the developer and the vision they have of the problem, you may miss some important benefit that perhaps even the customer hasn’t thought of and marketers are not even aware of. In fact, so many of the products we use today that enthrall us did not come from customer requirements but from creative people with a vision and the means to achieve their vision (through strong engineering followed up by great marketing). By listening closely and asking engineers questions about the technology, their work, their challenges with the project and what they perceive as their value to the product’s end use, you will learn a lot and you will be on your way to establishing the empathy you need to gain their trust.
Likewise, sharing your own vision and institutional knowledge with the engineer also helps as they often feel isolated due to the sheer effort of their own contributions. Sometimes you will agree with an engineer, sometimes you will not. When you do, and you act as their champion to key stakeholders, you have then won their respect as well. Do it repeatedly and you will win their trust. Conversely, you can still win their trust and respect even if you (or upper management) do not agree with them after you’ve established empathy by providing honest feedback followed up by supporting them in any way feasible as they cope with the challenge of working on something they do not agree with, or do not wish to work on.
You may be thinking, “easier said than done” but every real world software and hardware project has trade-offs introduced by the stakeholders or the creatives peppered with the temperaments of those who deliver said products. Many years ago when I was an intern at Bell Labs in N.J., a wise person once said to me “where there is talent, there is temperament.” This truth has not changed in all my working years. Sometimes the higher the temperament, the greater the talent, but sometimes great talent is meek. Regardless, everyone working on a product or program should to be heard, understood and represented. This is both a product manager’s and a program manager’s role.
Not long ago, I had a fun lunch with a former colleague (we worked together at two different semiconductor companies over the last seven years). Over some nice tea at a Chinese restaurant in Sunnyvale, CA we started comparing semiconductor corporate culture as it relates to vehicles. My buddy was better informed than I as he had worked (but no longer does) at the three distinct and best known semiconductor companies in Silicon Valley, although two of them now mostly operate their businesses outside California.
The analogy goes something like this: one company is just plodding along soccer mom style, going from point A to point B, mini-van style, not giving up, occasionally winning, with no real sense of urgency, but a good sense of commitment. Another company acts like a race car, everyone moving as fast as they can to win the race, with their eye on the driver, the owner of said race car. The last company is best represented by a big Mack truck, joining the race later than the other two, but winning by plowing down the competition.
Needless to say, I had a laugh as I thought it was a a great analogy and a fun story. I’m sure you can figure out which company is which vehicle.