Making Performance Allies

So, yeah, we're on our last talk of the day now.

It always goes by pretty quick. Did everybody enjoy the conversations in between the talks too? Did everybody get some good conversations with people, get to meet some folks?

Yeah, again, it's one of the great things about this event is all the different types of people. You've got people working in media and hospitality and like the, you know, government and public sector space.

And then you've got people like Ethan who have worked in every single one of those actually. So there's just an incredible breadth of experience here.

And I've had the opportunity to chat with Ethan in the past. I know he's done an exhaustive amount of research on, you know, the all important concept of like, how do we actually make this stuff stick? Right? Like that's the thing is like, it's easy. I always say the technical bits to, in my opinion are the easy parts. The hard part is how do we go back and drive that change to actually happen in our organizations in a way that's going to stick long term. And so Ethan has done a ton of research on it and I'm very much so looking forward to this last talk. Ethan, thank you.

Hi everybody, this is Web Performance Allies. I'm Ethan Gardner. I'm a full stack engineer and educator from Cincinnati, Ohio. As Tim mentioned, I have a diverse array of experience in multiple different industries and you can, you can find me online@ethangardner.com, real simple, just add.com behind my name, you'll find me.

So this talk is about the people side of web performance and I find that this is the missing link. To be able to do more performance work and connecting business to web performance metrics is incredibly important to this. And also we're going to talk a little bit about how to overcome some negative perceptions that people might have when working with engineers.

Now I'm going to focus on the interaction between engineers and non engineer roles throughout this presentation. So if you don't hear a lot of like heavy, heavy tech talk, that's okay.

But before we start, let's pretend like we're in a meeting with a software vendor and you hear them say, wow, you're our largest client by far.

And based on the various different job roles that are in this meeting, everyone might hear something a little bit different. For example, client relations might hear something about getting priority customer support or marketing might hear something about getting features on the roadmap.

And engineers, well, we're typically seen as the geeks and nerds who come in and Express concerns about the things that people are so excited about.

This Persona here is based on me, actually.

So that's not what people want in an engineering partner. Let's talk about what they do want. About 10 years ago, I was getting my master's degree in education and my master's project. I did a literature review of research articles. And the gist of these research articles was employers were asked what skills they expected, but engineers joining the workforce for the first time were lacking.

And I believe that these five soft skills are the key to unlocking web performance allies. So these are ranked in order by number of mentions in about 40 different research articles that I reviewed. One, we have communication. Two, we have teamwork, followed by creativity and problem solving, project management and organization, and fifth, and finally is documentation.

Now, this is the most important slide in this presentation, but as I mentioned, this research was about 10 years ago. And the good news is I went back and prepped for this conference. I reviewed more literature and more research articles.

These skills are very much relevant today. So even though that tech has changed a lot in the last 10 years, the soft skills will stay with you for your entire career. Let's talk about that first skill, communication. How you say things matters.

So you build and burn through social capital with your interactions and you can be seen as more abrasive, like this guy here, or you can be seen as someone who has a gentler delivery.

And sometimes that's challenging to do, especially when you get busy.

I once had a manager say to me, ethan, don't say no, say not right now. And this really extrapolates the meaning. If you extrapolate the meaning behind that. If you say no, that shuts down any future communication. You've already burned that one soft skill if you say no. Whereas if you say not right now, that leaves the door open. It's still a no, but it leaves it up to interpretation as to why it's still a no.

Let's talk about advice I got from another boss. And here's how it can apply to web performance optimization. He was really happy with me as an engineer. However, he said, I wish you could think more like a marketer.

And this was great advice because at the time I was working at an ad agency, I was embedded as a technology in that marketing world. And one mistake I made early on with my web performance journey is I framed everything about the end user where really, in most cases my customer was marketing. So I needed to cater my communication to that marketing user. So how did I take my engineering visor off I started to frame something as relevant to marketing, but benefiting my user in the end. And so I started to do it like this. Marketing opens new doors, performance keeps them open. This is that teamwork aspect. I framed it as a joint venture. Teamwork is soft skill number two. So this is perfect.

