Evolution of the Web Monkey
The other day, a friend told me that their lead web developer had left his company for another job. According to my friend, this guy was a rock star when it came to development — and he knew it. He would sometimes refer to himself as a “Web Monkey”, but he also knew how much value he added to the department.
Then one day, during a presentation, the CEO introduced him as their lead “Web Monkey.” Maybe the CEO thought he was being cute, and it was OK because he had heard the developer himself refer to himself that way and figured it was OK.
A few weeks later, the developer tendered his resignation. My friend doesn’t think that it was directly related to the presentation incident, but I think the presentation was a symptom of some bigger problems in his company.
Rule 1. Don’t call web developers, designers, and content editors “Web Monkeys” unless you want them to throw their feces at you (figuratively, of course. I hope). Only web personnel can refer to themselves and each other as such. Even if it’s done out of endearment or humor, calling someone a web monkey if you’re outside that department is a slap in the face to their credibility.
Some other tips for working with web teams:
2. Incorporate web team members into your initial product kickoffs. From what I hear, even in 2014, the web is still the red-headed stepchild of many companies’ marketing efforts. Too often, product marketers get into a room and map out campaigns without involving web people. Then when they do, it’s either a) already been planned out, complete with unrealistic timelines and expectations or b) not planned out at all, but seen as an afterthought. And at this point, the marketing budget is squandered.
When you work together with the web teams, you can usually work out a compromise, and from my experience, come up with something better that neither parties would have come up with on their own.
3. Don’t make up stuff to sound cool. Simply describe what you need and/or use screenshots. A number of years ago, I received an email from a potential client asking me if I could edit his citations. I wasn’t familiar with this site, so I looked all over for a page or section called “Citations”. After a few minutes of frustration and feeling like an idiot, I emailed him back. His response was, “You know, those things that come up when you search Google.”
Metadescriptions. And keywords. Yes, I can edit those. I would have actually preferred if he had started out with “Those things that come up when you search Google,” before I drove myself batty looking for something that didn’t exist.
To drive the point further into the ground, my mechanic husband often endures this mentality. One of two things happen: 1)People try to fix the problem themselves (“Hey, if some stupid grease monkey can do this, surely I, a PhD, can do it.”), and then end up spending at least twice as much fixing the original problem AND what they broke trying to fix it; or 2) They puff up their chests like wild gorillas and tell him what needs to be fixed, and he ends up wasting time (and their money) finding out that the problem was with something completely different.
Like web folks, he’d rather you tell him the problem you’d like him to resolve (complete with stupid mouth noises), and let him figure out how to fix it. A few seconds of humility could save you thousands of dollars. Which brings me to…
4. Ask, don’t tell. When web producers tell you they can’t give you a design or technical feature you’ve requested, it’s not because they’re being arrogant, lazy, or trying to make things more difficult for you. They are trying to create the best user experience possible for your customers and potential customers. You know — those people who buy your product or service and make you money. In some cases, they are trying to save you money.
A designer (at least one worth their salt) is following some sort of style guide so your site doesn’t turn into the Winchester Mystery House of web sites. As a designer, one thing that raises my hackles is when a clients says, “I value your creativity. Could you build a web site just like my competitor?” If your competitor jumps off the Golden Gate Bridge, does that mean you should, too?
When it comes to technical features, a developer should want to build something beyond a site that isn’t going to break; it should be easily maintainable and scalable. Remember, your site lives on long after your launch.
A mature web user experience model is about strategic versus tactical solutions, and the process is collaborative versus “garbage in, garbage out”. It’s about looking at the web site as an organic beast, rather than just the home page and everything under it. It’s also about applying long-term solutions rather than spackle and Band-Aids
Web folks aren’t short-order cooks. And they’re not monkeys.