Transcript

When I was 13 years old, my mom took me with her to a meeting. So a thing to know is when my mom was pregnant with my sister, who's older than me, she ran for a spot on our local school board, and she won, and she sat on the school board for the next 18 years. And so my entire childhood is full of memories of me like reading in the back of the room during a school board meeting or sort of doing my homework with super attendants and union reps and teachers and all sorts of school district-y things happening around me.

But this particular meeting, it was at the County Office of Education, and it was a weekday afternoon, and I remember that she specifically wanted me to go to it, it wasn't just like easier on the schedule. She thought I would find it interesting. And so the County Office of Education where I grew up was actually in an old school, and so a lot of the meeting rooms were actually old classrooms. And it was actually setup like a classroom the day that we went into it. And I remember that I was the only kid there, which is not particularly unusual. But the rest of the group was a real mix.

There were a few school board members, the district secretary was there, I think my P.E. teacher was there, there were some classroom aids, and at the front of the room there was a guy with a computer. And he said he was gonna teach us how to hook a modem up to this computer and then how to connect it to the World Wide Web. So it turns out that the county had gotten a grant from the state to provide a local access number, back when you needed a local access number, and training to get more people in the school district hooked up to the internet.

The browser of choice at the time was NCSA Mosaic, and the web pages, they looked a little bit like this. Aw yeah, yeah. Right? If people were feeling a little fancier, a little snazzy, they might look something like this. Yeah. I don't know if you all remember the internet back then. It was just a lot of information, right? It was a lot of walls of texts. Stuff was pretty hard to find, it was pretty ugly, and it was so magical and so amazing. And as time passed, more and more people started getting online and we started trying to build sites that looked cool, even beyond this.

Now in the early part of this phase, I feel like people were taking the boring informational walls of texts and snazzing them up a bit. Putting in some nice images, a little bit of table action going on there. Yeah. And as time went on, the design tools got even fancier, right? Still love Space Jam. So the design tools got even fancier, and the pages got pretty, kind of busy. There was a whole period here where stuff was just really kind of dense and gross. I don't know if any of you have studied architecture or interior design, but we move to something that sort of reminds me of late Brogue, French gilded, like Rococo style. Like, there's a lot going on here. Any corner that could be filigreed, would be filigreed. It's very elaborate, it's very ornate, it's pretty hard to use. It's like, I don't know where you take a nap in here.

Now the complexity of those layouts and ornamentation on those sites, it really did push us forward in terms of browser capabilities and web standards, and just the way that we had tools to build these things. And the next phase after these kind of heavily gilded sites in the world of web design I think was both a reaction to and an evolution of these kind of sites. We started to say, "Okay, so this is really pretty, but how can I make it easy to use?" And this is when I feel like user experience starts to be an organizing principle for our work, right? Who's coming to our site? What are they trying to do when they get here? How can we help them get that done?

And that was a really new way to frame our projects, and for many of us, in our organizations we are still coming around to framing our project in this new way. And it has led to lots of really interesting, beautiful, clear, straight-forward, relatively easy to use sites. And so in only a couple of decades, we went from kind of unstyled information, where it got you where you wanted to go, but it was not particularly pleasant. And then we started adding colors and fonts and sparkles and tables, and we ended up with a lot of sites that were elaborate, but not particularly functional.

And then we sort of having been taking the best parts of both of those. Maintaining the beauty and reframing it on user experience, and ending up in a place where, I sort of think of it as the glorious age of user experience, and I feel like this is where we are now. And when we launch a site or project or a new set of features on a site or on a section of a site, when it's really focused on making things easier for the users, it feels really good. I can watch people use the new site and they're able to do more, and they hit fewer roadblocks. And maybe if we're launching a responsive site, people are really impressed with how usable it is on the phone. Everything feels like this huge success when we're focused on the user's needs.

And then a couple months pass, and I circle back to a new section or a new feature, and it's just, it's like a little ragged, a little confusing. Maybe there's some content that seems out of place, there are maybe some category names that don't make sense, maybe there are some messages that feel kind of clunky. Things are just starting to feel a little hard to use again, instead of easy to use. And when I trace it back, where this comes from, I think, usually, is that the folks whose day-to-day it is to maintain the site, whether they are content editors or designers or developers, they're making decisions that aren't in line with the original strategy for the project.

