When at the Community Leadership Summit in Portland a few months ago, we met Evan Hamilton from UserVoice. He hosts a monthly Meetup called the Community Manager Breakfast at UserVoice's offices, and today's meetup was a great chance to hear from some very talented community managers as they unpacked the thorny challenge of working with their company's development teams. 

Causeit has had our own ups and downs with development teams; we have an internal Lead Technologist who is also a developer, but largely depend on clients' own developers or outsource shops or independently contracted freelancers. We've found a few great pieces about how to connect your community, your own business cases for action and your developers so that everyone is aligned and on the same page, and we've integrated those comments into the notes we have from the Meetup. Sorry we can't attribute it all perfectly—we had a hard time tracking names and handles. If you attended, please list your twitter handle in the comments and/or on the Meetup so we can all get to know each other better!

Here are our raw notes, centered around questions. Be generous with the writing, please—these are mostly unprocessed! 

What works in your formal processes with developers? What doesn’t?

Many attendees related that the formal processes for accessing developers in their companies don't work particularly well other than for establishing priorities, and leans on more personal connections to get results and build relationships. Out of the conversation, a number of different questions arose, providing a bit of what-to-ask-after if you're interviewing a company to work with them or brainstorming with your team to increase communication:

• How to work with management to re-prioritize? 
• How to communicate with the community about the problems they may experience when the developer can’t attend to it immediately? 
• Evan: how do you create the middleman to prioritize tickets, etc—so that the developers respect that prioritization? 

One attendee shared that running social media listening post reports and ticket reports quantifying how many people are reporting an issue is a great way to prioritize by community impact. 

Storify

reports from Facebook and Twitter are a great way to show what features get feedback one way or another.

How do you build rapport with your development team?

It also became clear that a lack of transparency about development goals/CM goals makes it hard for either side to ‘get’ each other.  Jeremy and MJ from Causeit mentioned a focus on bringing people into meetings which aren’t ‘theirs,’ like developers in strategy meetings and vice versa. 

CMs focused on supporting internal development communities seem to report more succes than community managers viewing only external communities (like customers) as true communities. For example, community managers who write user stories for developers can make a big difference for their internal and external communities simultaneously, while building rapport. Another community manager lets her developers know about their wins from/for the community so that they have the experience of acknowledgment and positive feedback which puts negative feedback in perspective.

How can you ease work with remote team members?

Again, many community managers emphasized reaching out to your offsite developers as another community you ‘manage’ so that you can ensure you’re in the conversations that matter to your developers. Ideas like welcome notes when they join the team, CC'ing people on strategy (and not just bug/feature emails) and reaching out for online social events (think chatrooms and Google+ meetups) were all suggested.

That's great, but how do you build a functional internal development community? (a brief brainstorm)

• Weekly meetings
• Met devs on their terms: chat, etc. 
• Happy hours
• Scrums
• Using Campfire
• Transparency
• Developers: having them ‘get’ the use cases
• Using your CM chops to let the devs know what’s up for users—what matters to them. 

Do you use Yammer, Jive or other community tools? 

CMs raved about a couple of simple strategies they've found to build up the fabric of their internal development communities:

• Yammer
• Jive
• Private Facebook groups for simple sharing
• Status feeds, as in TeamworkPM

When new features are wanted or needed by community, and only some transparency is possible, what can you do? 

Evan and other attendees suggest bringing the angry tweets and feedback from customers to the development and management teams to create a case for action, with reminders to the development team that the users have little to no access to what’s going on in the development plan. In other words, managers and developers who see customer complaints and, exasperated, throw up their hands and say 'we're doing all we can' can use gentle (or firm) reminders that end users often don't know

what

 is being done or why their request/bug is being prioritized the way it is.

Other topics for discussion which were touched upon but not fully explored included:

• How to deal with merged products/acquisition challenges? 
• How to bring transparency to CM? 
• How much truth can you tell your customer? When possible, immediate and clear response makes a big deal. 
• Time-boxing responses to feature requests, etc. 
• Using bugs or other breakdowns as a moment to connect with community and develop relationships
• During DoS attacks etc, direct the energy and anger where it’s deserved, like at the hackers.