Taking Ownership of Bugs.

Posted on 28 July 2010

I’ve had the great fortune of working in many different professional environments.

I’ve worked in small groups, large groups and even LARGER groups, even worked for myself.  Each of these types of groups has it’s advantages and disadvantages that impact the end user.

Currently I’m in the largest of possible professional groups, the largest technology company in the world, and we’re working on a very big project.  While the scope of what can be created is much greater in a larger group, the path for problem resolution is also much larger and more diffuse. As a community manager it’s necessary for me to follow bugs that impact the end user, down that path, to their conclusion.

Following that path when working with multiple groups across the globe INSIDE of a large corporate infrastructure, is as difficult as it sounds.  Each of these groups relies on the basic infrastructure the corporation offers such as IT, legal, procurement, etc throughout the development process, and sometimes, beyond.  In that type of environment, even if everyone is super focused, there are going to be gaps resulting in issues that impact the end user.

So, how do we resolve these issues? Good question!

Someone needs to OWN the issue! If the issue impacts user functionality, that’s YOU, the community manager. Often the buck will be passed, ESPECIALLY if the problem hasn’t been concretely identified, that’s where you come in.  When a technical issue arises in my community I trust I’ll hear about from the users before I hear about it from an engineer so take advantage of that advanced notice!

The most important thing you can do is DOCUMENT the issue.  Create a bug report, write a ticket, use whatever documenting system you’ve got in place!  With a ticket in the system you’ve covered your bases and time becomes ammunition for issue resolution.  The LONGER something  remains broken the more urgent it becomes, usually.  As always, the CM represents the company to the members and the members to the company.  Unfortunately co-workers and outside group members that don’t have to interface with upset members don’t feel as motivated to give answers as you are to provide them.  So a little patience goes a long way and candy to butter up the engineers doesn’t hurt either.

I’d love to hear from others in the same position.

Do you have any tricks or tips you’ve got for supporting large projects with multiple groups or for coercing engineers?

How do you update your communities?  Do you update through your community or through branded social media?

How do you retain your members when the issue isn’t resolved in a timely manner?

Feel free to contact me by posting a response, tweeting me @ericfoster or on Facebook.


No responses yet. You could be the first!

Leave a Response

Recent Posts

Tag Cloud

#cmgr brand awareness Community Management Community Manager Customer Service Employment End User ericfoster.org Hard Work Interview online community Rebuilding social media southwest air user experience

Meta

Nurturing Online Communities since… is proudly powered by WordPress and the SubtleFlux theme.

Copyright © Nurturing Online Communities since…