And so even though the entire point of the project was maybe to streamline an application process or to make it easier to find some program guidelines, or even just to connect users with the right phone number to call, those things are getting harder again, like the paths are getting of complicated and confusing. So I started paying attention because I notice I was seeing the same problem over and over again in a lot of different projects that I was sort of tangentially related to. I was seeing it in projects I was leading, I was also seeing it projects that I was just sort of a consultant on, I was seeing it in projects that I had nothing to do with, that my colleagues were working on.

The people who were doing the everyday work in the site, they were misusing modules to mimic things from the old system, they were not taking advantage of new features that we had built to solve those exact problems. And just generally, they weren't managing the site in a way that put the user's needs first. And I want to be clear that these projects were not like a mess otherwise. They had solid foundations, they had good teams, they had decent budgets, there was organizational support, and they had really good leaders. I think they also all had project leaders who were very focused on leading.

And as a group of people who lead projects, you know that that work requires a very particular kind of mindset. The person who is in charge needs to see the path ahead clearly enough that you can define its edges and you can understand where the team is going, And especially if the project involves any sort of internal transformation, if you're redoing your information architecture or you're converting to a responsive design, or maybe you're moving your site into its very first CMS, the project needs a leader. It needs someone who has been to the wondrous foreign country that is a CMS-managed site. Someone who's familiar with sort of the customs and the limitations and the roadblocks. You want someone who knows what you're getting into when you're doing any kind of transformational project.

But where this falls apart a bit I think, is that one person is just one person. One person who is busy, who goes on vacation, who gets distracted, who has other kinds of projects to deal with. I think the problem with the way that we tend to view leadership is it creates this dynamic where only one person is holding the vision. The rest of the team is actually freed from the obligation to hold the vision because the leader is doing it so well. And that one person, that leader can see the path and the map and the forest and the trees all at once. But when she needs to miss a meeting or the team starts branching off and taking on pieces of the project on their own, they often don't have enough information to stay in line with the plan.

And what I realized is that these sites weren't being maintained well and admins and authors were kind of doing a poor job, because no one but me understood the strategy. So I was in kind of a bad place because I had reached the same kind of conversions point on a number of different projects, and just where I needed the teams to start ramping up and taking on things on their own, I just felt like they weren't up to it. So it came to the point where I was pretty sure that the only way for these projects to succeed was for me, personally, to just micromanage the shit out of everything.

So I would edit every single piece of writing to make sure the subheads were being used correctly, I would sit with designers and like guide their hands into choosing the correct photo for a feature story, I would review the style guide with the developers and the designers before every little decision to make sure, "We're going to use this button style today." So I had planned out this beautiful, flexible, versatile system and I had resigned myself to believing that I was going to have to leave it in the hands of people who just really didn't know how to use it. I resigned myself to believing on a regular basis that my team members were kind of dumb. And here's the thing about thinking someone else is dumb.

So A of all, it's not true, it is actually probably false. The people on the teams that I am working with, they are smart and they are clever and they are experienced and they are good at what they do. And when my gut reaction is to think that they are dumb, my gut is speaking from a place of fear and ego and bile and is not really worth listening to.

B of all, even if it were true, even if someone on the team isn't a strong writer or is actually having a really hard time understanding how a new feature is going to work, how does it serve me label them as the problem? Because if I decide that they are the problem, like, "Oh, this guy is just never going to understand our new work flow", I've kind of painted myself into a corner, because where can I go from there? I don't have the power to fire people, even if I did, I don't want to, and hiring a new person wouldn't solve this problem because, spoiler alert, they also would not understand the new work flow because they'd be brand new.

So at the same time, I was coming to understand these constraints in my projects, over in my personal life I had been on a journey of discovery. I had started meditating, I got certified as a yoga teacher, and I had started paying a lot of attention to the difference between the things that I was in control of, and the things that I was not. The things that I was responsible for and the things that I was not. And I don't think really that it is possible to start focusing on that kind of stuff in your personal life and not have it sort of spill over into your professional life.

And if you start day off reading like sutras, and then you transition over into reading your emails, it's not as much of a clean break as you might think. So it used to be that I would sit down in the morning and I would open up my email and I would see that a piece of content had been entered wrong or I had asked someone for a list of something very specific and gotten back a list of just something else entirely. And my habit was to think, "It's not that hard, this person is just not paying attention, they are just being dumb."

