September 17, 2006
The recent Facebook controversy brought out a few more good posts on how to engage, learn from, and respond to your users.
Teresa Valdez Klein at Blog Business Summit reiterates the standard advice: ask what your customers want, admit when you screw up, and, most important, don’t sneak back into your shell once the immediate crisis is over.
As usual, Robert Scoble has the best advice on corporate blogging. He takes it all several steps further: publish a video blog, meet with a cross-section of your users in person, link to blogger criticisms “out there”, and post responses on others’ blogs.
That’s quite a bit to take in for any business.
I am happy to say that Webshots has been improving on its communications.
The Webshots blog has been a growing source of communication between members and staff. Anne, Amy and Jessica have been doing a great job.
Anne put together an invited group of members on a separate blog, with whom we communicate about new ideas, demonstrate new features, and so on. It’s quite a different kind of feeling.
We also have a staff picks blog, which, while not truly a communications avenue, is a volunteer-run blog of Webshots employees who pick and write about our great members. It’s also a different kind of feeling, and puts even more of a personal touch on things.
Gone are the days when Webshots shunned communicating with its users, and avoided catering to the tech-savvy crowd. We’re now open with our failings, and when we do something wrong, Anne and Amy take a lot of flak so that we engineers don’t have to. 🙂 (Which isn’t usually fair to them.)
Going back to Scoble’s advice, probably the biggest struggle we’ve had is putting together a true cross-section of our users with whom to interact. Every group thinks they’re the target audience. And why not? Without a site that individualizes the content it features to each member, everybody has a claim. That’s a problem with pushing the same content to 20M+ members.
After reading Scoble’s post, I realize how far we have left to go. Webshots never links to other blogs (I don’t think it’s a policy, maybe just an oversight or unspoken fear). And we’re never officially commenting on others’ blogs, or promoting Webshots in our own blogs.
The latter point merits some extra thinking. Posting on others’ blogs in discussions about your employer blurs the line between “offcial company activity” and “personal opinion.” The opportunities for screwing up are pretty numerous. It’s easier if you’re the CEO.
Even this post blurs the line. (Obviously it’s all personal opinion and my employer will disavow
just about everything I write. But the average reader might not see it that way.)
Is it good if your employees are blogging about you, even if they sometimes say stupid things, or criticise your management, or leave for a competitor? It’s been good for Scoble. Does it work for everyone?
June 17, 2006
I just realized this as I was waking up from my nap: today marks my fourth anniversary at Webshots. (My official hire date was June 16–a Sunday in 2002, with my first day being Monday.)
Technically, I’ve been doing work for Webshots for almost five years. As an engineer at Excite, I was, among other things, responsible for Webshots’ photo search starting in the summer 2001. I have fond memories of complaining to my manager, “Who the frell are these people who can’t give us a valid XML feed?!?” Over the years, I’m sure I’ve caused more than one partner to exclaim, “Who the frell is this bozo who isn’t using our API correctly?!?” And the world turns.
We’ve only made two indisputably bad hiring decisions in the past four years. There was the numbskull who tried to bring proprietary code from a former (competing) employer into our site (he was fired on the spot, and all of his code removed before we launched the product he was working on), and the guy who wrote more Daily WTF candidates in his short time than I’d believed humanly possible.
Today, the Webshots engineering and webdev team is better than it’s ever been in the over ten years of Webshots’ existence. Being part of CNET also means there are other engineering teams across the organization whom we can leverage for core infrastructure, and even, on occasion, bells and whistles. (One of those cool groups is responsible for Solr. I envy the people on that team.)
Four years in one organization is about the time when most people–even happy people–start re-evaluating their careers, and I admit I’ve been doing some soul searching myself about how to take my career to the next level. The things that make a job worthwhile for any engineer are being surrounded by smart people, learning new things, finding new challenges, and getting things done. I don’t have the perfect job (who does?), but I’ve found a lot of all four lately.
But the really nice thing about this anniversary? I start accruing an extra week of vacation every year! Yeah, baby!
April 12, 2006
Last week, Webshots launched CollegeLive as a beta — a distinct, more-or-less “walled garden” for university students. It’s not just a ripoff of Facebook, but, let’s say, inspired by their success, with some improved features. And it was a lot of fun to develop.
Most entreprenuers would be happy with the traffic we’re getting in our first week.
Me? I’m just impatient that we’re not yet getting tens of millions of pageviews.
It’s been a while since I’ve worked on anything that wasn’t large scale within a short while. Our mobile offerings have always been medium or small scale. Mobile has always been a good place to try new things–new platforms, new development models–because it’s large enough to pose some challenges, but small enough that it’s not going to tip over. There are few mobile services of that magnitude today.
Now, nobody expected tens of millions of page views the first week, especially launching mid-semester. It needs time to grow, and we’ll doubtless respond to our members with features in time for a fall rush (no, not that kind of rush…well, maybe that kind of rush). I’m just incredibly impatient. I’m not sure I could go back to working at a company that doesn’t deal on a large scale.
March 26, 2006
For the last several weeks, I’ve been on a project where we’re all pretty tightly coupled. Any design purist will tell you that tight coupling is a bad, though sometimes useful, thing. Tight coupling means every participant needs to know practically everything about every other participant, and all participants need to be “in the same room” whenever work needs to be done.
(Mental image: passing a co-worker onto your call stack…by value.)
(Oh wait, that’s what meetings are. Too bad small conference rooms don’t throw stack overflow exceptions.)
Practically, what this means is we’re all pretty much working the same hours–including weekends. That’s not exactly news in the software world, but it is a different way of working for me. I can be more productive at 3am than I can at 3pm, but it’s hard to get everybody to agree to work those hours. (Maybe when I’m a manager. Bwaaahahahaha.)
Ordinarily, I resist for an entire project team to work together on a weekend. Partly, this is selfish. In cases where it seems to work (i.e., we meet our deadline), management will perceive that working weekends is the answer to tight schedules. The result? More weekends to work. We lovingly call this the death march, which studies have shown don’t work.
However, sometimes the work is partitioned in a way where not having everybody in a room together, even on a weekend, will cause bottlenecks. On a project with a far-off, or flexible, deadline, there’s time to reconsider partitioning of work after a week under less-than-ideal circumstances. But when you’re on a tight deadline, you suck it up, and hope everybody learns from the experience heading into the next project.
Luckily, rearchitecting how a team works is much easier than rearchitecting how a software system works.
If there’s an upshot to tight coupling, it’s that everybody gets a chance to mesh. We’ve expanded the team recently, which means we have a high proportion of new members. This is the first chance we’ve had to really work together as a coherent unit, and it’s been great. Maybe there’s a lesson here… everytime your team expands, you go through a little ritual hazing, i.e., working several weekends in a row on a project with a firm deadline.