7 Replies Latest reply on Jan 30, 2017 10:32 AM by CurtisG

    GSD vs. Internal Comms Communities

    annetown

      First, some background: I'm currently in, essentially, my third 'Jive' community, my fourth community overall, and I've noticed something funny. I'm currently an enterprise community manager for Citi, but helped ramp and build an internal community on my marketing team at a previous employer. Directly prior to this, I managed two external advocacy platforms for HTC and Nissan North America.

       

      Now, some context: My current community at Citi is, what I affectionately call a Get S*** Done (or GSD) community. (I consider myself the GSD Squad Leader). We have a smattering of HR tools to help with everything under the sun at Citi, and our community is a place for folks to connect and engage with their immediate teams, larger departments, and sometimes with the company. In the past, (and what my impression from most other internal communities) I've only seen internal communities as almost an extension of internal comms. I know it is way more than that, but for the sake of time, I'm painting with a broad brush here.
      What I want to know is, are there communities out there that do both? We're talking internally later this month about strategy, and I want to pick some brains on whether or not this is possible, what the challenges were, how they started vs. how they got to where they are, etc.
      I'd love to learn:
      1) Is your community that community? If so, which did you start as? Or did you start as both?
           1.2) What steps did you take to get there?
           1.3) What are the challenges you still face?
      2) If your community isn't there, what community are you and would you change it one way or the other?
           2.2) Do you have plans to get to both? Why or why not?
        • Re: GSD vs. Internal Comms Communities
          dougmackay

          Hey Anne!

          Long time! I hope you're well.

           

          Looking back, I'd say that Criticalmass' CM1 community did both. We spent a lot of time considering what the "1" was all about and it was definitely a GSD community but ALSO the voice of the company. 

          1.yes, CM1 was that. I think it really started as a GSD but also had the messaging aspects of comms.

               1.2. I know this might put some managers into a stroke but we did most of this by using spaces. The GSD stuff was definitely designed with hierarchy in mind so navigation could be easy. "Work" was put in spaces, "Culture" in groups. That allowed us to really make messaging rules and engagement points.

               1.3. The GSD didn't really face many challenges once adoption was done. After all, it's about GSD. The biggest challenge was the dilluted argument: if CM1 did all this so easily what was the value. That was really hard to answer and resources played a big role there. We did have analytics back then (on-prem and no resources/budget) so the leadership never saw "value"

           

          That was a while ago now. I think a lot of organizations step into the GSD early because comms is so much more ethereal and harder to quantify. I think your challenge is really exciting and can breathe life into your community.

           

          All the best,

          Doug

          1 person found this helpful
          • Re: GSD vs. Internal Comms Communities
            Dennis Pearce

            We use Jive for a mix of purposes.  In fact, when someone is wanting my help setting up a group or space, I usually go through a "triage" exercise with them based on what we've seen as the three primary use cases in our company.

             

            Is the primary goal of your place:

            • to share information with the broader organization?  In that case we focus on developing a home page that emphasizes navigation, featured content, categories, etc.
            • to collaborate (i.e. GSD)?  In that case we focus on dynamic widgets or tiles that help users see the latest conversations and activity.
            • to provide support for some tool or business process?  In that case we focus on FAQs, question widgets, and ensuring the right people are set up to be notified when questions are asked.

             

            So far it's almost always been one of those three situations.  I think it's important if you have more than one use case to not muddle them together too much in home page design because it can start to get confusing for users.  That's one reason I was happy to see Jive giving us the ability to have multiple custom activity pages.

             

            I think most Jive customers see groups as for collaboration and spaces for social intranet, information sharing kinds of purposes.  We follow that somewhat although we don't have any set rules, so we seem to have evolved into a little bit more nuanced distinction when it comes to collaboration.  When I look across our community, I see that people tend to want to have subspaces for departmental collaboration or for teams within the same organization, and groups for cross-functional collaboration or for communities of practice.

             

            So for example, we have a top-level R&D space where R&D information useful to the whole company is shared.  Under that are subspaces for the development teams working on various unannounced products.  But we use groups for things like learning new programming languages or technologies.  I think there are two advantages in using subspaces rather than groups for collaboration in scenarios like the one I described:

             

            1. If you have a top level social intranet space like the IT space, the HR space, the R&D space, etc., having collaboration going on underneath them makes it a little easier to publish content when it's ready for primetime.  Employees in each business function are mentally and psychologically working in the same general "area" of Jive and can navigate back and forth between the places they need to work in.  Whereas cross-functional teams and CoPs use groups because they don't have a natural "home" space to associate with.
            2. The ability to inherit permissions means you don't have to worry too much about it once it's set up.  For example, we try very hard to work out loud, so we want our development organization to all be able to see everything going on with every project.  But because these are unannounced products, not everyone in the company should have that same access.  So in our case, out of an employee population of 12,000 about 2,000 have access to these spaces.  This would be a nightmare to manage if we were to use social groups, but because spaces can leverage LDAP user groups and inherit permissions, it's still painful but doable.
            3 people found this helpful
              • Re: GSD vs. Internal Comms Communities
                annetown

                This is a really interesting concept. I'm curious, how do you help manage these permissions, etc? Do you do a training with them? Citi has about 230,000 members in it, so scalability is incredibly important. And while I really like the idea of spaces for organizations, I'm fearful there would be a lot of overhead management taking place.

                  • Re: GSD vs. Internal Comms Communities
                    Dennis Pearce

                    I have some instruction docs and videos, but it is challenging.  One of the funniest things I see happen (for me, not the space admins ) is that an admin will have a subspace with custom permissions.  They will be editing the permissions to add or remove somebody and inadvertently click the link to inherit from the parent space.  But that parent space doesn't have them as an admin!  So they essentially lock themselves out of their own space and I get a panicky call -- "My space disappeared!  What happened to it?"

                     

                    For our R&D teams, we customized our LDAP so that it builds departmental user groups and updates them automatically based on the relationships in PeopleSoft.  Then those LDAP groups are synced over to Jive, and the R&D teams then use those user groups for permissions instead of individual names.  But it's a little kludgy and the sync sometimes quits working.

                     

                    In some other conversation on here awhile back (but I can't remember where), I remember someone saying Jive was working on being able to populate user groups based on profile field values in addition to just listing names. (Curtis Gross, was that you?)  I don't know where that stands, but it would really help solve the problem of having to deal with that middle ground where you want to provide access to a large group of people but not everyone, and where the membership of that large group is constantly changing.

                      • Re: GSD vs. Internal Comms Communities

                        Hey Dennis - That may have been me.  Taking the concepts of 'admin groups' and expanding the functionality is something we have been looking into.  It isn't in the short term roadmap, but I would place it in the medium term.  The concept would be to give the 'admin groups' a bit more functionality akin to the community permissions, and what I mean by that is having whitelist / blacklist functionalities for adding users automatically rather then relying on manually maintaining the 'admin groups.'   Sounds a bit like the work you have done to customize LDAP as well.

                         

                        Thanks for the story as well, it's interesting how a story from a real scenario can highlight where there is a need / flaw in a product.  Great way to get a point across.