I work in technology education for software organisations. This has mostly meant working in the field we call Developer Relations. Although I've had some fantastic opportunities working in devrel teams, I've become increasingly convinced that education can play a more comprehensive role–and that within companies, we're restricting ourselves unnecessarily by the division of engagement types into different functions.
You might have encountered roles like Developer Advocate and Community Manager more commonly, but education for developer products typically also falls under devrel. Sometimes education is categorised alongside functions like Developer Experience (DX), which can touch on the software product itself. For an intro to devrel strategy, check out What is Developer Relations?
Please, not that argument again
In devrel there is a neverending debate about metrics. Effective community programs are necessarily not over-tracked. To do community well, you need to avoid trying to gather too much information about how people interact with what you put out there. This makes it extremely challenging to measure, which often puts devrel in a precarious position within companies. We tend to get moved around a lot and have to continually justify our existence, because proving the impact of what we do is a tough gig. This means that community development efforts are unfortunately frequently undervalued.
Don't worry–devrel metrics are not what I'm on about in this post. 😅
Have we painted ourselves into a corner?
Leaving aside the metrics problem, I'd like to explore a realisation that's surprised me over the past few months:
While measurement challenges shouldn't be a barrier to investing in community development (and we should absolutely pressure companies to contribute to community learning), I believe we could actually be missing opportunities by trying to keep a strictly enforced delineation between devrel and functions responsible for other types of engagement, for example with customers–one opportunity being the ability to validate your programs.
This might set alarm bells ringing for some people, and understandably so. Anyone who's been in devrel for a while has probably experienced being used as a resource for other teams, including those in the sales and marketing cycles, where success looks necessarily different. It's important to guard against being measured with the wrong stick, but I can't help feeling we sometimes paint ourselves into a corner.
Ultimately, unless you work for a non-profit program, your job in devrel is most likely expected to contribute to the growth of the business, albeit in the long term and in a way that's hard to trace back to the work you did. I'm certainly guilty of having indulged in some level of denial of this reality in the past. Could a more explicit acceptance of it help put devrel on firmer ground? Or would it be a slippery slope? Can we better leverage our skills without corrupting devrel's core purpose?
Sidebar: I also wonder if being cut out of customer conversations restricts our ability to influence business development in an ethical direction. Having community-minded people in the room might help companies make more responsible decisions, but it won't happen if we leave the money stuff to other teams.
Education as infrastructure for engagement
Let me take a step back and retrace how I got here.
The most substantial project I've worked on in my time at Postman has been a framework for building learning experiences that manifest inside the product but are remixable externally. These learning pathways are designed to scale, they're self-serve, use automation, involve a variety of technologies, are based on modular / reusable curricula, and informed by learning theory–it's an experimental approach. I call it Learn by API, because it teaches people about APIs, by API.
One of the first contexts I was able to trial the new experience in was the company's student program, where learners acquire the skills to achieve Postman Student Expert certification. It's a community program, but the relationships are a little more closely managed. We've had training sessions / events backed by the framework, and we maintain an ongoing dialogue with students–we also award certification leading to an even more involved pathway.
Access to quality feedback was a huge advantage at an early stage of this approach–it basically let me treat the student program as a kind of R&D for learning experiences. This provided the initial validation for investing further and rolling it out in other places.
The feedback loop allowed me develop the framework like a product, with a more robust, iterative cycle than I've used for any education resource in the past.
Internally, a few Postman teams started using the training for onboarding new hires, which gave me access to even higher quality input. Around this time I was also in discussions with Postman's customer teams about a variety of projects, including the user conference, for which I was able to develop the framework further.
The conversations I had with solutions engineering, success, sales, and team enablement, opened my eyes to the potential of education as an asset in additional engagement types–and a way to leverage key relationships to benefit the user base more broadly.
Customer education roles are increasingly popping up. People working with customers on developer products are under no illusions about the impact learning can have on revenue-related outcomes such as sales and retention.
Openness ftw?
The reality is that we're bound to contrived divisions on account of company performance measurement structures. In devrel we generally have a solid idea how to develop community, but the need to demonstrate impact can dictate the tactics we invest in–the tail too often wags the dog.
That aside, how often have you discovered people in different teams repeating the same / similar work? Between devrel, marketing, cust success, support, content, and beyond, I've lost count of the number of times I've seen this happen, especially with learning resources. I can't help wondering if we would put devrel in a stronger position, not by guarding its bounds more agressively, but by collaborating more openly with other functions.
Health warning: how feasible / risky this is depends hugely on company management and culture.
There is a ton of overlap between teams. For developer products, lots of people are doing education work outside devrel, sometimes under the banner of enablement or experience. When you look at what dev advocates and solutions / sales engineers do, the day-to-day can be very similar–the contexts and success definitions are largely what differ.
It's also true that the output might be positioned differently–customer resources might be more value-oriented for example.
I see what I do in developer education as enabling people, I build supports to facilitate success around a software project / product. For this purpose I might create content, tech, and communication channels. In the end I'm aiming to broaden adoption and deepen engagement–a goal usually shared by multiple teams.
Education has tbqh always felt a slightly uneasy fit for me within devrel given the focus on "speaking developer" etc, if we want to open doors to people from other backgrounds, this mindset can be more of a hindrance than a help. With the growth of no / low code I suspect it's going to become a more general problem.
All the things
Where my head is at right now is that the most effective place to drive education work would be in collaboration with any and all engagement-facing functions: community, customer, partner–add UX to the list depending on product, and HR for internal training. If we can treat education as part of our infrastructure (don't make me add "Ops" to something 😭), it can support and be informed by all of the relationship-building we do collectively.
We can frame engagements in terms of how close or far they are from product and company. The closer the relationship, the greater scope we have for tracking the impact of a resource without alienating people. Customer and partner relationships are typically already tracked, providing access to understanding and validation that we don't usually get with community.
I now believe that with education at least, starting closer can put us in a better position to reach further away. By delivering resources initially within a more monitored context, we can benefit high value relationships in the shorter term, and leverage them when it comes to empowering the wider community over the long term. This informed development could build a foundation of confidence in what we release at scale.
Top comments (0)