A short interview between Christopher Parsons and Ellen about the necessity of explicitly communicating the 'why' behind tools and processes in knowledge management, using Turner Fleischer's use of Power BI as a concrete example. They identify a disconnect between KM creators and studio members (the 'curse of knowledge') and note that clear, novice-focused explanations also aid AI systems that consume the content.
Why are you thinking that the why is so important in 2025 in a way that you didn't when you wrote the first version of your knowledge base?
From the feedback that our studio members are giving us, people are disconnected. No matter how amazing I think we're doing in communicating our why, it's not resonating and it's a really interesting dichotomy because people love to work here because of the culture, and yet we're missing the mark on the intention of a lot of what we do. And because we have so many different unique workflows to our studio, people are now seeing it as an added burden instead of a benefit that is going to enhance their own work because it.
Hasn'T been explained why it exists and how it helps them. And Turner Fleischer.
Exactly, Exactly. And something as simple as we talk about Power bi, for example, everything we do has an associated Power BI dashboard. Those of us who work with Power BI and understand that it is an incredible visual tool to allow you to access knowledge and data easier. Our studio members gave us feedback that this was an added burden that we were now asking them to do. So then we looked through our knowledge database and we actually didn't have anything that told people what Power BI actually was for us. And so we're rewriting all of our wiki pages. The Power BI Dashboard is at the bottom. There's a Power BI wiki page now that we're creating. It's the why. Why do we use Power BI at Turner Fleischer? What is this getting you? So that it's not seen as an added burden, but it's seen as a. I want everybody to open those wiki pages and go right to that Power BI dashboard because they know the why. So that's just one example. I could spend hours talking about a lot of those examples. And the interesting thing is, to us, who have been working in KM for so long, we don't see it because it made sense to us. What we need to understand is it's like anything, anybody that's an expert in anything, it's hard to take a step back and look at it through the lens of I'm someone that knows nothing.
You have what we call the curse of knowledge in knowledge management, right? Like you can't unsee, you can't unlearn what you know. And it's hard to see it like a beginner.
Again, we have this. And honestly, like, this project is so big and it's such a passion of mine, I'm like, I'm right in it. And I'm a lot of the keeper of the writing and the brand voice, and I love it. And I was just in a meeting today where my software developers created a wiki page on a new software that they developed, obviously. And I started reading it and I was like, I know that it made sense to them, but I know that it will never make sense to somebody who's trying to actually use it.
Evan, you and I talked about this in our conversation. And Ellen, I think you know where I'm going to go. So I'm going to throw AI in for the first time in the conversation. I think we made it 25 minutes without saying AI. So, you know, kudos, good job. Kudos to. Kudos to all of us. You know who else likes context and doesn't know how? Turner Fleischer already runs AI doesn't know it. And so when you kind of take the time to write that the way that you're talking about, Ellen, and be simple, be clear, write it with a user in mind that isn't an expert, but a novice. Right? And then include context like, you're also helping AI to understand your content too literally.
The design of our new wiki page is the top of the wiki page is the why. And every single wiki page is going to have the why. And your point about coming into the company, it's so true. So a simple thing like, I don't know accounts receivable. I'm doing a lot of work with writing out processes for my project managers. So project manager will come in and they will have done it this way at their other company, or maybe they didn't do it at all. And why am I making them work with accounts receivable? Shouldn't that just be like an accounting team member doing that? Well, at Turner Fleischer, it's not. It's the project manager. And I figured that out 35 years ago. No client wants to listen to me in accounting ask why they haven't paid their bill. Because we typically have very good clients and the reason they're not paying their bill has to do with something that happened on the project. And so I was forever saying, you know, hey, Peter, what happened on the project? Because I'm trying to explain it to this guy over here. And I was like, wait a minute, you talk to them directly. And so the new accounts receivable page is, why do PMs have to do accounts receivable at Turner Fleischer? And then you get into the contents of the page and then it shows you how, right? Whereas if you don't have that context, you're thinking like, oh, my God, I took this job and now I have to do this, this, this, and this. And that's where the whole perception can come. There's too much structure, too many workflows, too bureaucratic, too right. But if you understand the why, might, you know, you realize what we've put in place again, to support people in doing their jobs and doing them more efficient.
