 introduced my name is Sarah. I am currently the VP of engineering at ReactiveOps and my one job is to advocate for engineers. You hear the word developer advocate but I am an engineering advocate and I speak up for my engineers. But before I was a VP I was an engineer just like many of you and my one job was to work hard to go to work every day and solve challenging problems to help customers and other engineers to learn from people to teach people and on top of all that try to keep up. And unfortunately the result of all my hard work always seemed to be that the organization shortened deadlines gave me more work made me work longer hours. I was stressed almost all the time right as we heard about this morning and Burnett was a real threat. And I always had a hard time trying to decide why my hard work translated to others negatively right because these results did not align with what I thought I was achieving. So why is there that disconnect between myself as an engineer and other groups, other audiences? I started thinking about it when I wrote this talk and I think it all comes down to misaligned values. So what we're going to talk about today is value in engineering work. So first of all let's go ahead and start by talking about what value is and how we may calculate it. When I first proposed this talk to my engineers at React Bobs, one of them said to me you cannot devalue engineering work. It has a value that cannot change. And he was right, but what he was talking about was actual value. Actual value is something that is intrinsic to an element, an object or a piece of work. It is factual, it is well understood meaning that we can measure it and we know it and it cannot be changed by outside forces. So this is the type of work that my engineer was talking about, this value. But there is a second more complicated type of value that a lot of us don't think about and that's perceived value. Perceived value is all about how something is experienced, a perception of somebody. It's very much based on individual point of view. I have a different perceived value than all of you. Some groups may have different perceived value than others and that can be manipulated very highly. I want to give you an example and somebody said please don't give a cheesy example. So I went and I actually did the opposite and I'm going to base this on cheese. So I'm going to show you, oh no. Okay. So I'm going to give you two pieces of cheese. On the left, I think your left is a block cheddar, something you'd find at the grocery store, a craft, a cracker barrel, you know what it is. And on the right is an artisan aged cloth bound cheddar. You're looking at these two things and based on your experience, your perception, you are assigning a value to each of those cheeses. One may be your jam, one may not be. So let's talk about what's going on. The actual value of those cheeses is static factual thing. It is maybe the type of milk, the fat content involved, the texture, meltability, age. All those things are inherent to the cheese. And we can look on the back of a label and we can say this is the nutritional value, this is a fact. And in all reality, those two cheeses that I showed may have the same actual value. So why are some of you thinking that the other, the cloth bound maybe have a higher value? It's all about perceived value. So I want to kind of get your juices flowing about what may influence perceived value. In the case of cheese, one of them may use unconfined dairy animals. If you're all about animal rights, that may be appealing to you. Some may be made on family farms that pay people living wages and that could be something that you really care about. One of them you may pick up at your local farmers market and it is supporting somebody in your community. That's important. And it goes down the list. Somebody takes great care. And at the end of the list, I mean, one of those cheeses just looks way more delicious than the other one, right? And that really depends on you. You could like something that's just going to like make you a delicious mac and cheese, or you want something to show in a fancy, you know, get together at your house. So what we're really talking about when we say actual value versus perceived value, we're talking about features, right, the features of the cheese are the actual value versus the benefit somebody may reap from them, which is the perceived value. So perceived value seems like a really interesting concept, right? So how may we calculate or predict what a perceived value of something should be. In marketing, there's this concept that I honestly, I learned when writing this presentation because I wanted to do some research about why this may be the case. And it's called the perceived value equation. And the hypothesis is that the perceived value of something is roughly the ratio between the benefits and the cost of something. So something is going to benefit you, but there's always a cost attached, right? It may be price, it may be trouble that you have to go through to get it, etc. And the perceived value that you have is going to be a ratio of those two things. So how might you maximize a perceived value? How might you make sure that people perceive your work or your product as really highly valued? Well, you kind of, I mean, all of your engineers, you can look at this ratio and say, how can I maximize that? The first thing you can do is either really increase the benefits of that cheese, of that engineering work, or you can drop the cost, right? And you can play around with those two values. But what in the world, when we're talking about our engineering work, is going to shift perceived value. There's two things that I think are really important. The first is the audience. Again, I said, perception is an individual point of view. So if I'm presenting something, my work or cheese, the audience is particularly important. They're going to have a different perceived value. And then the second thing, which we're going to talk about today is communication. How you communicate the benefits of something is going to increase the perceived value. So if we loop back to the cheeses, you know, I pick up the craft block of cheese, it just says cheddar on it. I don't know the benefits there, right? I just know the inherent actual value. But I pick up the clothbound cheddar, and it's going to tell me this is an actual description. It's raw cheese crafted by hand in small batches on a farm nearby. Like, all of a sudden I'm picking out words. You guys not seeing this? Oh, sorry about that. All of a sudden, you're seeing all these words that are basically triggering your benefits, right? You're saying, oh, I really care about the farm down the street. Oh, raw milk is way healthier for me. And so you're seeing the benefits communicated to you. So let's go ahead and talk about communication. And now we're done with cheese. We're going to talk about engineering work. How do we communicate value? So in communicating work, what we're doing, when we sit down to write a blog post, a tweet, presentation such as this, or even just a pull request of your work, what you're doing is sharing your experience, what you've gone through with that work, right? That is how we communicate engineering work. So now I want to tell you about a specific type of communication that I think many of us are have written in our past and we are kind of guilty of putting out there in the ether. It's what I call up and running communication. And this is a term that I came up with. It may be very wrong, but it is what I call it. And maybe as I share this with you, you can either tell me whether or not it's a good term. But what is it and what do we mean? So up and running is a term I think is very familiar in tech. We've heard it before. There's certainly blogs that you've read or presentations that you've seen that talk about up and running. But I want to show you a particular example of what I think it means. So I think of it as a race. This is Usain Bolt running 100 meters. In the beginning, on the top row, you've got him in the starting blocks, preparing himself, building tension, setting his mind right, and then he's up, right? The gun goes off, he's up. And then running, to me, is moving in the right direction. Unfortunately, up and running is a very ambiguous term. Running could be anything in that race. And I think there is a misconception that up and running covers an entire topic. It covers beginner, intermediate, and advanced in a topic. So if I say up and running with Kubernetes, you're like, oh, that's all I need to know about Kubernetes. Well, that's not the case. Up and running is your first application. You're moving in the right direction. You're not a Kubernetes expert, right? This communication is based on becoming a beginner. So it's focused on getting started. It doesn't talk about any upcoming hurdles that may happen in the race. It doesn't talk about the advanced technique that you may need later down the road to beat somebody else or to, you know, regulate your breathing or anything like that. And we don't talk about the finish line. We don't talk about what the ideal end state is, right? We are just talking about the beginning, which is useful in some cases in frustrating others. In the wild, what this looks like is this. I have a couple titles. Hopefully the colors have translated. I really like neon, so I just went with it. So I'm going to read a couple of them. Ansible up and running, automating configuration management and deployment, the easy way. Docker is easier to use than you think. AWS made easy, painless container management with GKE and Kubernetes. And my very favorite, a weekend, a Rails app, a Kubernetes and a manager, which I feel like somebody should be walking into a bar. But what I want you to notice when you look at these titles is that there is a common theme here. There is an emphasis on something very specific. And what that is, is simplicity. We are not sharing challenges. We are not sharing roadblocks. We're not sharing the hard work that we went through to learn this information. All the time that we spent. All the people that helped us. And we're talking about saving time and learning something quickly and being able to implement it and showing people potentially the power of something. That's the emphasis. We already talked about what we omit. We're not even registering the implications. What's going to happen when you hit scale? Or when you need to go to production? Or when you need to be multi-regional? Or you know, when your boss asks what the heck does this mean? We're not talking about that. We are just sharing a simple introduction. To loop back to my title, up and running culture is slightly different than up and running communication because culture is simply a pattern of learned and shared behavior of a group. Right? It's something that we have absorbed into ourselves as our identity of engineers. We've seen this communication and then we feed into the system. Right? So the engineering communication culture is such that we go out there, we look at blog posts, we learn from them. And at some point when we finish a project, when we learn something, we write a blog post and we feed it back into the system. And it's constantly depositing and withdrawing from this library. Right? That's our communication culture as engineers. And just like memes on the internet, you know, the definition of a meme is a thing that is copied and shared. We are emulating the behavior of communication that we see. So if we have Docker is easier to use than you think and somehow we learned something from that, when we go to write our blog post about Kubernetes, we're going to say, oh yeah, Kubernetes is easier to use than you think. Right? We're going to emulate what other people have communicated in our behavior. And that's when it becomes up and running culture. It is, so this is the crux of my presentation, it is a specific type of communication that we participate in that is focused on introductory level material. It glorifies speed, it tries to simplify topics, minimize effort, and inherently try to explain something that's really scary and make it less scary. And then we drop the mic and then we say, you know, worry about the advanced stuff on your own. Right? But why do we participate in this as engineers? When I started to think about the perceived value equation, I thought to myself, what are engineers doing when they communicate their work? Well, they're min-maximizing it for themselves, for other engineers. They are trying to lower the cost to themselves by saying it's easy, it's fast, but they're maximizing the benefits. I learned this awesome new thing. It's going to change my work life. It's going to be effective and impactful. Right? So I have both raised the benefits and lowered the cost, which should potentially skyrocket the perceived value for engineers. But why is this a problem? Well, it's the audience. I'm going to posit that it is the audience. You are communicating to yourself and other engineers when you communicate your work. You're not taking into account the audience of other people that may be experiencing your work. So you are in fact miscommunication, miscommunicating the value of your work. So I want to talk to you about a couple, just a couple of audience types that may be picking up on your communication and valuing things very differently. So the first is decision makers. These are CTOs, CEOs, VPs like myself potentially, who are removed from engineering work and their job is to take in information and make decisions for your company. When they hire an engineer, a very expensive engineer, what they want their expected benefits in their perceived value equation is that you're going to come in and you're going to learn challenging topics. You're going to extrapolate from your experience, problem solve, troubleshoot, do all the hard stuff, and then innovate for my company and make sure we change. That's what I want if I hire you. Those are the benefits that I'm looking for. Unfortunately I caught your blog post that said Docker is easier to use than you think. And what you just told me is that these topics that you're trying to work on are very easy. You didn't need that experience that I paid for and potentially these problems in the community are already solved and all you're doing is implementing. Right? So through that communication, that up and running communication, unfortunately you have dropped my perceived benefits. And so what I do with the equation is say well heck, the benefits communicated to me by your work are much lower than I expected. So to keep the same value of you, right, I hired you and I need to make you useful, is that I need to drop the costs to make the value stay the same. I have to drop them a lot. And unfortunately what that turns out to be is that I shorten timelines. Right? Because we're expecting this work, Docker is easier to use than I think. It should be fast, right? The problem is well understood. This should be not a challenging thing for you to solve. I then also say well you've got this handled. You know Docker and Kubernetes and you deployed to it in 24 minutes and you know potentially an Azure walked into a bar. These teams should be smaller. So I'm going to hire for a position that's called DevOps engineer which covers everything, right? Because all of this is easy so you can do all of it. And by the way I'm going to give you new work, more work because the tools that you are communicating to me about have made your life easier and the automation is going to take away all that work you have to do. So because you communicated to me that the benefits are lower than I expected, I am going to do everything that I can to drop the cost involved. And this I think is why all of us are really frustrated that our bosses are piling work on our desk and telling us you know Docker should take you a weekend when in all reality that may not be true. The second audience that I want you to think about are beginners. This is really important because when beginners are starting to learn in our career field what they're going to do is go on the internet and they're going to look at your blog posts and they're going to watch your tutorials. Potentially they're going to look at a presentation and they're going to take back another perceived value. Unfortunately because you told us that Docker is easier to use than you think and I as a beginner really struggled with Docker. I really couldn't even get it installed on my Mac. I didn't know what an image was. I had to search on GitHub to try to figure out what an example Docker file looked like. I spent 45 minutes really struggling with basics and you told me Docker is easier to use than I think. You are setting unrealistic expectations. You are telling me as a beginner that my time was wasted that I potentially am dumb because I cannot figure out what you did and so I'm seeing unrealistic expectations. There's an inequity in resources. You have your colleagues at work. You have an expert friend in Kubernetes who can help you learn. Beginners don't have that but they see that reflected in your work without seeing the challenges involved because in your blog post you didn't mention that you had a buddy who knew everything about Docker who told you that. Then the lack of future thought again up and running communication is about the beginning. We are presenting it as if it is the full topic but it's not. It's just the introduction and so what this beginner sees is a potentially a beginning to their learning about a topic but then you haven't touched on the challenges, you haven't touched on what's next, the advanced topics that they need to learn so again they're lost. This is really frustrating and so the perceived value equation for beginners looks like this. Well heck the cost of this work to me just went up really heavily because it's not easy and yet you're telling me that it is and so my perceived value goes down. So again you've communicated to me through up and running communication that the value of your work is less than it is. These are just two groups. There are many other groups that you need to be thinking about sales, marketing, recruiters, customers, other types of engineers. Your family at home like there's all kinds of audiences that you need to take into account because they have a different perceived value equation. So I want to talk, this is my last section about the methods that we can use to communicate our work better. The first is set expectations. At the beginning of your blog, your talk, your tweet, make sure that the audience knows what they're in for. Say this is a beginning to understanding and potentially the first application of Docker, right? Don't say Docker is easier to use than you think because we're not learning the entire topic. We're learning a beginning intro. Tell them as explicitly as you can. Leveling. This is an interesting one. I am very guilty of not leveling. I didn't level this presentation, although it's challenging to do. But I want you to clearly label your communication. If it's beginning, intermediate, or advanced material, say so. I went to KubeCon last year and I thought it was really valuable that they leveled all of the talks. So they said this is a beginner talk, this is intermediate, this is advanced. Because then, it doesn't matter what my context, what my point of view is, I can look at it and say, oh, this is a challenging concept, right? This is something that I need to invest a lot of attention in and really, you know, this is the piece that's going to fit into my entire journey. People will be able to self-select your material. The thing I really don't want to happen is for you to write an article that says Docker is easier to use than you think. And a CTO seeing that and telling all of their engineers, hey, this is beginner material, this is very interesting, right? You need to set the context for people who aren't you. You're going to affect engineers at other companies by communicating these things. I want you to share the rest of the story, like Steve Harvey. I want you to communicate more than just up and running. You need to communicate advanced topics, anything that you've learned. Push past those starting blocks. Talk about implications, consequences, next steps. My favorite, favorite, favorite thing in blog posts is when you say, next time we're going to talk about X, right? Because that means to me that this isn't the end of the story, that there's something else that I need to be aware of because I've just learned something brand new and I need to know about the challenges involved later. So talk about the rest of the story. Focus on the benefits. Unfortunately, you do not have too much control over other people's costs, that's going to depend on their situation. So you need to sell the benefits as much as you can. Tiffany talked about this in the earlier presentation, which is the big sell. You need to make sure that other people understand the benefits of your work. So when you're talking to your boss, you're saying, this is exactly why my work matters to you. This is going to meet your quota. This is going to make sure that we get across the finish line on that particular project. If you don't accurately represent the benefits, unfortunately, they will become a cost to you. Be authentic. I think lots of people talk about this. Do not photoshop your work. Share the trials and tribulations. If you're going to write a post that's Docker is easier to use than you think, somehow you need to be able to make room for all the times that you failed, that your image didn't compile or the container failed when you started to run it. These are all natural things, natural progressions of our learning and our work, and they need to be shared and made clear. Your failures are as important as your successes. Some people understand this. Site your sources is something that I like to say, because, again, a beginner does not know where you've got your information. It's not even possible that everybody who wrote a beginning up and running Docker article all learned on their own. There's no way that you, I mean, maybe you read the code base and you did, but it's not likely. You have learned from somebody else. You have pulled from sources, whether it be code, whether it be tutorials, whether it be a friend. So make sure that you share those things so other people can benefit. And not to use value judgments. And this is really hard. Don't judge your work for other people. When you say things like easy, simple, quick, you are assigning a value judgment to your work. You're not giving the other people a chance to take a look at it for what it is on a factual basis and determine whether or not they think it's worth something. And this is important for all audiences. And then my last ask of you is to try to use precision in the way that you talk. We're all engineers. If you write code, if you maintain a system, precision is really important. Precision in your word choice is extremely important. I would prefer that you, like if don't say docker is easier to use than you think, say these commands, these 10 commands will help you begin to understand docker fundamentals. That is far more precise. And it communicates exactly what you want the audience to get out of it. You are not value judging anything. So that's my spiel. The last most important thing, again, that you can do for your communication, making sure that other people value your work is to make sure you take into account the audience. If you are presenting for a decision maker in your company, you need to use certain words. You need to give certain benefits. You need to make sure that they understand what they're getting out of your work, what they are getting out of your work, not what you're getting out of it. If you're writing onboarding documentation for new people in your company, again, it's not about you. It's about them. What do they need? How do you show them the benefits of this way of learning what you do? If you're writing an article for your marketing people, who's your audience? Potentially your customers, right? And they are going to have different benefit needs than you as an engineer. So I want you to think about the perceived value equation for each of your audiences. I want you to practice empathy, put yourself in their shoes, think about their point of view. Where are they coming from? How are they going to see value in my work and then address their concerns? Hopefully what you've gotten from this talk is a couple of things. One, it is very important that you communicate your work well. And the second is that this up and running communication that you've probably seen in the community and potentially you've participated in is not working well for us. And I would prefer that we start moving toward communicating in more effective ways. Thank you. Thank you, Sarah.