You’ve probably heard by now that Mike Arrington has sold TechCrunch to AOL. Congratulations to him and to AOL, which has bought itself some talented people, some good traffic and no doubt some headaches down the road.
This paragraph in Arrington’s explanatory post jumped out at me:
The truth is I was tired. But I wasn’t tired of writing, or speaking at events. I was tired of our endless tech problems, our inability to find enough talented engineers who wanted to work, ultimately, on blog and CrunchBase software. And when we did find those engineers, as we so often did, how to keep them happy. Unlike most startups in Silicon Valley, the center of attention at TechCrunch is squarely on the writers. It’s certainly not an engineering driven company.
This description jumped out at me because it was so familiar — and also because it surprised me. I guess I hoped and trusted that the “endless tech problems” that were at the heart of my experience at Web 1.0-era Salon.com (they led me to write a book) were a thing of the past. What Arrington is saying is that the stuff that was hard 10-15 years ago is still hard today. I guess I should have expected that.
At Salon, we had some highly gifted people working for us at different times on the technology side, we built a robust CMS that’s still operating (and that spawned its own open source version), we built our very own pay wall in about a month in 2001, and we pioneered all sorts of useful things in our day. But it was exhausting for an organization that was driven by its editors and writers to also have to figure out how Web publishing worked, technologically and economically; to build systems that would scale well and bend to our needs; and to work out how sales and marketing could make sense in the new medium.
By the second half of the decade I spent at Salon I know I spent far more of my hours dealing with those issues than writing or editing copy. I remember thinking enviously of the position our sometime rivals at Slate occupied; they’d always had the benefit of being tied to a larger enterprise — first Microsoft, then the Washington Post. No doubt that had its own frustrations. But it meant they could concentrate on the fun stuff without having to invent and manage the entire business and technology operation simultaneously.
This is why I always stop and think when I hear friends and colleagues repeat the truism that “the journalism is the hardest part.” We said that a lot at Salon, and I still hear it today, but I no longer think it’s true. Good journalism is always work, sure — but it’s known work. We know what it takes to do it right.
The challenges of independent publishing online, on the other hand, are the real “hard part” of this industry. I bet any entrepreneurial publisher you ask will agree — go talk to Rafat Ali or Om Malik or Pete Rojas or anyone else who has tried to build their own Web-based publishing enterprise over the past decade.
The thing is, if you’re the sort of entrepreneur that I’m guessing Arrington is, the hard stuff may be exhausting, but it’s also what gets you up in the morning. That’s one reason startup founders so often spin their wheels after they’re acquired; designing and building your own little speedboat is just a lot more absorbing than managing how to integrate your personal craft with a battleship-scale corporation. It’ll be interesting to see how this plays out for the TechCrunch crew.
Post Revisions:
- September 28, 2010 @ 22:31:05 [Current Revision] by Scott Rosenberg
- September 28, 2010 @ 20:57:33 by Scott Rosenberg
Unfortunately, this is true at every scale, although I hear that Drupal and Movable Type have made some real progress in solving it at last; I don’t know enough about WordPress as a professional CMS front-end.
At TidBITS, we have invested north of 1,000 collective hours in planning, revising, and building two complementary CMS systems, one a homebrew (LAMP with HTML::Templates at the core), and the other Expression Engine with a lot of custom code.
And we’re a small site. Relative to revenue, we’ve spent an enormous amount of time on development, but it’s been the only way to deliver the precise combination of what we want to do and what we’ve found our readers wanted–as well as the pathway to bringing in new readers.
We kept hoping we wouldn’t have to fund an independent CMS. But every tool we tried was lacking in one or many ways.
It is definitely still hard.
Just last week, after a young engineer made a mistake that had me at the office at midnight (sound familar?), I pulled up to his desk since he was still there working through it with me and asked him what he had learned from the experience. His answer was appropriately self-reflective and it was clear he had learned how not to repeat the mistake. I told him to check out the opening of Dreaming in Code to see if he recognized any names. :-)
It all goes back to Fred Brooks’ “No Silver Bullet”: http://en.wikipedia.org/wiki/No_Silver_Bullet. The “essential complexity” remains, and even intensifies as expectations continually go up.
Just last week, Twitter had several hours of problems with a security worm, Facebook was down for 2.5 hours, and the site I am responsible for had a few problems, too. In each of those cases, I heard the post-mortems and understood exactly what had happened. I had conversations with people who know how these things work, and uniformly, we nodded our heads in understanding while we all read the armchair quarterbacking on Twitter (“don’t these people know what they are doing?!!”)
And it’s all totally worth it, and that remains difficult to explain.
“designing and building your own little speedboat is just a lot more absorbing than managing how to integrate your personal craft with a battleship-scale corporation”
So true. Beautiful turn of phrase. Although integrating (or trying to integrate) can be a lot more lucrative.
Thanks,
Same was true of building scalable blogging software and communities. So many people brush off the software engineering accomplishment of blogging, and related technologies as if they were always obvious and the solutions revealed themselves
The bit of your excerpt that leapt out at me, Scott, was when Arrington noted that it’s hard to get talented engineers when you’re focusing on writing, not engineering. Ambitious engineers look for places where they can be drivers, not supporters. Not sure how to square the circle on that one — split off the engineering into a subsidiary company, look for talented engineers who have some ideological or geographic reason to work for you instead of a more engineering-focused company, or what?
@Sumana: We had this problem in Amazon’s early days; I worked there in 96/97. We could not attract engineers because programming the innards of ecommerce was unsexy compared to everything else going in the greater online world! After the company went public, it changed (after my time there).
The thing was, at Salon at least, we actually had a series of really talented and imaginative CTOs and engineers, many of whom — hi, Chad! — went on to do other cool things at other places. I bet TechCrunch, with its profile in the Valley, also had its share of engineering talent. I’m guessing the issue is less attracting and holding onto talent than it is in knowing what to do with them, how to harness their creativity. It’s definitely the case that “editorially driven” companies often fail to treat engineers and technical people as creative peers. Today I’m hopeful that’s beginning to change. At Salon we always had the “it’s early days” excuse. But there were a lot of lost opportunities…