And one strategy I find is to be able to search for common ground with people, be relatable. So look for things you have in common with people and I want to share this with you. So here's how we can make our message heard. Even in the most contentious relationships between different software, different disciplines, we can always find something in common. So we all have our own versions of a metric that we're trying to measure, as you see here.

Quote number one I found on the marketing subreddit, which isn't one I frequent very often, but it says if you can't measure it, you can't prove if it's working. Followed by and this is actually from Andy's session description on Loaf, which happens tomorrow. If we can't measure it, how can we improve it? These two things are strikingly similar. So really, to make inroads we have to figure out how our version of IT relates to the other person's version of their IT that they're trying to measure. And sometimes finding that it is easy. Marcy's talk earlier today told you all about the intersection of accessibility and web performance.

And there's other professions or other job roles that have natural alignment. So for example UX research, they focus on a metric called time on task. Basically how long does it take a user to complete an action on a site and they measure that time. Whereas we in web performance we have many time based metrics. So naturally, as we're condensing all these metrics and presenting the user with things faster, that automatically reduces that time on task because it helps that user move through an interface or a workflow more quickly.

Another thing they do is they focus on a metric called user error rate. Now we have metrics in web performance about UI stability. So that user error rate is measuring how often a user makes a mistake or clicks the wrong thing in a assigned task. So if we're providing the user with a stable, responsive UI that reduces that error rate element because they're able to click on the things that they intend to. However, sometimes finding that IT that I mentioned isn't easy and in this case it's best to have a conversation. So there's two avenues I really explore when I'm having a conversation with people.

One is business and job related challenges. And the second is personal interest. Let's talk about that personal interest. So this is grounds for being able to establish that common ground with people and also to help me figure out what analogies might be appropriate in explaining some of the advanced web performance concepts.

And one question I love, this is actually my favorite question here is has there been friction working with engineering in the past?

Because this informs me how much nurturing do I need to do in order to form allies with somebody? So if somebody has great experiences working with engineering, I might not have to do too much, it just might take off naturally. However, if someone has maybe not the greatest experience working with engineers, I might have to take a little bit more care into how I develop that relationship.

I want to show you a silly example of a commonality here I discussed last night with Tammy and that is our love of all things googly eyes. Because googly eyes make everything better.

It doesn't necessarily have to be super serious. And sometimes that commonality that we find with people, as this case is, it doesn't have anything to do with web performance or why we're here or work. It's just something from our personal lives that we connected I want to share with you about the early days of my web performance journey at my last company. So for a little background here, I know there's a lot of people here from Google and Cloudflare and other large companies with very performance oriented cultures. Well, I've always worked at small companies that maybe didn't have a huge budget for web performance tools. Maybe they didn't have a web performance culture.

So this is the case. At my last company I was in the media industry and there was no awareness of web performance at this company.

There was no budget for tools. And this put my creativity and problem solving to the test. That was skill number three.

So I started to have a conversation with people. In this case it was marketing. So I asked them for a list of competitors.

And I know that marketing cares about the product and the competition so they can figure out how to position our products against other people in the marketplace. And I care because I know that speed can be a competitive advantage. But this started that conversation. It showed interest in their work, which is an essential piece of trying to form performance allies. And marketing was more than happy to lend a hand. So what I did with this information, I made a report here. So this is what you're looking at on screen is the web performance article leaderboard.

I made a report that was very similar to this and I circulated this to my CEO. So I made it real easy to understand just with that Lighthouse esque one score rating. And my CEO was really taken in because I showed our brands ranked among our competition and sometimes we were last, sometimes we were middle of the pack and very rarely were we first.

But when I sent the email to my CEO, the CEO, I credited marketing for their help with this. I cc'd marketing so they had visibility into what I was doing.

And there was three immediate outcomes of this.

As I mentioned, there was no real performance culture.

So what I did was I got executive buy in because no CEO likes to hear that there's a product out there that does things a little better than them. And the executive gave me the direction to focus on quick wins. Now this is that project management and organization soft skill which is number four. And the other outcome or another outcome of this is that marketing became a teammate.