Now I have like the Dalai Lama's Twitter feed in my ear, sitting on my shoulder, and I'm like, I can't even get halfway through that kind of thought before it gets sort of short circuited and I'm like, "The only person I can change is myself." Freaking Buddha compassion. Alright, fine. So the only person I can change is myself. What does that mean for training? What does that mean for the way I lead my projects and the way that I teach my teams our strategy?

So the way that I used to communicate strategy or projects twofold. Number one is osmosis. If you are in a room with me, you should probably just be absorbing all of the underlying strategy, via my electromagnetic field. And two is, if you're not in a meeting with me, we're gonna have a training session. It's gonna be, let's say, three weeks before site launch, it's gonna be half a day of watching someone else enter fake content into an interface you have never seen before, it will radically change the way you do your day-to-day work. But don't worry, we're also gonna give you a long unyielding PDF document to take home and study. I'm not sure how we reached the point where that became okay, because we are definitely better than that.

Traditional one size fits all instructions in training, they don't work because we're not all one size. I have colleagues working flex schedules, I've got people splitting time between multiple departments, I've got folks coming in from and going off of parental and medical leave, I've got summer interns. This whole like half day and a PDF is not cutting it. So I want everyone to take a deep breath, prepare yourselves for some thought leadership.

So I mentioned earlier that I feel like right now a lot of the web is sort of entering this age of glorious user experience, and where that's very focused outwards on the people who use our sites, I think that the next level of insights, the next sort of deepening of our practice is gonna come from turning that gaze inward. I think it's time for us as leaders and as strategists and as managers to take the empathy and compassion that we have found for our users and to put that same level of attention and detail into how we run our teams and to how we train our teams.

So what does that look like? So I think we need to look at delivering smaller chunks of training that are more narrowly targeted to individual work flows in the formats that are most helpful in context, when people need them. I think we need to give our teams the space to practice working in new setup, and I think we also need to build in opportunities for repetition without the impatience that usually goes along with watching people repeat something over and over again.

So this seems pretty straight-forward. These are not like mind-blowing ideas here. So before we dive into the details of this, I want to talk a little bit about why we haven't been doing this all along. Like, what's been getting in the way of doing this? So two things that I want to address, acknowledge, that I think we need to deal with, urgency and control.

So we're gonna start with urgency. So in the digital world, in tech, on the web, on phones and other devices, I think everything changes really, really quickly. The Pew reports on internet usage come out every year and the numbers just keep going up. 2/3 of Americans own a smartphone, the number is very similar for Canadians. People do everything on their phones. Banking, job applications, real estate searches, healthcare research, everything.

Traditionally, underserved groups, like people of color, young adults, low income, basically any group other than an upper middle class white dude, those are more and more likely to have their primary access to the internet be their phone. And there's this underlying pastiche of panic and kind of frantic scrambling underneath everything that we do that the world is moving, the needs of our citizens are moving and we are not keeping up.

So you'll note that I am not calling it a false sense of urgency. It can be absolutely real, but being real doesn't always mean that it serves us well. Urgency can be a really good momentum builder, it can be the thing that gets the ball rolling, it can sort of get us off our butts, it can get people to start paying attention. But once things are moving, urgency is this tiny little devil on our shoulders, whispering things into our ears like, "It would be faster to just make educated guesses about what our users need, instead of doing real testing.” And, “Oh it'll save time to just build this new feature now and come back to documentation later once it's done." Or, "We could finish the redesign this quarter if we just migrate all this content as is and revise it down the road."

Real talk yo, urgency lies. Urgency cares only about speed and not about quality, urgency is what makes you think that this is a reasonable layout for a form. This is an American tax form, I looked at the Canadian ones, and they are equally trash. And so I did not bother localizing this talk for you because they're all, tax forms are trash. It also makes you think that this is a decent way to explain to the public what your office does. This is what I like to call 'hot nonsense'. Urgency is this lie that tells us that it is better to have something done than to have it done well. It drives us to think that the most important thing is just to lead briskly, to just cross the finish line, to check the box.

And most of us have been working in urgency and under a deadline for so long, that we're actually pretty competent in here, it feels like some kind of normal. But we've lost in listening to urgency is any sort of sustainability. As project leaders, we always cut the corners around making sure that the whole team understands it and really believes in the goals and the strategy behind the project. So we breeze past the part where we teach our teams what this project is really even about, and then we get sort of annoyed later that they didn't pick it up.

