Nobody knew what anyone else had built
The first real AI problem on our team had nothing to do with model quality. It was that dozens of people had each built something genuinely useful, and none of them knew about the others.
That’s where CSAssistNOW came in. All applications I have developed with AI end in the word “NOW” because it is directionally accurate to the time it takes to build, it is catchy, and almost a little bit annoying. It’s just a shared place to publish and find the prompts and skills people build.
There are four reasons we wanted this.
- Visibility - Once a department gets past a certain size, AI use can very quickly become fragmented. Someone automates a renewal summary, someone else builds an account brief, then another builds a risk status dashboard. A library helps make the work visible and legible. You can see how AI is actually being used vs. how it’s supposed to be used, or what you see folks using it for on social media. Basic social features were added to try and capture that (I used this/ Upvote / Propose Update).
- Recognition - I think this one matters more than it sounds at first pass. Curiosity needs an audience. When someone builds something that takes a ton of manual work off their team every week, that should be visible, credited and celebrated. A simple and subtle leaderboard for most used skills creates some basic and healthy gamification.
- Freeloading (Intentionally) - Most people don’t want to engineer anything, which is completely acceptable. They want the thing that already works. The library lets them come in, grab the skill someone else built and get value the same day. This is super important as teams continue to try and get more done and focus on things that provide customer value. If you are stuck troubleshooting a skill to query data from six different locations, crossing your fingers that they are the right places and the right data points, that is actively subtracting the amount of time you can spend with your customers.
- Governance - Each skill goes through a review before it publishes. This shouldn’t slow things down. It should ensure leadership endorses the way the problem is being solved, the skill is technically sound and it is something we want other people to be benefiting from. A governance process that is deemed to be “red tape” would cause drops in engagement, and engagement is the fuel for a social library like this one. It is critical to get this one right and ensure the time it takes from submission to sharing with colleagues (or declining and providing feedback why) is fast. As much clarity as you can provide up front goes a long way with understanding the bar of acceptance prior to submission.
What ties all four together is smaller than it sounds. When a skill clears governance and publishes, the library posts it to Slack. Internal tools die if people have to remember to go to them. This one shows up in a channel you are in, with the builder’s name on it, and a link that takes you straight to the thing you want. That one post does all four jobs at once; people see what is being built, the person who built it gets credit in public, anyone who wants it is a single click away, and the post itself is proof that it has been reviewed.