I painted them in a favorable light and it became less of an us versus them mentality which I've had my run ins with marketers in the past. So it helped me try to see how we can benefit each other in this web performance journey. And I also secured a small amount of monetary budget, I should clarify, not performance budget. So monetary budget to be able to pursue more performance tooling and invest in performance more. And the longer term outcome of these interactions here was that over time, about the course of two to three years, the performance information started to show up in company slide decks. It started to show up in all hands meetings, in things I knew were going to be shared with the board of directors.

So even though that took a long time to really materialize, it all started here with this teamwork exercise.

And once we start to get some successes, we want to build on those, we want to keep these conversations going.

And one way I know I can do this is I can ask people what's their current work versus their challenges and do those two things align?

Because sometimes they don't. Sometimes they might be working on something that's time sensitive and that might take them away from working on their biggest challenge. And I know that in that case I have two ways to help. So one, I can assist them with their current work and help them get through that more quickly so they can get back to focusing on their largest challenge. And then the other thing is I can help people with the things that they can't get to. I want to figure out what metrics are important to them and do I as an engineer have the skills or tools to be able to help. It's important with this not to just wait for that JIRA ticket. Be proactive, show interest, and take initiative.

And one way I can do this is I can go shopping for ideas. Once I know if there's metrics that are important to people, I can go shopping for ways that I know can shift metrics.

So I can look@wpostats.com or web.dev case studies.

These are great resources that help you with that creativity and problem solving aspect. Because sometimes there's people out there in the marketplace who have already shown how they can move metrics with web performance, and I can just borrow those ideas and implement something similar in my case. So people love when you can solve problems for them and come to them with ideas.

And you can also in some cases correlate web performance to business metrics if you already have the tools and the data to be able to do that. So if you already know, that's a great thing because then you know what metrics to move.

Well, unfortunately, it's not always that easy. So if you don't know that relationships, you need to dig deeper. So as I mentioned my last company, I was at a media company and I came across this article from web.dev suggesting that there was a relationship between visitors revenue and ads, and the media company was ad supported. That was a major revenue stream for us.

So this got me thinking about ads and web performance. What was that relationship? And so this is that creativity and problem solving, that soft skill number three. Again, as it turns out, these slow ads is not a unique problem.

I was able to find all kinds of stuff from The Atlantic, from web.dev, akamai People, Inc. People trying to solve this slow ad problem. And if you're not aware, the problem with ads and the reason why they're slow is that that fulfillment process that it takes to get a banner ad on screen can sometimes spawn hundreds of requests. So that results in lots of long tasks and network activity. So here's what I did with that problem solving ability. I took this as a problem statement. Now, you notice there's a lot of words in this, but really I'm trying to frame this up as an argument that's relevant to the Adopts department. Adopts, if you don't know, is responsible for ad inventory and revenue on a media site. So the highlighted portion where it says it means fewer ad views, that's the part that's super relevant to them.

And what I did with this is I love this template here, by the way. This is called Hypothesis driven design or hypothesis driven development. And it's a simple belief remediation and outcome template. So you can plug things in into this template and that makes sure that you can validate and test things with experiments. It's a great mechanism to be able to do that. So in our case we believe that. Here's our belief, faster ads have an impact on user engagement. So if we prioritize the fastest ad partners we will see here's our outcome, better overall ad performance and increased user engagement. And as I mentioned, test this, validate it, make sure it holds up. So here's how we did.

We did a study, collected analytics on advertising partners and the size of the circle here represents the volume of requests.

So you can see that partner A, which is that blue dot on screen, bigger circle, sent more requests. They effectively created a virtual traffic jam with the other ad partners on the site.

So that showed that maybe they weren't the best fit for us.

So they were also sending very low value bids. It was just a bunch of lowball offers for our advertising space and they only had their ads placed on our sites 0.9% of the time. If you compare that to partner B, which is that orange dot, Partner B had a higher win rate, higher value bids and less bids overall. So that cleaned up that web performance problem I mentioned. And there was four different outcomes that came from this. So one, we removed that partner A.