If you want to end up finished, you listen to urgency, but if you want to end up with an excellent product, then everyone on the team needs to really get the strategy. It's the only way you're ever going to get to a point where the designer can choose exactly the right photo for a page header and the developer will build an accessible feature right from the get-go, and the author is going to include all the right categories and all the right metadata on their first try for an entry. That kind of deep, in the bones understanding, it cannot come from a training document and a webinar.

But urgency is, all things considered, a relatively easy issue to work through because it is mostly about awareness. It's pretty easy to make the argument that our work is better when we take the time to be thoughtful, and that pushing out launch by a few weeks is worth it if what we get in return is a team maintaining the site who is actually incredibly confident and skilled in their abilities. So tackling urgency is a matter of mindfulness. We have to recognize that we're getting sort of sucked in by a siren song and we have to choose differently. Control though, this is a whole different animal. I have some feelings about control, y'all. Those feelings are, I like it. I like being in charge, I like telling people what to do, I am literally standing on a stage telling a room full of strangers what I think you should be paying attention to. I like being the person who knows what the plan is, and not only that, I like being the only person who knows what the plan is. There is power there. And I don't want to give up power because I think that actually means death, that is what my ego tells me at least.

But here's the thing about control is, control lies. Control says to me that no one is smart enough to understand the strategy, that the project is going to be completely lost without me, and that a strangle hold is really the only way to steer. Control is kind of a jerk. No one understands the strategy because I haven't taught it to them, the project is lost without me because I built it that way. The only way to figure out the answer to this problem is for me personally to deliver the solution because I set myself up to be the hero. None of those things are true. Or rather, they are true because I engineered them to be true. Control says that that's the only way to run a project, though, and that's a straight up lie.

So apparently, what this comes down to is that I have decided to base part of my sense of self worth on how rigidly I control a website project. That seems healthy. So how maybe could we get away from that? Step one, unfortunately, is that we have to look inside ourselves to see kind of how we got here. I am sorry, because I know that this can be kind of a gross step, it can be kind of weird and icky inside and we would like to skip this step, but it's pretty important. I think we need to look at and pay attention to all of the really good qualities that led us to where we are. Drive and organization and imagination, and also look at some of the less savory elements that got us to where we are, like competitiveness and fear and the need to be liked. And I think we need to dig in a little bit on the parts of ourselves that we are feeding when we are in complete control of a project.

For me, being in control, being the only person who really understands the whole plan, that really feeds the part of me who is scared of being obsolete, the part of me that worries that no one is going to hire me unless I have all of the answers. That part of me sucks, it doesn't actually need more food. And so i have to make a deliberate decision to start feeding the other parts of me in a project, to feed the part of me that gets excited when a team member does really well, that wants my friends and my colleagues to have those light bulb moments, the part that is really tickled and proud when I circle back to something a few months later, I see the team that I left behind still making really good, clever decisions that put the users first.

Those are the parts of me that I want to feed. A small note, like I say you made a deliberate decision like you do it once, one time deal then you're done. That is sadly not how it works at all. I make and remake and remake those decisions all the freaking time. The fear is there just under the surface and sometimes it sneaks out and I live in that place and I make decisions from that place and then I'm like, I have a moment of clarity and I'm like, "Oh shit, I did it again.", and I have to go back and I have to decide to feed the parts of me that I want to grow. It does get easier. Like most habits, for a while, I would write every email or issue ticket or base camp message or whatever twice.

Like I would write it the way that I would normally write it and then I would be like, "Okay, step sideways, add in some grace, start from a better place, add some generosity." And I would make that message come from the best version of myself. And the thing is, when you do those revisions often enough, you can start to get that done the first time, you can keep that sort of fear and yuckiness kind of squelched down, mostly. So once we've done a little work to get over ourselves, let's look at some practical tactical ways to help our teams understand the strategy and to understand the larger goals of a project.

As I mentioned earlier, our traditional approach to training is like sitting in a room watching someone type on a screen. If you are very lucky it will also involve a very crappy catered lunch. You will have sandwiches wrapped in paper, there will be a tub of pasta salad, and of course there's always a giant PDF training manual. It is gonna be dense, it's gonna be confusing, it's 100% guaranteed to be out of date by the time you leave the room. I'm willing to bet that every single person in this room has sat through one of those trainings. I think many of us have conducted those trainings, so I need to spend no energy at all convincing you that they don't work.

