Photo by Jess Bailey on Unsplash
No one gives a &*^@# about your DevRel/Community Programs (and what to do about it) #1: Alignment
Three steps to building solid foundations
We're going to do a bit of "back to the basics" first to kick things off, because if you miss any of the steps in this episode, it sets up everything that comes after this for pain and heartbreak and tears.
(For the back-story on this series, see Episode #0.)
More likely than not, your company's going to use some goal-setting framework like OKRs or V2MOMs or whatever the latest organizational alignment buzzword is at the time of your reading. But even if it's just in sticky notes taped to the fridge in the break room:
#1: Read (as in, really read) your company's goals, as well as the goals of all the people above you in the org chart.
And this is honestly harder than it sounds, because it's not like there's ever dedicated time to do this...
Onboarding into a new company is intense: you're meeting dozens (or hundreds?) of new names and faces, information is being thrown at you a million miles a minute (which is 1,609,344 km, btw!), and also now WTF your monitor suddenly isn't working, and so you need to file an IT ticket for that, and to do that you need to figure out how to do that, and then...
And being further established in your company is also rough because now you're super busy, and so it can be tempting to bookmark that "New Company Goals" page for later (hint: there never*is* a later), and skip that company all-hands that talks about the new goals in favour of an extra precious hour of sleep, or...
Regardless of how challenging it might be to squeeze in: you need to make time for this. Otherwise, you risk continuing to toil away on strategy & tactics that maybe made sense 6-12 months ago, but no longer fit where your organization is going.
🚨 Working very hard in a direction your organization doesn't care about (anymore) is a sure-fire recipe for frustration on all sides! 🚨
#2: Make sure you're able to clearly articulate what the "top 5" problems are for your org.
Some form of "Make more money" is one we can probably safely assume as a given. ;)
But what are their other big problems?
Are they trying to even figure out what product / feature to build?
Are they trying to get the word out about what they've already built?
Are they trying to get more active users for their product / features?
Are they trying to expand to new geographical areas/target audiences/use cases?
Are they focused on building out a partner ecosystem?
Are they an open source project trying to attract new contributors?
Are they trying to get to IPO in a hurry, and thus laser-focused on growing revenue and cutting costs?
Are they in a situation where they're haemorrhaging customers all over the place and they need to both stop the bleeding and turn things around?
🚨 Each of these is a very different problem that requires very different strategy & tactics from a DevRel/Community POV. 🚨
#3a: Make sure you're able to clearly articulate how the work you do every day contributes to solving at least one of those problems.
What does this mean in practice? Here are a few examples:
| MMMassively Big Organizational Problem™ (MMM-BOP 😉) | How you can contribute in your DevRel/Community role |
| Brand awareness (aka, "No one knows who the *&@# we are") | Write tech content aimed at solving common problems in your space, and ensure said content contains popular SEO terms to help bring in organic search traffic. |
| Partner ecosystem | Partner with their DevRel/Community folks on content co-creation, meetup co-hosting, co-speaking opportunities, etc. Bonus: your org gets to benefit from that partner's name recognition/established trust as well! 😎 |
| Expanding into new regions | Expand your meetups program (or partner with others') to those locations as well, to help "break the ice" by building positive relationships with the local developer community on the ground. |
| Haemorrhaging customers | Meet with those customers' developers to figure out their pain points and provide concrete recommendations to your product team. |
...hopefully you get the idea.
And though this "linking" of your work and activities to Other Peoples' Problems™ (OPP — wow, I'm sure on a (rick)roll here with my ancient song references, huh? ;)) might feel limiting to some, there is actually quite a lot of room for creativity / individuality here.
Think of these as Creative Constraints, which are (somewhat counter-intuitively) actually a positive thing that lead to more impactful outcomes!
For example: Let's say the big thing you love to do is speak at conferences. Cool. So proactively look for events that...
...are in strategic target locations that Field Marketing/Sales cares about
...have developers in your product's target audience in attendance
...have a number of customers/prospects who are coming (and see if you can also do a lunch & learn with their developers while you're in the area!)
...have opportunities to partner with... Partners :)
...provide opportunities to run a developer-oriented workshop to get event attendees onto your product as new users
Etc.
💖 Drive Impact++ — make it easy for folks to say "Hell Yes!" 💖
#3b: Make sure your manager agrees with your plans. ;-)
Write down what you plan to do, how it ties to goals elsewhere in the org, and how you plan to tell if you were successful at it. We'll get more into the wild world of data and measuring impact in a later episode; in the meantime, a good general rule is to make your goals SMART:
Propose this plan during one of your 1:1s (usually goals refresh once a quarter, so a few weeks before that is a good time). Your manager should be able to provide feedback, as well as clearly articulate their expectations, what success looks like, and also how they plan to evaluate against that success criteria. This needs to be a two-way conversation, as you have the best insight into your day-to-day tasks, challenges, what you're hearing on the ground from developers in the community, and also where you personally want to grow in your career. But they tend to have more insight into the broader challenges of the business as a whole, as well as what your 👵🏻 "Grand Boss" 👴🏾 in the org chart is most concerned with.
And finally, make sure you're syncing regularly on progress (or lack of progress) on these goals so there are no "surprises" at performance review time, in either direction.
🚨 "Surprises" in the Manager <=> Individual Contributor relationship ALSO result in a guaranteed ticket to pain and heartbreak town. Avoid at all costs. 🚨
Ok, so there's some "101" type information on alignment-building, as well as a proactive heads-up about a few massive pitfalls to avoid. I know this may be yawn-worthy review for some folks out there; I've just seen a lot of people in DevRel think they can simply skip over these steps and go do their thing, and while this might even work (for some value of "work") for awhile, it inevitably leads to a very bad place later on.
In our next episode, we'll discuss building cross-functional empathy to address collaboration issues, which is your first-class ticket to a magical wonderland filled with sparkles and unicorns and rainbows! ✨🦄🌈
Sound too good to be true? Learn more in No one gives a &*^@# about your DevRel/Community Programs (and what to do about it) #2: Collaboration