Two, adopt started to see us as an asset. As I mentioned, people love when you come to them with things that can solve their largest problems. We helped them investigate their largest problem in a way that solved it was a blind spot for them. They weren't aware of this information. So we tried to help them solve how to maximize revenue. In this case, there was no change in ad revenue. But by removing partner A, that opened the door to get other higher quality partners on our site. And as I mentioned, it reduced those long tasks and network activity. So we started to see an increase in user engagement which helped move metrics for other people like marketing. Unfortunately, not everyone will believe you. There are skeptics as you're presenting this web performance information. So I'm going to show you a few tactics that I've employed. So one thing I mentioned, people often see us as geeks and nerds. We can acknowledge that in our communication to people we can say, I realize this might seem like nerd speak, but performance can really make a difference. So sometimes if you let them know you're aware of that perception in that first part, that helps them hear that Second part. So this is that communication piece that I mentioned. You can also show them what users are saying about slow sites. So if you work on a brand that's large enough, you can probably find some examples from people online talking about your exact product or company.

If not, you can go crowdsource that information.

So I went to Reddit, I typed in site slow frustration and I want to share four examples that you can use.

So example number one, on screen, the person calls the product and you don't have to be able to read the whole thing here, but the person calls the product unusable garbage, followed by a sentiment of that company must not care.

The second example on screen calls the product awful, followed by I'm not sure how much longer I can deal with it.

You have that how do I cope with this awful product?

These next two examples, they get even more extreme.

And with those first two examples, try to imagine how much more difficult it is if that's the perception of your brand. Right.

That is a hard hurdle to be able to jump over. So these next examples, they get even more extreme. This first one on screen. So example number three, if you're keeping score at home, calls for the termination of employees. So you just shouldn't be able to be working if you can't make a fast website.

And this fourth and final example hopes that the entire company goes out of business. So I can't imagine that anyone wants to be lumped in with the likes of these. But it does illustrate how people perceive these web performance issues.

As people are using digital products, another thing we can do, we present a lot of quantitative data to people. We collect information all the time. I love this book. So it is called Making Numbers Count and it helps turn quantitative data into relatable terms.

So I will show you a little bit of what I mean. Interactive milliseconds make millions, but they don't make sense. This Milliseconds make millions is a reference to the Deloitte study of the same name. And that unit of time, milliseconds also comes up in many other sources, such as Jakob Nielsen's usability engineering book. And to give you an idea, this presentation is 3 million milliseconds long. Nobody thinks about it like that. So it's not a familiar unit of time to people. And that's what I mean when I say milliseconds don't make sense. And remember, we're framing this for other non engineering job roles.

So if you know how to frame this information in a way, that's relatable to people. This will tick that communication box, which is soft skill number one, as you may recall.

And I'll show you what I mean with this milliseconds thing.

If you clap four times in one second.

So 1, 2, 3, 4. 2, 2, 3, 4. That was probably a little fast, but. 1, 2, 3, 4. 2, 2, 3, 4.

3, 2, 3, 4, 4, 2, 3, 4.

Thank you to our conductor Stoyan here.

We're clapping every 250 milliseconds in that case. And when we talk about milliseconds, especially in something like inp, we're trying to get people to care about a unit of measure that is smaller than the time between each one of those claps.

Again, that's just not a relatable number to most people.

So what can we do instead? We can be the interpreter of data. So instead of saying, Our INP went from 370 to 160 milliseconds, which, by the way, great win, kudos to you if you achieve this. We can now say before users were tapping buttons in frustration and waiting for feedback.

I'm willing to bet everyone in this room has had that experience.

Now they get a smoother experience that's over 50% faster.

I mentioned that we can use that personal interest piece as well.

So say, for example, I know that somebody watches track and field or they follow the Olympics. We can now explain that previous example as that the time difference we made up is greater than the gap between first and last place in the men's 100 meter sprint at the Olympics.

And that has been the case. I went back to, I think, the 2012 Olympics, and that difference between first and last place was less than the INP, or sorry, greater than the INP.

You can also use this storytelling ability to be able to explain these metrics themselves. So I'm going to tell you a story here.

I'm in New York City on New Year's Eve. This is post midnight a number of years ago. And seated on the train, there's a woman next to a man and she's just giving him verbal jabs. She's asking him questions like, where'd you get that tie? Did she get that for you?

Well, after a while, someone on the train says, hey lady, why don't you leave him alone? And she says, because he's my ex fiance and he cheated on me.