There is caveat. They don't work when we do them by themselves. As part of a larger sweet, it's a fine approach, and so I'm gonna be talking about what else can make up that sweet. So the first thing to recognize is that there are different kinds of training. Learning the CMS is what a lot of us think of as website training. But the flip side of learning the CMS is offline workflow. How does content get prepared and vetted for the site in the first place? That often has nothing to do with the CMS. There's roles and staff responsibilities, like who does what.

Like Lisa was talking about yesterday, who is a steward for this piece of the website? Who is the steward for this section of content? And then there's also the overall strategy, which is a user's journey. It's understanding the audience. Why are we even doing this project in the first place? This last one actually gets skipped a lot, especially when you're talking to people who are in sort of the lower ranks of a project. Like they might get taught how to upload the meeting agendas from this organization's weekly board meetings to the site, but they never actually learn who wants them there or what they want to do with that content. They just sort of get taught how to use the form.

So these are four very different things, and there are more than four, these are sort of like four overarching categories. You can't put all this in a single meeting. It's different skill sets, it's different people, it's different brain space. And so understanding that these are separate things to learn I think is the first step in teaching them in a way that is effective. Thing two is to recognize that there are lots of different formats that training can take. So there's presentations, where one person is standing in front of a group, usually with slides. This could be good for project overviews, it could be good for larger goals, kind of anything being handed down from up high. If you have the ability to record these, either with an actual camera or even just recording the audio of a webinar, it can be really nice to have a recording of these to refer back to, but also because people who join your project later on will have missed all of the context setting that happened in the early phases. So you can give them these videos and say, "Well here's where we started, and now we're in phase 17." Working sessions.

So that's where a group is actually working together to figure out how to move forward. This can be a really good approach with things that cross organizational silos. So offline workflow, working for RACI chart, spelling out who owns different parts of the process and different parts of the site, getting lots of people in a room together and actually just filling out charts or mapping out what the journey of a piece of content is going to be. There's documents, like our old friend the PDF manual. Documents aren't like, I'm pretty frowny about documents, but I think it's mostly because we use them badly. They're really good for reference.

I like to say that all documents are dictionaries in that they're really good to look something up later, but you can't expect anyone to read them cover to cover. And then there's inline CMS training, which I think is vastly underused. This is when you attach help text and tools tips and links and sort of rich help content in the entry fields of your CMS, rather than segregating that over to a training manual or a style guide. So you're putting instruction right where people need then, in the interphase that they are using.

So let's talk about practice a little bit. My friend, Sara Wachter-Boettcher, who has been mentioned a few times here because she's awesome, she wrote a great article called 'Less Training, More Practice'. And she makes the point that practice is how we learn to do most of the things that we are good at. Writing, driving, cooking, whatever. We may have received training in a certain aspect of any of those things. Here's how you make a cursive 'Q'. But none of us mastered them that way. We mastered them by doing them over and over until we built the muscle memory.

Until making letter forms or parking between the lines or whisking flour and butter into a brew, stopped feeling like a list of steps and started feeling natural, until it became a part of us. So when you're teaching your teams, I think it's really important to give them the space to practice. So don't just show them on a projector how to migrate content to the new CMS, have them practice migrating with real content and talk through what parts make sense, what parts are tricky, what parts could be made easier with some administrative UI tweaks. When you're explaining to your team how the project is going to improve the experience for your site visitors, rather than just sort of presenting two use cases and calling it a day, have your team members listen to those two use cases and then brainstorm more examples, identify more things that are going to be improved.

It doesn't matter if you and other project leadership have already thought of the things they come up with, because the point is not to come up with new ideas, but to get your team thinking in a way of, "How is this going to improve things for users?". You're trying to get them to understand why we're even doing this project, it's sort of a deep intrinsic level. Repetition I think, after practice, is just one of the most crucial things. This is a really hard one if you have any kind of background in development or like as a project manager or an organizer, because we're always looking for the most efficient way to do things, and repetition does not feel efficient. So let me tell you a little story here.

A few months ago I was teaching a workshop, it was two days. This company was undertaking a very large project for them, they were moving their website to a CMS for the very first time, they were reorganizing their sections, they were gonna structure their content in a whole new way, it was a big thing. And I had built the content model for them a few months before that. I had included a set of wireframes, which I always do. Not as a design element, but sort of like, "Here's how this might play out when we put the content on the real screen."

