Speaker 1 Okay, let's dive in. Team wikis. Speaker 2 Yes. The knowledge hub. Or sometimes the knowledge black hole. Speaker 1 Exactly. You know, there's supposed to be that single source of truth, but, often they just gather dust. Speaker 2 Digital dust. Speaker 1 Yeah. So today we've got a bunch of stuff. Articles, notes, even someone's, like, ideal wiki structure. Speaker 2 Oh, interesting. A blueprint. Speaker 1 Yeah, but we're not just doing a simple how to. We want to get into the why. Speaker 2 Why do some work and others just fail. Speaker 1 Right. And how do we actually build one that people use, not just, you know, look at once. Speaker 2 Well, it's fascinating because the technology that's often the easy part. Speaker 1 Do you think so? Speaker 2 I do. It's the people side, the habits, the, the culture around it. That's usually the make or break factor. Speaker 1 That make sense. It always comes back to people, doesn't it? Speaker 2 Pretty much. Speaker 1 So speaking of that, one of the articles started with this cool analogy. A good wiki is like a well organized library. I like that at first I was like, okay, maybe a bit abstract, but it actually really works when you think about it. Speaker 2 It's about finding what you need easily, right? Yeah. Like intuitively. Speaker 1 Exactly. In a good library you kind of know where to go. The sections make sense. Speaker 2 Your wiki should feel like that. It's not just hoarding information. Yeah. It's making it findable, accessible. Speaker 1 Which, really highlights how important good design is. And search. Speaker 2 Oh, definitely. Because we've. Speaker 1 All been there, right clicking around endlessly in some awful wiki. Speaker 2 Scrolling. Scrolling. Is it even in here? Speaker 1 Yeah. And you just give up. Speaker 2 And if you can't find it, that knowledge might as well not exist. Speaker 1 It's lost. So true. Which I guess brings us to those, core design principles from Ward Cunningham. Speaker 2 Right. Simple, open, incremental and organic. Speaker 1 They sound a bit like buzzwords, maybe. Speaker 2 Well, they can be, but they're actually really fundamental to how, good wiki software works today. They're baked in. Speaker 1 Okay, let's break that down. Simple. I mean, that one seems obvious. Speaker 2 Yeah. But critical. We're all overloaded if it's complicated to use. Speaker 1 People won't use it. Simple as that. Speaker 2 Exactly. Low barrier to entry that encourages contribution engagement. Speaker 1 But is there a risk of it being too simple? Like not structured enough? Speaker 2 That's the balancing act. Yeah. And that's where maybe incremental and organic come in. Speaker 1 Okay. Speaker 2 So it evolves, right? Speaker 1 It grows with the team. Adapts to what you need over time. Like a what, like a living thing. Speaker 2 A digital garden, maybe. Speaker 1 I like that, but gardens need tending, right? Speaker 2 They don't just magically stay perfect. Speaker 1 Precisely. And that's why that wiki design article talks so much about prep work. Before you even build it. Speaker 2 Like what? Speaker 1 Getting the team involved. Getting by in figuring out who the key people are. The contributors. Speaker 2 Setting expectations? Speaker 1 Yes, and establishing clear ownership. Who's responsible for what sections? It prevents confusion later. Speaker 2 Okay. I'm definitely seeing that pattern you mentioned earlier. The human element again communication. Speaker 1 It keeps coming back. The best practices article really hits on this too with contribution guidelines. Speaker 2 Like rules the. Speaker 1 Road kind of. Yeah. So everyone knows how to add stuff. What a good entry looks like. Who maintains which part avoids the Wild West scenario? Okay, that makes sense. Avoid the chaos. So teams ready rules are set. What about the actual structure? The bones of. Speaker 2 It. Right. So the wiki design piece uses slights, terms, channels and documents as an example. Speaker 1 Which are basically folders and files. Speaker 2 Pretty much channels are the big categories. Documents are the specific pages inside. But that concept applies to most wikis, whatever they call. Speaker 1 Okay. But just having folders and files isn't enough, is it? Speaker 2 No, the real power is how you arrange them. The hierarchy nesting things logically. Speaker 1 Like a good file system on your computer. Speaker 2 Exactly. You wouldn't just dump everything on the desktop. You need logical folders within folders. Speaker 1 Which leads us nicely into this, Chris's ideal wiki document. We saw, the. Speaker 2 UX designers vision. Speaker 1 Yes. It was really interesting how they structured it around the actual UX workflow. Speaker 2 Yeah, like research, design testing. Very logical for that team. Speaker 1 And what struck me was how it wasn't just a theoretical structure. Speaker 2 No, it really put those best practices into action. Speaker 1 Right. Clear owners for each stage using templates so things look consistent. Speaker 2 Linking out to other tools rather than trying to copy everything. Speaker 1 In. It felt really practical, like a system someone could actually maintain. Speaker 2 A well-oiled machine, hopefully. Speaker 1 Yeah. And speaking of practical, making the content itself useful, not just, you know, walls of text. Speaker 2 Oh, definitely. The Best Practices article hammers this home, right? For usability. Speaker 1 So, like, meeting notes. What's the key there? Speaker 2 Don't just transcribe. Focus on the outcomes. What was decided? Yeah. What are the action items. Who owns them okay. And tagging. Tagging is crucial for finding stuff later. Could. Speaker 1 Yes. Imagine trying to find a decision from six months ago. Speaker 2 Nightmare scrolling through pages and pages. Speaker 1 It's not tagged or structured. Well. You're lost. Good tagging is a life saver. Speaker 2 And that applies beyond meetings to thinking about technical specs, design documents, guidelines. Right. Speaker 1 All that core knowledge. Speaker 2 The principle there is reference don't recreate meaning. Link out to the source of truth. Link to the JIRA ticket, the Figma file, the Google doc. Don't copy paste massive amounts of stuff into the wiki if it lives elsewhere. Speaker 1 So the wiki is the central index, the hub pointing you to the right place? Speaker 2 Exactly. It keeps things manageable and ensures the wiki doesn't get bloated with duplicated, potentially out-of-date info. Speaker 1 Smart. Okay, what else makes a wiki usable day to day? The articles mentioned version control, yes. Speaker 2 And comments crucial for collaboration and honestly, for saving your bacon sometimes, Speaker 1 Yeah, yeah, I can imagine accidentally deleting a whole section version control lets you rollback. Speaker 2 Exactly or see who changed what when it avoids those, moments. Speaker 1 Tell me about it. Have you ever had a version control save? Speaker 2 Oh, absolutely. There's this one time a colleague and I were, unknowingly editing the same key process document. Big changes on both side. Speaker 1 Oh, no. Collision course. Speaker 2 Pretty much. Right. But thankfully, the version history made it super clear what had happened. We can merge the changes without losing hours of work. Speaker 1 Hoo! Speaker 2 Nice. Okay, so that prevents data loss. Comments help with collaboration discussion around the content itself, right? Speaker 1 Asking questions, suggesting edits, getting clarification. All right there on the page okay. So let's say we've done all this. We built this beautiful, well structured content rich wiki. Speaker 2 The dream wiki. Speaker 1 How do we stop it from slowly dying, becoming that digital graveyard we talked about. Speaker 2 Maintenance, the less glamorous part, but maybe the most important. Speaker 1 It never ends, does it? Speaker 2 Nope. It needs ongoing effort. Regular audits. Is this still accurate updates? Keeping things fresh and clear? Ownership. Whose job is it to do that? Speaker 1 So it has to be part of the regular workflow, not an afterthought. Speaker 2 Absolutely. If it's not integrated into how the team works day to day, it will become neglected. Like that gym membership you bought in January, Speaker 1 Exactly. Good intentions. Zero follows. Speaker 2 Well. And it's not just individual responsibility. The Best Practices source talks about building a culture of contribution. Speaker 1 Okay, how do you do that? Speaker 2 Well, leadership buying is huge. Managers using it, referencing it. Leading by example. Speaker 1 Make sense? If the boss ignores it, why should anyone else care? Speaker 2 Right? And then recognition. Acknowledge people who contribute good. Speaker 1 Stuff like a little shout out. Speaker 2 Yeah, maybe even things like doc cleanup days where everyone pitches in to tidy up a section, make it a team effort. Speaker 1 I like that it feels less like a chore then more like tending that garden we mention. Speaker 2 Exactly. You can't just plant the seeds and walk here. It needs consistent care from everyone. Speaker 1 So it really circles back to the beginning. Tech is one piece, but the people, the processes, the culture. That's the rest of the puzzle. Speaker 2 It really is. So maybe a challenge for listeners. Think about your own team, your own wiki or maybe the wiki you wish you had. Okay. What's one small thing you could do maybe this week to nudge things in the right direction, to encourage a bit more wiki use or contribution? Speaker 1 That's a good prompt for me. Maybe I could make sure the notes from our next meeting actually land in the wiki. Tagged properly with clear action items. Speaker 2 Perfect. Start small. Build the habit. Speaker 1 Yeah, because ultimately a wiki is only as good as its design and how much people actually use it and keep it alive. Speaker 2 Absolutely. Just take a second and imagine all that collective knowledge, all the experience in your team, easily searchable, accessible to everyone. Wow. What would that make possible? What could you achieve? Speaker 1 That's. Yeah, that's a really powerful thought. It's like unlocking the team's collective brain. Speaker 2 Kind of. Speaker 1 All right, well, hopefully this gives everyone some good ideas. Go forth and build useful living knowledge hubs. Speaker 2 And enjoy the process. Speaker 1 Definitely don't let it become a chore. Make it part of how you grow together.