Context Sharing

[00:00:00]
>> My next point is shut up. [LAUGH] It's say less. And I'll start with well this blue box down here, a big temptation and this actually I think comes from my engineering background and my schooling background is to show your work, right? Let me show you all of the things that I did to get to here.

[00:00:23]
It's, on one hand, it can be credibility lending of, look at all the background I did in this, but for the most part, it's self-aggrandizing, whether you mean to be or not, where it's like, look at all the work I did, look how important this is. Don't do that.

[00:00:40]
I actually don't care how you got there. I hired you or I work with you because I think you're an expert and a domain expert. Just tell me what you want me to know, right? Please say less, right? So now that you have an audience in your mind that you're talking about, I'm talking to my team.

[00:00:58]
I'm talking to a bunch of product managers. I'm talking to customers. I'm talking to developers. Think about the context that they need the minimum viable set of context for them to get to the point that you can actually start talking about your plan, or whatever you want out of them.

[00:01:17]
So, here's a couple of very breakable rules that I'm gonna throw at you. If an audience all knows something that you're about to tell them, then don't say it. Why are you saying something that everybody knows and has acknowledged and is okay with? You do not need to share any of that context.

[00:01:35]
There's some companies that love to say like, well, what if someone in the future is gonna read this talk because I didn't have time to ask somebody. I don't know I'm not slowing everybody down in that maybe someone new might read this someday, okay? If none of the audience knows something, and is it's critical to your message, those are the things that you need to set in context sharing.

[00:01:57]
So let me contact share and contact sharing for a second here. [LAUGH] Contact sharing is basically the idea that you're gonna set enough context on whatever you're about to tell them. Whatever your point is, whatever you want them to do, it's enough of say, okay, we're gonna migrate from server less to Kubernetes.

[00:02:20]
Let me tell you about what enough about what server less is and what Kubernetes is so that you can understand I'm doing this and I'm trading off for this, right? And I want your sponsorship of this to go forward with this particular project. If you're talking to a bunch of a group of engineers that have been working on a serverless platform for 10 years.

[00:02:37]
Has sever less been around that long? Probably. Anyway you don't have to tell him what Serverless is, right? Please don't tell them what Serverless is cuz you're probably wrong and they probably know better than you, right? But if you're talking to a bunch of executives ,you probably need to tell them why this is different and why it's important to them.

[00:02:54]
By the way, this can be really expensive or doesn't scale the way you want to or it's unpredictable and it scales to zero and blah, blah, blah. All those terms probably need definition for your leadership if it's critical to your message. If they don't care about scaled to zero means, then don't tell them.

[00:03:09]
It's fine. So that's what I'm talking about when I'm saying context sharing. How much lead up in your doc do you need before you actually get to what you're at or in your meeting as well, right? So yeah, the next rule here is if some people know it and it's important to it, you can give a short summary and then links are the most wonderful thing in the entire world.

[00:03:32]
It's like, hey, here's a two sentence blurb about what Serverless is. If you need more, I wrote an entire treatise of this. Here's the dock. Click here and then use that dock to send everybody. If you care to know more about here is everything you've ever wanted to know.

[00:03:47]
But I'm not gonna put it in my critical path of getting you from, I don't know anything about this to I agree with your point. And if context just isn't important to your message, just leave it out. Just don't share it. You don't have to say it. If it cannot be left out because for some reason either someone thinks it's important that it needs to be there, or it's tangentially related to something grander that it needs to be in there.

[00:04:15]
I don't know, whatever reason that you can think of, just use links, write a different doc, get it out of the critical path, and send only the select few that need to see it off into the wilderness. So, say less. This is what I'm saying when I'm saying less.

[00:04:35]
I'm gonna tell you why I'm gonna tell you say less. Hopefully, most of your just nodding is like yeah, probably, I wish people would say less than these particular kinds of dogs. But well, yeah, here's my example. Here's kind of what I was saying. If you're saying like, we're moving off of Heroku and we're gonna be moved on to, GKE, Google Kubernetes engine.

[00:04:54]
Let's say we have two different meetings one is gonna be with all the tech leaders and one is gonna be with a bunch of product leaders. With the tech leaders you probably don't need to explain what a dyno is, you probably don't need to explain what GKE is, what pods are, what services are, what's secret storage is.

[00:05:08]
They probably know, they probably know better than you, you can leave all that part out and just be very cursory like, we're doing these things and this is our proposal and get quickly into the technical details. Because that's probably what they want and it's probably what you want, right?

[00:05:21]
If you're sharing with product leaders, you need to probably spend a decent amount more time telling them, this is everything that we're talking about. This is what a dino is. This is why it's really expensive. This is why salesforce doesn't support Heroku anymore. RIP to the real one.