They were color-coded, they were very clean and straight-forward, very easy to understand. Sometime in the middle of the first morning, the conversation circled around to the blog. They had one, this is gonna surprise you, but it was kind of a mess. It had become a catchall for all the content that didn't have anywhere else to go, it was just sort of this bag, it was like a junk drawer of a website. And so the plan in the new system was that we were gonna dissolve the blog entirely and take all of that content and put it in more contextually appropriate places on the site.

So this came up on the morning of day one. And I explained the plan, and the VP of marketing, she was very, very skeptical. It wasn't the first time she heard this plan, but I think it was the first time she sort of actually paid attention to what I was saying. And she was like, "I don't get it, I don't like it.". And I explained that we weren't losing any of the content, we really weren't losing any content, it was good content, it was just not supposed to be in a junk drawer. But it came up a couple more times over the course of the day, we pulled out the wire frames, we walked through how it wouldn't really change that much on their end, on content creation end, but it would make it so much easier for users to find X and Y. And she was still like, "I don't like this, I don't think it makes sense, I like the blog, I don't know why we're going in this direction."

So the next day rolled around, next morning came, we covered some other stuff on our agendas and I was like, "Yo okay, ready? We're gonna have a fight about a blog, it's time." The wireframes were already up on the screen from the last thing that we had been talking about, so I started explaining again, last thing, she's like, "Wait, so design tips for this service would be on that service's page?" And I was like, "Yes, okay." So I go over to the white board and I do a quick, just really shitty sketch, I realize later I have redrawn the exact wire frames that were like beautiful and crisp and clean on the whiteboard or on the projector above me.

I sketch out these boxes and I point, and I say, "So this will be, this will be here, we'll put the hip hips here and be great.". And she's like, "Yeah, that's exactly right, that's exactly what I want. Is that what we're doing? That's what we should be doing." Okay, I had been saying that for two straight days. I had been saying it for like five months. So after the workshop was finished, later in the day, I immediately started dissecting. I was like, "How could I have helped her understand that earlier? How could we have not had those seven discussions of tension before we finally got to the resolution?"

And I realized I had been resisting some things about how teaching works and about how learning works, because I was trying to be really efficient. The first thing that I was resisting was that time is not optional. The passage of time, just like straight up calendar time, like letting the hours tick by, I think is a really underappreciated ingredient in teaching. I think about the ways that we talk about learning new skills, and we talk a lot about making a habit of practicing everyday and putting in the effort. And our assumption there is that it's the effort that makes a difference, but I'm beginning to suspect that the plain old passage of time is the secret sauce in a lot of these processes.

Sometimes there's nothing wrong with my explanation, there is nothing wrong with my team members, but I have to give the information a chance to percolate and a chance to be absorbed before it's gonna click for people. The other thing is that repetition is crucial. You like that? It's a little slide joke for you. We have fun. So our brains have to be taught things a bunch of times before they start to make sense. It can feeling kind of inefficient, but it's not actually indication that someone isn't paying attention or that they're dumb, it's plain human nature, and I fight it at my peril. I think I have been looking for a magic explanation, and this is something that's really hard for me to give up on as an idea.

When that blog plan finally clicked for her on the second morning, I immediately started thinking, "How did I just explain that? I should keep that explanation and next time I'm in the same situation, I should use that last explanation first." I was looking for like a work zone, but I think there is no secret key. I have been sort of thinking of it like that every person and every situation has this secret approach and if you can just figure out the secret approach, you unlock everything. And the belief there is that I happened upon the secret key with my last explanation and that I could have saved a ton of time if I had started with that one.

But I think actually it's probably more like this, that all the pieces are necessary, that if I had a do-over, and I started with that perfect last explanation, it still would have taken two days. We needed to have the conversation about how it would impact the writing team, we needed to talk about where the users wanted to see that content. At some point, I needed in real time to draw that stupid wire frame on the whiteboard again, those were all really necessary steps, filling in all of the puzzle pieces so that everyone could understand the whole picture.

That can feel really inefficient, but actually what I have decided instead, is that it gives me breathing room. That there is no failure in explaining something four times, there's no failure in someone needing days of practice before content entry makes sense, or double checking with a coworker about what the point of a piece of a project is. Those things are reality, that's how people actually work. I could rail against that or the only person I can change is myself. I can choose to meet my team where they are and I can choose to be their coach instead of their leader.

