I try to write a blogpost after every Salesforce.org Open Source Community Sprint. This is #8 in the series… if I counted correctly!
This week, I spent a lot of time reflecting on the word “enablement.” I was searching for something that connects documentation, marketing, and empowerment. I have been working on the Data Generation Toolkit Open Source Commons community project for about a year and recently turned my attention to getting the word out about this amazing effort.
What is Data Generation Toolkit?
A group of volunteers came together in Fall, 2019 to address the gap in Salesforce tools/processes for generating fake data to use in Sandboxes.
Why would anyone want fake data? Here’s a few reasons:
- You want to show off your slick new Salesforce tool, but your contact records contain sensitive information, and you need to keep them confidential
- You are building a “home” for data that don’t exist yet (like a sign up system for future events) and you want to see how it would handle 10,000 registrations
- You are testing automation for your org, and you need a reasonable number of Households (and all related data, like people, donations, outreach, etc). Making those by hand would take hours (or days).
Our project’s instigator persuaded our project’s lead developer to create a tool to solve just this problem. The tool is called Snowfakery, and it’s free! The only problem is that it’s a bit hard to use for Admins (like me) and there’s a whole world of Admins out there who could benefit, but aren’t quite snooping for a solution to a problem they … don’t know they have.
So, this team of intrepid volunteers forged ahead, creating a robust “guide to seeding sandboxes” (kind of a choose your own adventure style resource with lots of great advice for tools and processes), a bunch of recipes for common Snowfakery data requests, and the beginning framework for an Admin-friendly user interface that would take Snowfakery to the next level of usefulness.
Which brings me to this Sprint…
This is the 4th Sprint for the DataGen project. I’ve written about this project here and here (the first link is from the previous sprint; the second link is about learning to use Snowfakery). The “problem” is that this here blog – as beloved as it is – doesn’t really reach the “general public” (that’s not my goal) but for the Data Gen Toolkit project to reach its full potential, we need to get the word out! We’ve been working on a mega-doc for almost 9 months and we’re on the cusp of releasing it. Heck, we need to make a birth announcement!
So this week, I set my sights on enablement.
What does enablement mean to me? Well, it’s a term that I started to hear from the “software sales” world, which is about getting customers to actually use the products that they bought, so that they don’t decide to return them! But to me, it means more than that…
… perhaps because the Salesforce.org Open Source Commons community has cultivated such a contagious sense learning and empowerment.
In my work on this project, I’ve been introduced to…
- Github – which is a platform and system for collaborating on code and docs with version control
- YAML – which is a programming language which you use for writing Snowfakery recipes
- Markdown – which is a kinda programming language for writing prose with formatting (despite not having a formatting bar)
- CCI – which is a framework and set of tools for moving Salesforce data and metadata between orgs
- Snowfakery – which is a new tool for generating tables of related, unique, valid, but totally synthetic data
- VS Code – which is an application that you download onto your computer to organize and modify files in a Github repository (I think it does other things, too)
- Command Line – which is a built-in thingy for running code on your computer (definitely does other things, too)
- Governance best practices for making “commits” and “pull requests” (which is what you call it when you finalize a modification to a code file in a Github repo)
- and I’m sure many other things that I’m forgetting!
Here’s an attempt at what enablement means to me, and how that relates to building power.
This working definition begs the question: what is access?
Frankly, I’m still struggling with this. I just don’t think it’s realistic or sustainable to ask Admins to spend as much time learning these tools as I’ve done! At the same time, this time has felt sooo generative and well-supported – I want anyone and everyone to join in the fun! I have made what I hope will become long time friends, and there are so many people who are there to catch me when I falter. Also, it is so fulfilling to learn AND give back to the community at the same time. See ya later, comfort zone!
What has made my personal access possible? Prior experience to coding (I took a course in college), knowledge of/invitations to these type of events, access to computer and internet, time (through my job), a network of mentors, timezone and language, social/religious commonalities with other project leaders, and inner strength to push ahead even when I felt frustrated at times. I’m sure there are things I’m overlooking – feel free to add them in the comments. Yep, access is complicated.
So, in my revised definition, I added “support and invitations.” That feels right.
Too often in the Salesforce twitterverse, I see a well-meaning, but ultimately unhelpful, refrain of “pull yourself up by your bootstraps” and “rags to riches” stories, without a lot of support to back them up. Not everyone can do Salesforce Saturday, Trailhead Tuesday, Road to Ranger, etc etc etc and still fulfil all of life’s obligations. And that’s ok!
What does support look like to me? Acknowledgment that new skills are hard. Realtime or same-day troubleshooting. Encouragement to celebrate wins. Realistic expectations. Sharing a phone number for those moments when you literally need to “phone a friend.”
I want to build a culture where everyone stays on their learning edge and mentorship edge while contributing as much as they want to. As a leader, I’m working hard to make sure that everyone also sees the impact of their contributions, whether it’s a one time effort or a year long commitment. I’m starting see evidence that that culture is thriving, but it’s mostly thriving within a small echochamber and it’s time to “branch” out (har har, that’s a Github joke, for those of you keeping track).
That’s where marketing comes in
In my definition of enablement, we need access, support, and invitations to use changemaking tools. Plus, the changemaking tools have to, ya know, exist. We’ve got the tools and I think we have support figured out (lots of friendly people, and well-crafted documentation). Access is ever a work in progress, but we won’t make that progress if we don’t start doing more public communications. We haven’t put a lot of energy – yet! – toward inviting the general public (in this case, Salesforce Admins at nonprofit, higher ed, and even for profit industries) to learn and use these tools. It’s time to kickstart that aspect of enablement, and I knew just who to call.
I invited my friend Jill, marketing genius, to lend her expertise to the cause. Together, we crafted a plan (Jill insists it’s a timeline, not a plan) that includes generating blog posts, social media posts on multiple channels, targeting influencers, webinars, conference abstracts, etc. I learned so much about how to craft/frame a message and test it to see what resonates. Unfortunately, we can’t use Snowfakery to generate all of this content. We’re going to have to build it the DIY way. Fortunately, there’s a great crew of contributors ready to roll up our sleeves and get to work.
You’ll here more on the blog, from time to time, about the Data Gen project and how to make it relevant to changemakers at small orgs. Big plans are in store, my friends! We’re not quite ready to say what they are (yikes! a cliff hanger!), but new ways to learn and get involved are coming. Until then, I hope you’ll join me in grappling with big concepts like enablement and access. Share a comment about what they mean to you! This dialogue is only just beginning.