Well, finally we get to the woman's stop, the man's still seated, and she gets up, you hear the doors go ding, she tosses her hair, she turns around, says, Happy New Year, loser.

And then the doors don't open.

She sits there and waits and waits, and then finally the doors open. But if we're trying to portray this woman's frustration with that, this is like the physical equivalent of inp. She's waiting for the doors to open. There's her visual feedback, like, I can go get on my way. That helps illustrate if you have stories like that to tell about the psychological aspect of some of these web performance metrics, other strategies.

Halloween's tomorrow, so we're going to talk about skeletons.

A number of years ago, I was in a skiing accident and I broke my arm and I needed follow up X rays every four to six weeks. So my appointments, I'd go in, I'd get my X rays, I'd go to the exam room, the medical assistant would come in, pull up my X rays and then leave the room. So I'm in the room waiting for the doctor, the nurse practitioner to come in and I'm like trying to figure this out. I'm like, nope, not a radiologist. I don't know, those just look like bones to me. Well, finally, nurse practitioner would come in or the doctor with a pen on screen and be like, ah, right here. Yes, you see it's still broken.

You have more healing to do. So we can apply these same tactics that the doctor or nurse practitioner did with the pen to the charts and graphs that we use to tell stories.

So if you notice here we have like active users. There's six different countries on screen and this presents information, but it does not tell a story. So this is just data that we're looking at right here. Instead, what we can do is we can say instead of active users, we can say that the US user base is four times larger than the next five marketplaces combined. We can highlight the United States and we can show the important information.

So instead of somebody wondering, like, why did this guy send me this? We can actually help craft that story to the part that's relevant to them. And this, something like this might help inform business decisions in terms of like, where to set up infrastructure or markets we can develop. So this is more about communicating web performance metrics to other people.

We can also provide guidance to people. So I haven't mentioned that fifth soft skill, which is documentation that's about to change. So we can document what constitutes a good third party versus a bad one. As I mentioned, I was at a media company. I knew from my conversations with people they always wanted more third parties, like more data, like more insights, more Segmentation, personalization, all that stuff. Stuff.

So I started to avoid that defensive like, yo, we can't do any more third parties. Like we already got plenty.

Instead, what I started doing is trying to help people decide what's a good third party versus a bad one. And this ticks that documentation soft skill box. And I also provided them with a pasteable script that they'd be able to send to a software vendor. I actually crowdsourced a little of this on the web performance Slack channel. I'm not sure if anybody remembers years ago, but it's a pasteable script that they were able to send to a potential vendor. And then I was able to review things asynchronously.

So this helped me scale my impact as an engineer.

But more importantly, I was able to provide value to people even when I wasn't in the same room as them.

Another thing we can do is we can make team working agreements.

If you're not familiar with what this is, it's a living document between you and other people or other disciplines that define the parameters of relationship. So how do we handle disagreements?

What as Harry mentioned, like, what is the dashboard of record? Like, what are we comparing when we actually look at some of these performance metrics? What are the expectations of being a good teammate and when do we reevaluate this? So this helps take some of that emotion out of disagreement. So that builds that teamwork aspect because you have an objective thing to point to if you ever get into a disagreement with somebody. So that is extremely helpful if you already have something that's negotiated in advance of, hey, remember this, we have this resource that we can use to help mediate this disagreement and you can sneak other web performance things in that are important to you.

Okay, so I've talked a lot about soft skills.

I'm big on teaching other people how they can manage their own continuing education with stuff. So let me see what I can do to help you focus on the things that are going to be the most impactful for you. I am going to communicate things in a hopefully familiar way to everyone in this room. I would assume everyone here is interested in web performance.

So we have two different types of data here. We have field data. This is things like peer feedback, performance reviews or things that we've noticed, maybe behaviors of other co workers.

We also have lab data, so a survey or self assessment of where you fall in this spectrum of soft skills and building allies. So field data, as I mentioned, feedback and observations. This is actually stuff I've received so that maybe you Focus on constraints and feasibility instead of working on shared outcomes. So I would say, absolutely, I'm guilty of this because people often come to me, hey, Ethan, what's the level of effort for this? Is this possible?