So I'm gonna wind up with a few take-aways here. Number one is to focus on your training strategy. In a large sense, all of the tactics that I have been talking about today, the different types of training, the different formats you could use, those are all fundamentally about not treating your team as an afterthought. We get so focused on the thing that we're building and on launch day, that we forget to make a real cohesive thought-out plan for how we are going to teach people to use it, or how we're going to teach our team to manage the project without us.

So for your next project, or for a project that's still in an early stage, try introducing training conversations in the very first planning sessions. Start thinking about site maintenance in your earliest conversations. So how is the communications team going to learn to use this? Who on the development team is going to be available for us to make admin customizations? Every time through the project a new feature gets added, ask again, how are we going to teach people to use this correctly? What happens if they use it wrong?

On the flip side of that, focus on your strategy training. I think that it is not enough for your team to be able to recite back a project goal that was on a slide deck at some point. I think they really need to understand it, they need to understand the benefits and the bigger picture and the ripple effects. And the only way they can get there is if you coach them into understanding the strategy.

What has been working really well for me is to make strategic decisions out loud, and take that as a metaphorical out loud if you work in a distributed team with a lot of text chat. I spend a lot of time explaining my thinking. Explaining what led me to the decision I made and what's wrong with the alternate choices, which can be a really helpful, not just where we're going, but why we are not following these other paths. In telling the stories of specific decisions over and over again, I'm laying out all the pieces of the guiding framework.

And team members as they hear that enough times, they start to put together their own understanding and they start being able to follow the framework on their own. And then as the project progresses, I shift from being the person who makes decisions to being the person who confirms them. Now, our old pal urgency likes to get in the way of these explanations, because urgency says that there is just not time to explain all of this stuff, that it would be faster not to. Which, yeah, thank you urgency, thank you for the feedback, but it is also faster to make Cheese Whiz than aged Gouda, but that does not mean it's right.

And finally, the work that I have been talking about today that's been personal, that's digging into our egos and our pasts and our fears, it's legitimately terrifying work. It's not easy. I don't know if you know the term 'Easy peezy, lemon squeezy'. My partner Aaron sometimes likes to say that things are "Difficult, difficult, grapefruit, difficult.". So this stuff, this egos and pasts and fears and our own psychologies, it is grapefruit difficult. It can feel really impossible.

Here I am telling you like, "Go back to work and go with your teams and repeat yourselves over and over again in meetings." And, "Be okay with people taking a really long time to absorb new information." And “be gracious and understanding and gentle in situations that are incredibly frustrating." So it's really important to understand that the better version of ourselves, that person who is kind and who is generous and who is full of grace, that person is already there inside you. They have always been there, they will always be there.

This is the part where I cry on stage. I have tried sometimes not crying on stage. It doesn't always take. I'm a person who cries a lot, I have always cried a lot. I feel a lot, I've always been a person who feels a lot. I'm guessing that we have a slightly higher percentage of people in this room than average who also feel a lot. Yeah. And you know as a kid growing up I got told, I got shushed a lot, because if you cry in school a lot, which I did, you get shushed a lot and you get told to calm down and to be quiet and sort of get yourself together.

I mean, I guess those people wanted me to feel less than what I feel? But now I'm an adult, so I can say with confidence, fuck that noise. And so sometimes I cry on stage, so fine, whatever. I cry because I feel the things that I'm saying, I feel things about them and I'm not finished feeling them and so I cry when I feel them. So the person who is kind and who is generous and who is full grace, that person has always been inside you, will always be inside you, always available.

So tapping into that person is not a matter of building a huge new skill, it's not filling a gap, there is no hole in yourself, it's not really about changing who you are, it's more like it's about cleaning up, it's more about clearing out the dust and the cobwebs and the clutter and the mess and sort of revealing what lies beneath. It's like letting the clouds clear and there's a blue sky left behind. Or to use imagery that might be a little more close to home, it's like clearing all the fucking Post Its off of your desk.

So launching a new site or a new strategic initiative can be really exciting. But developing the strategy by ourselves, although a very powerful feeling, that is not really enough. I think we have to take our entire team on the journey with us. And only when everyone that we're working with really understands the goals and the mechanisms behind our new directions, only when our teams are the heroes of our stories do we have the foundation necessary to see all of our projects succeed. My name is Eileen Webb, I am the director of strategy and livestock at Web Meadow. It is not a facetious title, I will show you pictures of livestock if you ask me. and thank for having me here today.