Web Strategist Lab

Was all about becoming frustrated (again, seemingly for little reason) over a project I see landing in my lap that I will have control and the burden of responsibility over without actual ownership. If it fails, I did it wrong. If it suceeds, someone else will claim credit.

So in order to handle myself I completed a dozen minor tasks only to have someone tell me I should consider changing all my priorities to theirs. Which I will have to do.

But I got some amusing responses to my tweet about third-party email systems very quickly, including a vendor who noticed I mentioned their name and dm-ed me within 20 minutes.

To sum up: I dislike projects that don’t know what they are and twitted has clearly hit some sort of critical mass

Let’s talk about something we don’t like to talk about (well, maybe you do, but from my experience, it’s like talking about death in a funeral home – everyone knows it’s always a possibility, but speaking it is verboten) — messing up.

Not failure, per se. Failure feels to me like something that didn’t work from top to bottom but no one stopped the train as it barreled over the cliff. Messing up is making a mistake, trusting in the outcome, not keeping a close enough eye on something, miscommunication, dropped deadlines, forgetting a detail, passing something off to someone who can’t handle it. These things, these very everyday things, are what I think of when I think about messing up.

And I’ll start our little game by admitting up front that I have messed up. Almost all of those things in my list above I have done. I have also finished meetings before I completely understood the client’s needs and expectations. I have allowed vendors to tell me everything was going fine without asking for more details. I have been distracted by other projects and let my focus slip.

Yep. I have done those things, and not always in the distant past.

And I guarantee that I have learned from every mistake.

The only place I’ve ever seen a discussion of these kinds of issues is when Fast Company talks about Toyota. For all the success Toyota has found from openly and frankly evaluating mistakes (seemingly without spin), I have not heard much about other companies using these ideas.

The only place I’ve heard of something like that is in a doctor’s Morbidity and Mortality conference when a patient dies (a great insider’s viewpoint of an M&M is Atul Gawande’s “Complications”). The doctors get together behind closed doors (away from patients and their lawyers) and talk about things that could have been done better purely in the hopes of educating each other. It guarantees that education never stops, it forces every one to be part of the solution, because you know one day you will be the subject of everyone’s scrutiny.

At my current position, we do “post event” work. But its mostly about counting guests and talking about how to make sure there was enough fruit at the event, or how many registrants needed additional help. It’s fine to do this level of examination on the execution level, but not enough feedback or discussion as to how we conceptualized the event, how we marketed it, how we chose the event, or even how we designated participants. It’s not a failure because the event brought in the 50 people we expected it to bring in, but that expectation was a function of the event. No one said, “How do we get 1,000 people to attend an event and what would that event look like?”

Do we screw up by not asking those kinds of questions? I wonder what it would take to create those conversations on a regular basis? I wonder if we have the culture that will keep people from pointing fingers and make people hear other ideas?

In the last two or three weeks, I have been involved in focus groups for two different projects. In fact, I was in opposite roles for each group. First, I helped develop a presentation by the Diretcor for a focus group for a coming Capital Campaign. Sadly, they came to me a week before the presentation was scheduled and when I asked what the outline/goal/theme/intent/purpose (you know, the actual “stuff”), they just shrugged. So the process was one of me getting everyone to understand that a presentation, espeically one to a focus group, where you have actual questions to ask them (or at least that was the idea). One would think that it would be an obvious thing, but the rules, as always, don’t really apply here.Then, a week later, I was on the pointed end of a focus group, specifically one about a proposed new web site. I think there were maybe 8-10 people in the room, but half of them never said more than a few sentances. I’m not sure why they were there other than for political purposes (“We invited them so they could play a part… if they wanted to,” it seemed to say). While the second focus group seemed to get somewhere in a hurry, it was because three people mapped out in a few minutes what should be done, why it should be done, and then spent most of the next two hours explaining to the rest of the group that it was the right answer. Is it common for the tech people to hijack the meeting in order to sort out the issues while the other stand by and watch? (Yes, I was one of the geeks who ran away with the meeting.)

It just seems clearer than ever now that the preperation for meetings is more important that what happens at meetings. There’s been a lot of talk lately about meetings and how they are evil and suck your time and how they are filled with useless blather. And they are mostly right. Meetings beget meetings like spam in your inbox. And most of them take all the time alloted to them (whether they need to or not), and just serve the person in the room who doesn’t seem to have anything to do but hear themselves talk.

When I first got here, a lot of people commented on how fast my meetings were. I think I’ve slipped lately (as the projects I run involve mroe and more people) and I’m in danger of becoming what I hate — a guy who lives in meetings.

I’m trying to put up systemic forces to keep that from happening. For example, we have a meeting that could meet every week and have ten people (nightmare!). But I set up the system to have two groups: the five core members and a rotating set from the other five. Meetings never have more than 7 people in them, and the people I trust most are in the majority of the meetings.

If only my boss’s boss could do the same for divisional meetings…

I could write a nice narrative detailing my interaction with a mid-level manager and how she wanted a new web site for her program pretty much NOW, and how, once we built it, took three weeks to even look at it for fixes, and after giving us fixes, is only now setting up an 18-person (yikes!) meeting discussing what should be on the web page… but I will spare you. Mostly I’ll spare you because you have your own stories of people who think the cart goes before the horse and pick out wallpaper before finishing the architectural designs.As I learned a long time ago (and have had to teach many people since then), the web is in such a unique position in most firms because it is a program without a country. It does work for all divisions. As such, it is one of the few things that can reach every nook and cranny of an organization. It is one of the few ways to affect enterprise-wide change (I mean, is your financial department or purchasing program shape the way programs do things?).

Most people think, “I have a problem. I have devised a solution. Now I will create a web-version of that solution. This is what it will do. This is what it will look like. Now, let’s talk to the web guy…”

Maybe other web-people think that makes sense. Maybe they are happy to accept the assignment and do the work whether or not they see issues with the solution.

But I’m not that guy. I want to be there meeting 1 and help someone discover the solution (and how it is web-able will be discussed in turn, but by having me at the table early on, the web-solution will be obvious as it was thought about during first-level meetings).  I think the the web is a tool that invites conversations about the process. not the process of design or development, but the process the client is trying to take to the web.