Preferred Communication Methods

[00:00:00]
>> So first and foremost is after we look at this, I would say, What do we prefer, right? So a lot of what I do, for example, right now is messaging software, right? Because I'm very similar, I am constantly contacting people, talking to people, helping people. And so does messaging software suit what we do, right?

[00:00:31]
Does the wiki, does the blog? So my question to all of you would be out of these four. And I think what we should do first is we should, actually here, let's do this, we should focus on a couple of things here. Messaging software is not the same as email blasts, blogs, and wikis, they solve different problems.

[00:00:52]
I think we can all kind of agree on that. So I think, for sure, we're gonna have messaging software in our stack, no matter what, right? We're always gonna have a Slack or something like that. However, besides messaging software, if I was to say, you know what, let's try and actually make this easier, let's get rid of the email blasts, let's get rid of the blogs, let's even get rid of the wikis, right?

[00:01:19]
Do you have a question?
>> No, I'm waving goodbye to them.
>> Okay, yeah, yeah, yes, goodbye, yes, let's get rid of them. Let's start from scratch. Now, we know we want messaging software, right, we know that. So that is gonna be where our real-time communication is, where are we gonna put our offline communication, right?

[00:01:42]
Because there's a valid argument in saying that this kind of makes all of this null and void in some regards. I would say the one that's probably the most helpful right now is email blasts, right? Because that's like a red flag, that's something that they at least know, if I get this, I gotta pay attention to it.

[00:02:00]
So email blasts may still be a good thing to keep, right? But this, blogs and wikis and articles and posts and stuff like that, yeah, those will be convoluted very easily, right? So if we go back to what do we prefer, the question we have to ask ourselves is how do we want our developers to access information besides within messaging, right?

[00:02:29]
In this case, you could say, you know what, we like the formatting of the wiki, because it already has a lot of our best practices and things like that in it, so maybe we move everything to the Wiki. Another thing I would wave the question here is, why did we create the blog?

[00:02:52]
And you don't have to answer that. But the main thing, again, is that I think it's very common for us in engineering to be like, okay, it's gotta go here and here, [SOUND] you know what I mean? But if we can take a look at how we're doing things and kinda say, okay, let's take a step back, there's actually opportunity to just remove things entirely, right?

[00:03:13]
So what I would say is, is if we preferred anything, we prefer messaging software for real-time communication to solve. And this is where we're gonna kinda start saying, well, what does messaging software do for us, right, to solve, let's say, new issues, right, or untracked problems. Whoa, something else just came up.

[00:03:41]
Wait a minute, untracked problems. Okay, wait a minute. So we're gonna use messaging software, but we're not gonna track our problems, right? Why I'm showing this is this is a problem. [LAUGH] This is another problem of basically saying, well, that's great that we have messaging software, but we may have another issue with inside of that, which is we're losing what you said before, those threads, that Papertrail.

[00:04:12]
So how can we solve that? Well, we just say, when a new problem is raised, we create a ticket for it and include Slack threads, simple. If we just create an issue, create a simple Papertrail that can start, right, messaging software becomes way more valuable, right? Because now, we can grab the problem quickly, we can open up an incident for it and we can keep moving, right?

[00:04:44]
And we can also say all critical information must be in the issue or ticket, not in Slack, right? So this is culture, That's culture right there. You have to be able to make sure that your developers or anyone else is gonna follow these standards. [LAUGH] Because if they don't, then nobody's gonna actually do this, right?

[00:05:22]
But now if we look at messaging software, we can say, okay, we're gonna take care of real-time communication, basically, to solve issues and stuff like that. But whenever we have something, we're going to put it into a ticket, make it trackable, things like that. Hopefully that'll solve one of the problems, right?

[00:05:39]
The second problem is when new information is shared, right, we need a article or document for that. This is also culture. What does that mean? In this scenario, developers must prompt each other to write documentation. Don't let it stay in Slack, [LAUGH] don't let it stay in Slack.

[00:06:13]
If somebody's bringing something up and you're like, this is important, right, then we should probably make sure that it's in documentation somewhere. So this is a standard that we're gonna set. If you don't do that, you're not doing your job the way you need to be for the company, right?

[00:06:32]
So again, if we look at messaging software in this case, right, we now have defined it a lot better, we now know that messaging software is really focused on real-time, right? It's focused on whenever a problem is brought up, us catching that problem, creating a trackable ticket for it, and being able to move through that ticket.

[00:06:51]
And then whenever new information is shared, we need an article or a document for that, right? So with that being said, do we feel like we need more than one solution here for the next part? If we look at it this simply and we just say like, okay, well, we know messaging software is gonna take care of our real-time stuff and trackability and stuff like that.

[00:07:22]
And we now know that developers must prompt each other to write documentation, does it make sense for us to still have this separation between wikis and blogs? Or does it make more sense to just have one and say, this is a centralized documentation platform or whatever you wanna call it, right?

[00:07:49]
The reason why I think this is a good decision is for a couple of reasons, simplicity. It's really hard when something's coming out to know what to refer to, right? Check this, check that. This removes checking anywhere else, we all know it's in the centralized docs, right? Now, where is it?

[00:08:16]
That's a different problem, we'll work on that in a second. But it's simplicity here. Now, does that mean that you still don't necessarily need the blogs or whatever? I mean maybe, right, but you've got to validate that, right? Communicating releases or new features, I would argue that this could just be a really good article, that this could be in the wiki as a release section upcoming.

[00:08:41]
And if anything, maybe the email blast just point directly to that wiki article, right? Generally serving engineering teams, well, this does that too, [LAUGH] you know what I mean? So unless we have a really valid reason as to why we're separating these two, right, I would almost propose that we just want one centralized documentation platform, simplicity around it.

[00:09:08]
So maybe what that simplicity means is that we also have simplicity around organization in the documentation, right? And that can be saying, each team gets their own section or area, right, that can be managed on its own, right? And we actually do this where I work, there's a DevOps section, and that DevOps section is like, I can do whatever I want in that section.

[00:09:42]
If I wanna put GIFs in there and make people laugh, I can do that. If I wanna actually put real documentation in there, I can do that too. But it's my job as a DevOps engineer in my part of the company to look at that and manage that area, right?

[00:09:57]
And I think here's kind of the bigger one, which is just remove the need of managing more things. If we just say we're gonna use a messaging software and then a centralized documentation platform, there's a serious chance that we could just get rid of the blog entirely, you know what I mean?

[00:10:18]
That's less, oops, that's less infrastructure for us to manage on top of literally solving people's other problems of time. And I would bet that if you went into a meeting and you said, yeah, I wanna save you time, they're gonna buy into it, because you're showing them the value they're gonna get out of it as well.