Stronger Together

Using an Internal User Group for Success

Andy Schmiechen
Andy Schmiechen
Published in
8 min readJan 28, 2017

--

Have you struggled getting user buy-in for your latest Salesforce process? Implementing a major workflow change and need champions on the ground? Is IT giving you a hard time about that Outlook plug in?

My company leveraged our user base to support a major overhaul of our business process and built further support for the Salesforce platform. You can take the lessons that we learned, and apply them to building your own user group.

At my company, when we started using Salesforce, we used Cases to manage our Opportunities. Why? It’s a long story that I don’t want to get into, but let’s just say, it’s a good lesson on why you shouldn’t let executives dictate technical requirements. About a year or so into using Cases for Opportunities, we realized that the case process couldn’t keep up with our changing business needs. We worked with great consultants and developed a plan to move from cases to the Opportunity object.

The transition itself is better left for another discussion, but as we planned the transition, we realized that this was a major overhaul to the way 80% of the company worked. From an implementation standpoint, our Admins couldn’t do this alone. If we dictated to our users, it’d be met with resistance, we’d certainly miss requirements, and ultimately have failure.

One of our implementation consultants, Kelly Leslie, suggested we put together an internal Super User Group. A group of users who’d become highly trained, would champion change, spark new ideas and provide candid feedback. The idea of a super user group was to ingrain the team into the culture of our organization.

Here’s how to get started

1.Group Charter. You need to figure out what you want the team to do. Are you using them for a major initiative, or will they be an ongoing, standing, team? Then document what you want them to do in a Group Charter. The group charter isn’t too different from a traditional project charter you might write. Some areas you may want to include your charter:

  • Goals/Mission
  • Expected Results
  • Ground Rules
  • Meeting Frequency

Need an example to get started? You can look at my employer’s Charter, used by permission.

2. Job Description. Next, develop a team member responsibilities and characteristics document. Consider that the people on your team will be working for you. Advocating your needs and the processes you build. This is essentially a job description, laying out expectations for being on the team, team member attributes, time considerations, behavior and official communications.

Thanks again to my employer, you can use our Responsibilities & Characteristics Document as an example.

3. Find your team. Publicize what you are doing, and ask for volunteers. Attend staff & department meetings to talk about the team. We’ve often seen that people won’t volunteer with a general call for action. So, don’t be afraid to seek out people you think would be a great fit. Be selective, make sure your team members will meet your desired characteristics. And, make sure that your team members bring a diverse background, both across your organization and culturally. Don’t forget to make sure your team members have supervisor approval to participate.

4. Kick Off. Hold a kick off meeting. Walk through the team charter and responsibilities documents, ask for feedback and further input. Begin collecting agenda items for the next meeting. If your team needs some education, consider leading the team through a few Trailhead modules, or begin the discussion of about a new process.

Sounds pretty easy, right?!

Well, not exactly. It’s actually a lot of work. Keeping your team engaged and on track is the hardest part, but it’s an important part of being an #AwesomeAdmin. We ran our super user group for about 2.5 years. In that time we had great successes, but also learned a bit about how to make teams better. These are all actual mistakes we made, so now you can learn from my team’s mistakes.

7 Lessons Learned

The Two-Pizza Rule

When we built our team, we had 13 business units plus 7 people on the implementation team. Can you imagine working with just the schedule of 20 people, not to mention validating feedback and input from all those people? We really needed a smaller group.

Don’t make your team too big. Jeff Bezos, that guy that founded Amazon, uses the two-pizza rule. If your team can’t be fed on two large pizzas, then the team is too big. Studies have shown that small teams have more effective communication, greater trust, and less fear of failure.

According to organizational psychologist J. Richard Hackman, the more people added to a team, the more exponentially complicated the work gets. Interesting that it’s not the problem, it’s not the solution, it’s the work that get more complicated. A simple example of this, I showed our Admin team a simple way of adding help text to Salesforce standard fields by adding a non-writable custom field on the page layout. Easy. Problem Solved. Yet, ideas started flowing from the other admins. You could make it a Visual Force page. Change the text to be red. Or a pop up on mouse-over. Yes, all of that resolves the problem too, but sure adds complexity.