And sometimes, y', all, I answer that question even when that's not the question that's being asked of me.

So another thing, conversations feel transactional rather than collaborative. Especially if I'm in a hurry.

If I get flustered, I'm just like, give me the essential information that I need instead of like this long drawn out meeting. So I do want to rush through things. Sometimes it might feel a little transactional. Another thing, strategic decisions might move forward without my input.

So if there's something I feel like maybe I should have been involved in and maybe I wasn't on the meeting invite, I had noticed that in the past.

And as I mentioned, we also have that lab data that can complement things as we're trying to improve our ability to build these web performance allies. So much like a synthetic test, this has a very short data collection window. You take a sample quiz. The one on screen is from the Via Character Institute. There's others out there. I'm not plugging any particular product, but this is the one I'm going to use for this presentation here.

So you take this quiz, you get a rank of things. I know this is kind of hard to read. So here's my top five.

Love, humor, love of learning, honesty and judgment.

So I would emphatically agree with this. We're going to talk a little bit about how that number five skill or that number five character trait of mine might impact some of my soft skill ability. Then we have the diagnosis phase.

So just like you're trying to figure out why a site or an application or or feature is slow, you could diagnose opportunities for your own skill development. So we can figure out where are the opportunities to build allies. What's situationally appropriate.

Sometimes this might change if we're looking for a new job versus trying to move up at a particular company or prepare relationships.

And could a specific soft skill be part of the solution? You want to understand why the situation is. What the situation is is.

So for me, the growth area, teamwork. As I mentioned, I have that judgment trait and that means that I need to understand the why behind things. I also feel like I need to be able to agree with the why. I take in a lot of data and sometimes if I'm not on the same page, it's hard for me to commit to a solution. So that hinders my ability to be seen as a good teammate. In some case. This is me like on stage, warts and all, in front of everybody here.

So then we come up with a plan. I want to improve my relationship with the product team in this case and I give it a timeline. So I have some tasks to do in the next three months. This is like deciding what performance interventions we're going to take. Like we've already figured out why the site is slow.

We're going to prioritize the things that are most meaningful for us to be able to get a better product. In the end, that's what it's all about.

So this is also that project management and organization soft skill. Because we're setting that timeline, we give it a finite window.

We want to prioritize. Remember the Team Working Agreement. If you have teamwork to work on, the Team Working agreement is a great resource because it tells you exactly what the expectations are of you in a performance concept. You can extract the bullet points, you can assess how you perform and how consistently you do things that are in this Team Working Agreement. You can also go outside the house, as I like to call it. So the Team Working Agreement's an internal document. You can find real world examples. A great source of this is the contributing MD files which are in many GitHub open source repositories as well as if the project is large enough. There are how we work repositories that describe what collaborating on a particular project is like on screen.

Here we have this one from tc39 who's the keepers of the JavaScript language.

I think their example of how we work is awesome.

Please go check it out. So what we can do is we can pull out things that stand out from these how we work or contributing MD files. One thing, collaborate early and publicly. I want to seek feedback. I want to make sure I'm aligned and not making assumptions with people as I'm trying to build allyship.

Also be empathetic. Phrase disagreements as questions and not assertions. This one I think is awesome. And then be a contributor. We can share ideas. As I mentioned, people love when you share ideas with them in a way that addresses their largest challenge. So back to this guy here. If you remember him from early in the presentation, his quote was I'm concerned about their ability to scale and the edge cases we might encounter. The framing that disagreement as a question might look like this.

How can we work together to make sure this approach scales smoothly and handles the edge cases we care about well, that uses that Shared ownership language of we and together. This is team inclusive language. So just that perception of you, if you phrase it like this, will probably improve how you're portrayed as a teamwork with other teammate with other people also too reflect on things as you're working through this.

So did you end up where you wanted to be? Should you go back and do another cycle with this? You can repeat this as many times as you want. Finally, we have communication that wraps up the teamwork how I might plan my own improvement as a teammate to people. So we talk about communication here.

I would be remiss if I didn't mention it because this is that soft skill number one, the most in demand thing that people requested.