[00:05:35]
And this is what Kubernetes is, right? And this is why we'd wanna be on there. And then you talk about big product decisions of, okay, we're doing this because this enables us to scale it a cost or this enables us to do a bunch of other things that we wanted to do that enables product things.

[00:05:53]
And this is why we it affects users for it again. But you're gonna wanna be able to root this and this affects, these stakeholders and these users, maybe it's the stakeholders that allows our dev team to move faster eventually, right? But do you understand what I'm saying with context setting and saying the least amount of important and make sure it's cater to the audience that you're talking to?

[00:06:14]
Okay, so why? Have you ever been in a meeting or just got derailed on something so pointlessly tangential that you just wanna die? I'm not talking about anything specific here.
>> [LAUGH]
>> Like weekly, right? It's a huge pet peeve of mine because it's such a waste of time for so many people, myself included and it's frequently because the product manager whoever's running the meeting, went on.

[00:06:47]
They expose themselves to this tangent and then someone's like, I'll take that tangent I'm gonna run with it and not give it back to you, right? So if you reduce surface area you reduce the ability of people to kind of take these and run these in different directions.

[00:07:01]
It's the same thing with like docs, right? if you do all this context setting and then you're talking about stuff that's actually not really related. If you start getting into like, what is secret store in a doc to product leaders, they're gonna might rabbit hole on that. And there's like a 10,000 comment thread on this one thing that's, no one caress.

[00:07:20]
I don't actually put it on HashiCorp. I don't care. I don't care where the secrets are. All right, write it in the code. I don't care. Now my problem, it's security is problem, right? So that's what I'm saying was say less and reducing surface area. It helps focus discussions.

[00:07:35]
It helps keep people on task and moving in alignment to the things that you want. I'm just saying all these things because someday one of you is gonna be my coworker and hopefully one of you is going to do this. [LAUGH]
>> I think you're always gonna have people that are gonna find context out of nowhere and I'll pull it out and I'll steer the conversation in some other direction that has nothing to do with what you're trying to accomplish.

[00:07:57]
>> Absolutely.
>> Because people are the worst.
>> They'll beat that horse.
>> Yeah, this is reducing your exposure to it. And that's kind of the point here, is you do have people that are gonna be like that and they gonna do it no matter what you do.

[00:08:10]
And so, there's nothing you can do to help that. We'll talk about how to like rerail meetings when we get to that section. But in these particular cases, you're trying to help the people that wouldn't normally otherwise derail it get caught up on a subject that's not really pertinent to what you're actually trying to do.

[00:08:30]
This is another thing, that don't convince people who don't need convincing, right? If you go into a meeting and there's consensus already about what you're proposing, end the meeting and get the hell out of there. You already got what you wanted, right? There's some PMs that will try and go in there and is like, well, I prepared all of this stuff, I'm gonna tell you anyway, right?

[00:08:51]
And it's just like, I did work, therefore I don't feel fulfilled until I express it. It doesn't matter, right? If you already have consensus this was actually no from a text of this course to several of my former and current colleagues and one of them Brian Harrelson who's actually the editor of the JavaScript spec.

[00:09:11]
This is one that he really harped on that I thought was really good. When you see bits of consensus caught, I was okay, we agree on that, and we agree on that, and then you start putting bits of consensus together, and then you end up with consensus. I thought that was brilliant.

[00:09:27]
But in particular with, once you see total consensus, just call it save this is good. And if you can end it or if you can move on to the next thing, right? But do not spend a bunch of time with a bunch of things to convince people when you have already won the battle, right?

[00:09:43]
Because what ends up happening and I have seen this before, when you start trying to convince people of something you start telling them is, well, here's the downside, but let me explain to you why the upside is good. I didn't think about that downside before, now I'm unconvinced of your point.

[00:09:59]
Sometimes it can be useful to kind of walk through it, frequently, it's pointless, and so you shouldn't have done it in the first place. And that your faults for running the meeting on the dock incorrectly.
>> I feel like some of that could be like CYA for the future, too.

[00:10:13]
Cuz you gotta be like while we kind of discussed this as a potential con, right? Though my approach.
>> Yeah, cover your butt, cover your butt to CYA by the way.
>> What's that?
>> Not everyone knows all the acronyms, so CYA, is cover your butt.
>> Come clear, cover your what?

[00:10:29]
>> Your butt.
>> You're basically indemnifying yourself for the future and saying, well, I did discuss this and you didn't say anything at the time, so I would assume that you kind of took that as he as yes.
>> So what you're talking about was essentially a variation of inoculation theory and I have a slide on that as well.

[00:10:50]
It frequently just doesn't come up, right? And so all exploring, all the hypotheticals is rarely of use. Sometimes it's, frequently it's not.
>> Got to know the context.
>> Yeah, it depends.