I’ve used the two-pizza rule successfully in a lot of my project teams. My only exception to this rule is the addition of the implementation team. Add as many people from the implementation team that are minimally required to understand the needs of the team.

Does that mean your team has all the answers? No, probably not. Don’t be afraid to bring in subject matter experts when needed.

Listen & Engage

Make team meetings about the group. You should be listening more than talking. One way to do this is to have have an end-user walk through a new process demo. After all, the users helped define the success criteria, right? So they should have no issue walking through a demo. Having someone else do the walk through, gives you, as an Admin, the chance to listen to feedback and see how smooth the process goes.

Engage with the team to assemble agenda items, and actually run the meetings. How? Certainly during the meeting, but don’t forget to Admin by Walking Around (#SABWA). Talk with your users on an individual basis, grab coffee or lunch.

I like the idea of doing a job shadow, too! Ever have someone who never seems to put information into Salesforce the right way despite numerous trainings? Go shadow her on the job. You might have an A-HA! moment where you find out why the system doesn’t work for her. Find out what’s really going on. Use that information for agenda topics.

You Can’t Do Everything

Make sure what you are working on brings value and matches up to company goals.

As we progressed, our team was bursting with new ideas. At one point, our feature and enhancements list was nearly 300 items long. Everything was on the list, and it was just impossible to make a dent. You’ll have to pick and choose what’s most important. You may want to consider whether or not you also need an executive governance or steering committee to decide what major projects to work on. Need help creating alignment between goals and projects? Develop a V2MOM document between executives and the team.

Deliver

Once you’ve decided what you’re going to work on, make sure you deliver on it. Nothing frustrates someone more than when they’ve take the time to assemble an idea and present it to the team, only to have it just sit on a list indefinitely. Be sure to communicate timing, put it on a road map, how it’s been reviewed, and estimated implementation timeline. Everyone knows priorities shift and projects can get bumped. Just be sure to communicate with your team why ideas get delayed.

Rotate the Team

Consider setting up term limits, but don’t change out the group all at once. In our 2.5 years of the team, we only changed members when someone left the company. Almost makes it sound like being on the team was a prison sentence! Over time, you could see enthusiasm drop, members didn’t make meetings a priority, and meetings turned into griping sessions.

At the same time, there were staff members outside the group who really wanted to participate, but we just had no room for them. You really hate to turn people away who are expressing enthusiasm for what you’re doing.

New team members will bring in new ideas, enthusiasm and approaches.

Stay Focused

Keep your focus on Salesforce and your mission. Don’t try to tackle too much. As our Salesforce platform grew, the User Group started asking somewhat off-topic questions about other systems integrated with Salesforce. We were integrating Salesforce with Office 365 SharePoint, SQL Databases and our accounting systems. We thought that adding these other systems into the agenda would be beneficial. We renamed the group from the Salesforce Super User Group to the Technology Super User Group. In the end, it actually lead to a loss of focus, and less results. We also alienated those who’s main interest was just Salesforce.

Have Fun

Finally, as with any team, make sure to have fun. Celebrate your successes, learn from your failures. Build your team culture through contests, games, team building exercises. One of my favorite things to build camaraderie is to get people out of the office in some kind of activity or participate in volunteer opportunities.

Success with the Super User Group

What were the results of using an internal super user group? It turned out that the end product was better in all aspects. After training our super users and working on our major initiatives, we surveyed our team. Here’s what they had to say:

“This began a much needed dialog our needs.”

“Provides better workflow and consistency to the process”

“Provides better organization and tracking of process”

“I’m just so happy we now have training that makes sense.”

“I really appreciate the usability enhancements.”

I’d love to hear from you! Do you have a super user group? What are your experiences? Has anyone else used this method? Leave me a message in the comments!

--

--

Andy Schmiechen
Andy Schmiechen

Senior Solution Engineer @Salesforce, @WI_SF_Saturday Co-Leader; former User Group Leader. All words are my own.