Lessons Learned Building a Knowledge Centered Company Culture
Tips for getting the most out of your Tettra trial
I know how hard it can be to wrap your head around implementing a new communications tool within your organization. In fact, not only was I Tettra’s first customer, but I led a company-wide implementation at my last job (which was not at Delos, Inc. in case you’re curious after viewing the screenshots 😀).
When I first arrived, I did one-on-ones with almost everyone at the company to evaluate all of our current tools. After those conversations, I came to the conclusion that there needed to be a connector — one place for our company “truths” to live.
After I decided on using Tettra, I’ll be honest with you, it was a long road filled with some trial and error. I tried tackling too many departments at once (my first tip in this piece!), and it was definitely a tall task to organize info from offline and online folders as well as pulling people’s institutional knowledge into docs. But in the end, the investment upfront yielded some amazing results with far reaching ripple effects that we’d never considered.
So what are you waiting for? If you’re in a Tettra trial or you’re considering one, here are my top lessons learned when thinking about team buy-in and making the most of your first 15 days on the platform.
1) Find an “easy” pain point within your customer or employee experience
As tempting as it is, don’t start with a behemoth issue for the trial. Focus on an area that already has some documentation, but perhaps it’s hard for the team to find or it doesn’t get circulated enough. If possible, choose a pain point that is interdepartmental so that your trial work doubles (or more) in value.
Once you’ve figured out your starting point, pull together the information that you’d need to create a page. I wouldn’t recommend re-writing or altering too much of the content, but you should write an intro to contextualize your choice before you publish it in Tettra.
Quick tips:
For your team demo, create and publish a few pages like the example above. Have one or two that will actually have content (or more depending on what kind of pre-written documentation is available to you), then also have some “fake” pages so that it gives people a sense of how the wiki could be organized.
2) Share with select team members to get feedback
One of the best parts of any wiki is that it’s a collaborative process, so even during this quick trial you should take time to chat with your colleagues. I’d suggest talking to a handful of writers, readers, and new hires.
Writers are the people whose content you used as a template. Bringing them into the conversation will show your appreciation of their work, and how important it is that their content is more accessible. Readers are the people across different departments that would need to regularly access these particular pages. And last but not least, talking to a new colleague will give you a sense of how to make your content the most accessible. Generally pages perform better when they’re written for a person who doesn’t need a deep bench of knowledge to be able to understand and apply the information to their work.
Quick tips:
Schedule short in-person meetings with your team, and then invite them to be early testers. Encourage the writers to update the pages you’ve created with their newest learnings, and have the readers and new hires make comments on the pages. You’ll get to see how they interact with the platform, and the pages will have more life when you present them to your key stakeholders.
3) Prep and present to the decision-makers
Before you meet with the decision-makers, there’s a few things you should prep. First, make sure you’ve incorporated feedback from the listening tour with your colleagues. It’ll strengthen the conversation when you mention individuals and their feedback, both the good and the bad.
Next you’ll want to have a roadmap of what the first version of the wiki will look like, who’s going to work on it, when you believe it’ll launch, and what you see is the greater vision overall. Being the wiki instigator, you’ll probably take on a lot of the effort early on, but having those early adopters from your feedback sessions will be helpful here as well. The good news for technical implementation is that if you’re already in the trial, it’s just a matter of inviting other team members when you get the green light.
Quick tips:
Whether it’s a conversation or meeting with your decision-makers, kick it off in the wiki! Create a page for the agenda, and start with some bullet points on why you believe this is important to your organization. Then run through the examples pages that you’ve created, while incorporating insights from your feedback sessions. Wrap up with your timeline, proposed team, and the tasks that you’ll need to make the wiki happen (writers, editors, etc).
Your key to a successful implementation is staying true to the needs of your team. So whether it’s writing, formatting, or categorizing, always take a second to step back and ask yourself (or someone on your team), “Will this help someone at my company onboard better / do their job better?”
Stay focused on those points, and I’m positive that you’ll have an awesome trial.
Have questions about this piece or need more help getting set up? Check out Tettra’s Help Center or comment below!
Photo by Peter Forster on Unsplash
