What It Really Means To Be a CTO
Guest Post Week concludes with Dan Shapiro
Dan Shapiro is a friend who I’ve come to know through the Seattle startup community. Dan founded the mobile software company Ontela, which he merged with Photobucket, and is now in stealth mode with a new startup named SparkBuy. (Follow them to get an invitation to their beta.) When I asked him to write a guest post, I wasn’t expecting what I received—an ode that humbles me.
I was talking to a CTO candidate some months ago. He seemed terrific and came highly recommended, with only one concern – he hadn’t been at a single job for more than two years. To his immense credit, he knew that was a yellow flag and, when we were talking about his resume, brought the subject up.
He did it in a great way too. He pointed out the strength and depth of his experiences, and then said, “the one thing I regret about my career so far is I haven’t had an opportunity to really build a long term relationship with a company”. He then explained the course of his career arc, and proceeded to dispel all my concerns. There was a few acquisitions, a bankruptcy, and similar circumstances that explained everything. Except one thing.
I asked him why he was leaving his current job, and he told me a few reasons. But, the biggest reason he provided was that the codebase is a mess, and it needed to be rewritten from scratch. He said that it was just painful to work in an environment like that, and he wanted to go somewhere that he could work on great, high-quality code.
This reminded me of the story of Scott Porad.
Awhile ago, I was having lunch with Scott, the CTO of one of Seattle’s most impressive companies, I Can Has Cheezburger? I asked him why their company was built on WordPress and .NET, an unusual choice for someone in their space. And that’s when I heard the story.
He told me that when the CEO, Ben Huh, hired him on, the site was a mess. The complex process of processing user submitted content was managed entirely by a thorny tangle of PHP (in WordPress) and .NET. This weird mix of ugliness was written by a contractor over the course of the preceeding six months. It was undocumented and messy. The obvious thing to do was get rid of it, and start fresh.
So, he sat down and talked to the CEO. Times were tight: they’d raised a small round to acquire the original domain and hire some staff, but the money was disappearing quickly. New features were needed to support better monetization, and they couldn’t get them done frequently enough.
Scott had a terrible decision to make. He could scrap six person-months of work and build the site anew. It would scale better, reducing costs would be easier, and he wouldn’t have to mix PHP and .NET. They could purge their technical debt with one fell swoop.
But, that’s not what he did. He told me that he wasn’t sure the company could survive locking down the business while he attended to development housecleaning. So, he kept the company on the original codebase, platform, and architecture.
Over the years they’ve cleaned up most of the mess, but incrementally, and only as needed. The company still runs on .NET and PHP.
When I finished this story, the candidate had a look I can only describe as dread. I asked him, “Do you know what it means to be a startup CTO?”
He said, “Yeah, I do. It means you have to be OK with a decision like that, because it’s in the company’s best interest.”
I said, “No, it doesn’t mean you have to be OK with it. It means you have to advocate for it.”
Scott’s a hell of a technologist, but that’s not why I admire him. I admire him because he’s an entrepreneur first and technologist second, and he does a hell of a job at both.
I guess the guy did not get the job.
Maintenance Man
15 Nov 10 at 11:54 am
Gut-shot reality writing. Ouch. Maintaining continuity in a system of PHP + WordPress + .NET would make me think very carefully about the compensation package.
Curtis
15 Nov 10 at 12:13 pm
who is the Techcrunch CTO?
Neil Durbin
15 Nov 10 at 12:40 pm
As technologists, it’s sometime tough for us to grok that business drives architecture/technology choices more than anything. Partnerships throw more considerations into the mix. Technology choices need to directly support your value prop for your customer. I have often incurred technical debt when needing something that our customer base is shouting for. But, you do have to account for the debt and you need to pay it back.
My situation when I arrived on the scene with my current gig was almost the opposite from the one described in the article. I could choose to renew our maintenance agreement for our commercial infrastructure software (for many of 100s of 1000s of dollars) or port it to open source. Took about two developer months to do the port and we have never looked back. Reduced a barrier to entry for our customers (they have to buy the same infrastructure software), cut costs, and more or less preserved the original architecture.
MikeG
15 Nov 10 at 1:31 pm
I liked this article. Thanks for sharing it.
Reza Akhavan
15 Nov 10 at 1:31 pm
I disagree that the CTO has to be an advocate for a technology strategy that has the potential to limit the business in the future. The CTO should be an advocate of the technology strategy that keeps the company’s options open while the VP of Products, et al, should push for new features, business, etc. It’s that healthy tension that allows proper decisions to get made and gives the CEO choices. If the CTO advocates for whatever they believe to be in the best interests of the business, who is making sure the company is not handcuffed by bad technology in the future?
History is littered with the likes of Friendster who made the same decision as I Can Haz Cheezburger with catastrophic results while Twitter made the decision to rebuild their infrastructure and thrived.
At the end of the day I would rather a CTO who would push for sounds and scalable architecture over one who tried to interpret the goals of the business. If the management team decides that the risks for the future are worth the cost for short term gain then the CTO is responsible for carrying out that strategy.
sean
15 Nov 10 at 1:38 pm
I agree with Dan, this seems to be a good case to discuss the differentiating roles between being CTO and Director of Engineering. The latter being more focused on executing the technical objectives, while the former is more aligned with the business interests and technically executing the President’s vision. The two roles are similar, but distinctly different.
Just my two cents.
Terry M.
15 Nov 10 at 1:57 pm
I think this is a good example of the difference between your CTO and Head of Engineering (although startups often have to conflate the two) – we’re trying to get to a position where our CTO can focus on the technology, roadmap and cool sh*t and somebody else can focus on uplifts, feature implementations and maintenance.
The real problem remains whether Start Ups can manage to have the two?
David O'Neill
15 Nov 10 at 2:13 pm
[...] great idea was shared in the article, What it Really Means to be a CTO/. What I got from it was this – Hard decisions will have to be made, and when they are you can't [...]
Life Lesson for Startups « On My Way To …
15 Nov 10 at 2:40 pm
Great story!
There’s a gem in there that I think some readers are missing. Namely, that it’s EVERY employee’s job to support the business regardless of their position. Those that don’t have the autonomy, support the business by following their superior’s orders. Those that have decision making power should be advocates of whatever supports the goals of the organization best. Sometimes that means patching. Sometimes that means rewriting. Very often, it’s painful.
That CTO candidate will never have a long term relationship with a company until he learns that lesson.
Kai Yen
15 Nov 10 at 5:55 pm
The key CTO skill is calculating when the current code has become a liability (Friendster) and will harm the business versus an inconvenience that can cleaned up over time.
I’m a business-focused CTO who delayed rewriting our site for a year because I had seen too many developers waste time with unnecessary rewrites. Our codebase was 21,603 lines of non-whitespace PHP on Drupal that was fully capable of running our site indefinitely, but required way too much developer time on optimization. More importantly, trying to make sense of the unnecessary complexity was extremely discouraging.
I took a 80/20 perspective on our features and our team rewrote only the most important ones in 30 days. It helped us re-align the business around the features that our users love best versus the ones that were rarely used distractions. Yes, we left out a lot of essential features that we had to add back in later, but our traffic and revenue weren’t harmed and our site is now a lot faster and easier to maintain.
You can read about the rewrite on my blog.
Eric Kennedy
15 Nov 10 at 7:35 pm
This is lame. A CTO is not meant to get involved in the politics of enterpreneurship, you have it wrong, unfortunately.
anonymouscoward
15 Nov 10 at 9:17 pm
[...] What it really means to be a startup CTO Posted: November 17th, 2010 | Author: Dan | Filed under: Sparkbuy, Startups | View Comments TweetI just wrote a guest post on what it really means to be a startup company CTO over on my friend Scott Porad’s blog. Read it here. [...]
Dan Shapiro » What it really means to be a startup CTO
17 Nov 10 at 1:04 pm
Yes, I found that out too. When you’re a techie, you can always opt for the “technically correct” approach, but once you become the CTO you have to balance all of the short and long term concerns, and sometimes make unpopular technical choices in order to survive. In the first few years I’d fight it, stomping my feet or just sulking, but after five years it became more or less automatic. The CTO role isn’t a technical one, it’s the bridge between the business and the technology. The choices aren’t black or white and if you’re a really small software company on the edge, the choices are often the difference between success and failure. My “inner programmer” learned to swallow his pride and get on with the business of winning. One executive I know loved to say “would you rather be right or happy”. It took a while to really understand what that means (and how to achieve happiness without feeling like I violated all of my technical principles). But it’s nearly impossible to explain that to someone who’s always been sheltered from that part of reality. They think “right” only applies to their little corner of the problem, instead of the whole.
Paul.
Paul W. Homer
19 Nov 10 at 1:52 pm
[...] is not to say that the vision can’t reside with a designer or an engineer, but in our model, I have to be accountable. If we miss the mark, it’ll be my fault… [...]
What Does A Business Co-Founder Do? | Jet Cooper
11 Aug 11 at 2:50 pm