So we can also prepare for common scenarios, reflect on what comes up repeatedly. So I mentioned that third party example with the Pastable script in that documentation earlier on. I also have an example on my personal site what I do when I'm approached with a Lighthouse score. Because you you know the numbers.

As Harry pointed out, like the score is the score.

You have real users to contend with as well. And the nice thing is you can script responses to these things over time and you refine things so you figure out what works with these explanations. It's almost like that behavior or interview process where everyone asks you tell me about yourself or where do you see yourself in five years? Chances are if you're going on an interview, you walk in with answers prepared to those questions. You can do the same thing with these questions that we get asked time and time again with web performance. So if you've enjoyed some of the stories that I've told, another thing we can do to improve our storytelling ability is I think this book is 150 pages of gold.

It would be ironic if it was like a thousand pages long because it's called get to the Point. But it's tip for succinct communication and storytelling. A lot of the things that I've done in this presentation I'm trying to implement the author, who's Joel Schwartzberg, I'm trying to implement his advice.

Another thing is that not everyone we work with is going to agree with us all the time. There are difficult personalities. So I mentioned earlier that boss that told me don't say no, say not right now. This book by Lisa Marshall called Smart Talk has a great chapter on how to say no, different tactics for making sure that no is not seen as an abrasive thing, and also a chapter on working with difficult people. So even if you don't read the whole Book. I want to call out these two chapters, get you right to the point because these are awesome resources that you can use as you're working with others.

And finally, go make some allies. You have to deliver on those soft skills. This is the key to making those performance allies.

You want to find common ground with people. If you want a low stakes way to do this, look at everybody's speaker bios, pull out some facts, you might find some things that you have in common for the networking that's coming up after this. And we want to prioritize those high impact improvements. So maybe read a book, set a goal, prepare responses to questions, whatever tactics you can glean from this. Just these are the keys to building a faster web together.

Now I hope everyone enjoyed this. Go make some allies at the networking following this. I hope you'll make an ally with me.

I thought I left my mic up there, but I left my phone up there.

How you doing? That was good. That was excellent. Thank you. Yeah, you can tell how much research and like homework you've done into this and experience in it.

So yeah, if you've got a minute, just a couple quick ones for you.

All right, so first off, timing wise, right, like, is this the kind of thing where you can expect to go home and like next week you got everybody sold, right, like then performance is good to go? Well, in your experience, how long does this take? I mean, I understand that's like a variable thing, but just to caution people, are we expecting days, weeks, months? How persistent do you need to be with this? Yeah, I mean I would say like that three month goal is manageable, right? You can go in, you can figure out did I make any ground in that three month time window. And it's a continual process, right? There's staff turnover, there's changing priorities, people get promoted, whatever the case is. So it's something that I like to do as a regular touch point, but build that habit because we're often reading the web performance stuff or new technology coming out. I would say if you can make this part of your practice as well, you'll be a better craftsperson for it. I suppose that's a bit of a defensive mechanism. The thing you just talked about, like the promotion or somebody leaves like a key stakeholder. That's a significant, that can be a significant challenge too, is baking it into the process, the way you counter that or sort of defend a little bit against a scenario like that.

Yeah, I mean, so like you look at it like a game of chess, right? You have the pawn that could eventually become a queen if they make it all the way across the board. Right. So I'm not big on just like developing allies with the quote, unquote, important people on the org chart.

So I think it's important to just, you know, be relatable to people, show them that you care. And that way when they do get promoted or move on to a different company, you don't know what role they're going to move into. Like, sure, you know, never burn that bridge. In your experience, which tends to. There's almost two questions here.

Which do you tend to gravitate towards and which do you tend to find is, like, more beneficial, the carrot or the stick? Like, I feel like some of the examples are definitively in the carrot territory to some extent. They're like showing the social feedback saying, oh, I hope company X takes them out of business. That's a little bit of a stick thing. So in your experience, do you start with the carrot? Does it tend to be more productive? Does it completely just randomly change depending on, I guess, the personality traits of who you were chatting with?

Yeah, so that's why I mentioned, like, you want to have a conversation with people, you want to. To pull at their personal interest. You can kind of get a read on people and figure out what might be the most relevant to them. All right, awesome. Really appreciate all the great advice.