5 ms·

What it really means to be a CTO

89 points by wdaher 16y ago

mathgladiator 16y ago
It also means having root access. All kidding aside, that is the central question of being a start-up CTO. All non-business building aesthetics and measurements are out the window until you have customer #1. After that, the goal is to support the customer as best as you can. If ugly code is making modifications difficult, then you rewrite only then. If it is working, then for all that is holy leave it alone. If the code is beautiful and a change will make it ugly, then it will be ugly. One of the lessons I wrote about goes core to this. There is more value (to a company) in learning how to navigate, manipulate, and fix large bodies of ugly/shit code than trying to rewrite it in a perfect way.
netaustin 16y ago
Broadening the idea of a CTO from startups to companies with long track records, I've always thought of ideal CTOs as those who can balance risk and stability, growth and retention. They are elastic enough to handle being stretched between the business/product/finance goals of the organization and the engineering required to make the product actually go. Good CTOs know about all the shiny new things but have the good taste to apply them only when appropriate, can manage the finances of an engineering team, and aren't afraid to hire developers who might be smarter and better than themselves.
imajes 16y ago
I sorta disagree. Sometimes being CTO is about instituting technical leadership from scratch. There have been a couple times where i've worked with a company (as a contractor) and helped them in a CTO role. This has ended up with a need to scrap everything and start again. That decision was acceptable because of the complete lack of any technical experience in house (100% outsourced, multiple vendors) who had very different patterns of development. Couple this with no tests, no process and no patterns, you're stuck trying to work against something that's unpredictable. The way forward then is to hire a team (even if it's just one guy) internally who can have ownership of code. Then instituting good practice and a sensible method of rebuild and rediscovery. Obviously this hinges on having enough runway to get into it properly. tl;dr: sometimes it's ok to scrap it all and start again when your goal isn't about preserving code but instead is about building a better product and technical culture inside a company. Getting downvotes - I wanted to add something: There's a real risk of making problems worse when you don't have any ability to stop and change. Working with existing code is great but when you have existing customers running into bugs on a daily basis, and fixing them would change the business logic that others are relying on, you either choose to build more technical debt or you swallow it and start again. Obviously this depends on runway, position, etc. There are many times when companies go through their proto and raise seed only to find that their original hypotheses aren't working, and to change requires a significant re-architecture. Bolting this on to existing codebases can end up with code so complex that it won't stay up, and you end up spending six months in pure fire-fighting ops mode to keep the thing alive. Knowing when to recognize this and acting accordingly is the right approach, even if that sometimes means calling it a day on the existing code and starting again.
- auxbuss 16y ago
  I'm calling bs on this. You have to keep the train moving. That keeps the cash coming in. You can't stop the train. So, you have to take what you have and somehow -- that's what you are being paid for and hopefully you have the chops -- manoeuvre the beast into a better state. This is fscking hard, especially when you have to get the darn thing under test. And it's invariably massively undervalued by most biz management teams. You can _always_ extract value from operative but shitty code, even if you have to stick your head around the U-bend and pull it back with your teeth. If you don't know that yet, then you've more to learn.
  - imajes 16y ago
    I don't know. When you're trying to build a team in a market where there are more jobs than qualified applicants, telling them that you have to 'rescue' an app is a turn off and won't get you anywhere. Also, when the real value within the app is a simple product, breaking it out and re-engineering based on what you've learnt takes about roughly the same time as it does to walk through the code line-by-line and add in valuable tests. Refactoring legacy code by multiple vendors is always a risky proposition (and much much harder to sell to clients who want a deadline for delivery).
  - variety 16y ago
    "rewriting systems" != "stopping the train" (if done properly).
  - fdagggee 16y ago
    There are lots of reasons that technological assets can be very poorly aligned with a company's current goals. In those situations, a redesign is often warranted. I've often seen it occur as a confluence of: bad hires, poorly managed projects, companies that change direction, and availability of better solutions to the same problems. Just because something can be done, doesn't mean it's the best use of resources. CTOs are responsible for making intelligent fix/replace decisions, and it really doesn't sound like you're advocating that at all. Rather, it sounds like you're advocating an ignorant 'only fix' position.
  - 16y ago
alanstorm 16y ago
You can tell a lot about the culture of an organization by comparing the official and unofficial duties of the CTO vs. the COO. One of the better things I've seen written about what a CTO is came from this Rands quote "There are two classes of Free Electrons. Sr. Electrons and Jr. Electrons. Both have similarly productivity yields, but the Senior versions have become politically aware. In technology savvy organizations, most CTOs fall into this category." http://www.randsinrepose.com/archives/2005/03/20/free_electron.html http://www.randsinrepose.com/archives/2005/03/20/free_electr...
dansingerman 16y ago
"one of Seattle’s most impressive companies, I Can Has Cheezburger? " - Really? Does that say more about Seattle, or the Web at large? (Or was this just a joke and I missed the point?)
- dgraunke 16y ago
  Check out this comment and its responses: http://news.ycombinator.com/item?id=1857342 http://news.ycombinator.com/item?id=1857342
- cookiecaper 16y ago
  I found it kind of weird that the guest post on this guy's blog was his friend talking about how great the blog's owner is.
  - danshapiro 16y ago
    That's me. Scott asked me to do a guest post and had no idea what I'd come up with. I'd been telling folks this story about him for a while, so I figured it was as good an excuse as any to share it with a wider audience.
brianwillis 16y ago
This reminds me of Joel Spolsky's Things You Should Never Do (http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html). It's old advice, but still as relevant as ever.
- variety 16y ago
  It's relevant, but he didn't really mean it to be taken at face value. Because of course it just isn't true (even though people keep repeating it a lot, for some reason). The world is full of tons and tons of successful, large-scale software systems (from apps to languages to databases to OSs) that were not only "rewrites" of older systems, but had to be written because the original system had incurred too much technical debt. So what Joel really meant, deep down inside, was "okay it's not that you should never replace large systems from scratch; it's just that you should be very circumspect about it, OK? You don't just go knee-jerkedly ripping out the old stuff just because it's a ugly, a pain to deal with, unsexy, etc. You have to look at the whole picture, and understand the (true) business costs of what you're doing. That's all I'm saying."
  - edanm 16y ago
    I'm not sure about that. What I took away from the article is this: whenever you're thinking of rewriting from scratch, there's a better way - incrementally replacing the code. It's not as fun, and it feels worse, but it ends up with much better code. I'm pretty sure this is nearly always true. Joel outlines the reasons, but the most important one, imo, is this: you're not going to do a better job. You think you are, because you see that the code is a mess and think you're better than the people who designed it. And you're probably right (or at least, you know more.) But a system that has years of work on it is not something you can whip up again from scratch - you're going to miss all the same things they missed the first time, when they were designing it, and either recreate all the bugs, or make your new system a mess. Incremental improving is nearly always the saner solution.
    - ulrich 16y ago
      I second that. It's not the "rewrite" that is bad, but the "rewrite from scratch". You might end up with a completely different codebase if you do it incrementally.
blantonl 16y ago
What it means to be a CTO at a startup is significantly different than what is means to be a CTO at a Fortune 500 company. I realize the audience here on HN - but that's a very important distinction to make.
johngalt 16y ago
This reminds me of "you go to war with the army you have, not the one you want". It's easy to think about what the perfect greenfield solution would be, but this is rarely the case. There's the "best" solution, and the "most applicable" solution. In my conversations with non-technical managers I spend much more time arguing against the "best" solution, and for what best fits our situation. If I can't reach them I will break out this line: "Nothing would make me happier than to spend more money and time on new technology, but I think we can meet your needs with X."
melvinram 16y ago
A lot of comments here seem to be missing what the post was intending to communicate (IMO.) It's not about whether starting from scratch is okay or not. It's not about whether mixing various technologies to get to something that works is okay or not. It's about aligning business needs with the execution plan and the resources available.
elliottcarlson 16y ago
I was brought in to a company a while back and took on the leadership role for a while (then brought in a friend to actually be the CTO as I wanted to be pure hands-on). When I arrived at the company, the original code base was a mess - originally outsourced to India, then given to a company in China and then a developer in the Czech Republic. The code was using amazing code like "$sourceboy = $sourceboy;" and tons of other gems. Anyhow, the decision was quite clear a rewrite was in order. The original code base received a little love here and there to make it work, but in the end we replaced it all and the company ended up selling for a little shy of 8 digits. While you may not be able to just scrap it all, there is no reason you can't do things the right way behind the scenes and then relaunch the right way over time. I think a good CTO or leader should recognize what will be better for the company, and perhaps at times that does indeed involve maintaining what you have - but if it is indeed broke; it's also in your best interest (as well as the company's) to fix it.
DanielRibeiro 16y ago
The point it makes is one aspect that Mike Cohn's chapter on Financial Prioritization really gives great insight (http://my.safaribooksonline.com/9780137126347/ch10 http://my.safaribooksonline.com/9780137126347/ch10). In the end, such issues are a business decision, and making it can be very detailed and complex or very concise and simple, depending on things like project size and how agile must you be. But they are business ones. Looking into them through any other lens risks a series of possibly very bad decisions.
rickmb 16y ago
The role of the CTO depends on the context. Sometimes you lead, sometimes you just facilitate. Sometimes you focus on technical quality, sometimes you focus on business objectives. It all depends on the balance within the company and the companies objectives. Bottom line is that you base your strategy on what the company needs, not on some abstract notion of a good CTO. The only consistent objective is to make yourself as superfluous as possible by creating a balance between engineering quality and business objectives that maintains itself without constant management interference.

89 points by wdaher 16y ago

It also means having root access. All kidding aside, that is the central question of being a start-up CTO. All non-business building aesthetics and measurements are out the window until you have customer #1. After that, the goal is to support the customer as best as you can. If ugly code is making modifications difficult, then you rewrite only then. If it is working, then for all that is holy leave it alone. If the code is beautiful and a change will make it ugly, then it will be ugly. One of the lessons I wrote about goes core to this. There is more value (to a company) in learning how to navigate, manipulate, and fix large bodies of ugly/shit code than trying to rewrite it in a perfect way.

netaustin 16y ago

Broadening the idea of a CTO from startups to companies with long track records, I've always thought of ideal CTOs as those who can balance risk and stability, growth and retention. They are elastic enough to handle being stretched between the business/product/finance goals of the organization and the engineering required to make the product actually go. Good CTOs know about all the shiny new things but have the good taste to apply them only when appropriate, can manage the finances of an engineering team, and aren't afraid to hire developers who might be smarter and better than themselves.

imajes 16y ago

I sorta disagree. Sometimes being CTO is about instituting technical leadership from scratch. There have been a couple times where i've worked with a company (as a contractor) and helped them in a CTO role. This has ended up with a need to scrap everything and start again. That decision was acceptable because of the complete lack of any technical experience in house (100% outsourced, multiple vendors) who had very different patterns of development. Couple this with no tests, no process and no patterns, you're stuck trying to work against something that's unpredictable. The way forward then is to hire a team (even if it's just one guy) internally who can have ownership of code. Then instituting good practice and a sensible method of rebuild and rediscovery. Obviously this hinges on having enough runway to get into it properly. tl;dr: sometimes it's ok to scrap it all and start again when your goal isn't about preserving code but instead is about building a better product and technical culture inside a company. Getting downvotes - I wanted to add something: There's a real risk of making problems worse when you don't have any ability to stop and change. Working with existing code is great but when you have existing customers running into bugs on a daily basis, and fixing them would change the business logic that others are relying on, you either choose to build more technical debt or you swallow it and start again. Obviously this depends on runway, position, etc. There are many times when companies go through their proto and raise seed only to find that their original hypotheses aren't working, and to change requires a significant re-architecture. Bolting this on to existing codebases can end up with code so complex that it won't stay up, and you end up spending six months in pure fire-fighting ops mode to keep the thing alive. Knowing when to recognize this and acting accordingly is the right approach, even if that sometimes means calling it a day on the existing code and starting again.

auxbuss 16y ago
I'm calling bs on this. You have to keep the train moving. That keeps the cash coming in. You can't stop the train. So, you have to take what you have and somehow -- that's what you are being paid for and hopefully you have the chops -- manoeuvre the beast into a better state. This is fscking hard, especially when you have to get the darn thing under test. And it's invariably massively undervalued by most biz management teams. You can _always_ extract value from operative but shitty code, even if you have to stick your head around the U-bend and pull it back with your teeth. If you don't know that yet, then you've more to learn.
- imajes 16y ago
  I don't know. When you're trying to build a team in a market where there are more jobs than qualified applicants, telling them that you have to 'rescue' an app is a turn off and won't get you anywhere. Also, when the real value within the app is a simple product, breaking it out and re-engineering based on what you've learnt takes about roughly the same time as it does to walk through the code line-by-line and add in valuable tests. Refactoring legacy code by multiple vendors is always a risky proposition (and much much harder to sell to clients who want a deadline for delivery).
- variety 16y ago
  "rewriting systems" != "stopping the train" (if done properly).
- fdagggee 16y ago
  There are lots of reasons that technological assets can be very poorly aligned with a company's current goals. In those situations, a redesign is often warranted. I've often seen it occur as a confluence of: bad hires, poorly managed projects, companies that change direction, and availability of better solutions to the same problems. Just because something can be done, doesn't mean it's the best use of resources. CTOs are responsible for making intelligent fix/replace decisions, and it really doesn't sound like you're advocating that at all. Rather, it sounds like you're advocating an ignorant 'only fix' position.
- 16y ago

alanstorm 16y ago

You can tell a lot about the culture of an organization by comparing the official and unofficial duties of the CTO vs. the COO. One of the better things I've seen written about what a CTO is came from this Rands quote "There are two classes of Free Electrons. Sr. Electrons and Jr. Electrons. Both have similarly productivity yields, but the Senior versions have become politically aware. In technology savvy organizations, most CTOs fall into this category." http://www.randsinrepose.com/archives/2005/03/20/free_electron.html http://www.randsinrepose.com/archives/2005/03/20/free_electr...

dansingerman 16y ago

"one of Seattle’s most impressive companies, I Can Has Cheezburger? " - Really? Does that say more about Seattle, or the Web at large? (Or was this just a joke and I missed the point?)

dgraunke 16y ago
Check out this comment and its responses: http://news.ycombinator.com/item?id=1857342 http://news.ycombinator.com/item?id=1857342
cookiecaper 16y ago
I found it kind of weird that the guest post on this guy's blog was his friend talking about how great the blog's owner is.
- danshapiro 16y ago
  That's me. Scott asked me to do a guest post and had no idea what I'd come up with. I'd been telling folks this story about him for a while, so I figured it was as good an excuse as any to share it with a wider audience.

brianwillis 16y ago

This reminds me of Joel Spolsky's Things You Should Never Do (http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html). It's old advice, but still as relevant as ever.

variety 16y ago
It's relevant, but he didn't really mean it to be taken at face value. Because of course it just isn't true (even though people keep repeating it a lot, for some reason). The world is full of tons and tons of successful, large-scale software systems (from apps to languages to databases to OSs) that were not only "rewrites" of older systems, but had to be written because the original system had incurred too much technical debt. So what Joel really meant, deep down inside, was "okay it's not that you should never replace large systems from scratch; it's just that you should be very circumspect about it, OK? You don't just go knee-jerkedly ripping out the old stuff just because it's a ugly, a pain to deal with, unsexy, etc. You have to look at the whole picture, and understand the (true) business costs of what you're doing. That's all I'm saying."
- edanm 16y ago
  I'm not sure about that. What I took away from the article is this: whenever you're thinking of rewriting from scratch, there's a better way - incrementally replacing the code. It's not as fun, and it feels worse, but it ends up with much better code. I'm pretty sure this is nearly always true. Joel outlines the reasons, but the most important one, imo, is this: you're not going to do a better job. You think you are, because you see that the code is a mess and think you're better than the people who designed it. And you're probably right (or at least, you know more.) But a system that has years of work on it is not something you can whip up again from scratch - you're going to miss all the same things they missed the first time, when they were designing it, and either recreate all the bugs, or make your new system a mess. Incremental improving is nearly always the saner solution.
  - ulrich 16y ago
    I second that. It's not the "rewrite" that is bad, but the "rewrite from scratch". You might end up with a completely different codebase if you do it incrementally.

blantonl 16y ago

What it means to be a CTO at a startup is significantly different than what is means to be a CTO at a Fortune 500 company. I realize the audience here on HN - but that's a very important distinction to make.

johngalt 16y ago

This reminds me of "you go to war with the army you have, not the one you want". It's easy to think about what the perfect greenfield solution would be, but this is rarely the case. There's the "best" solution, and the "most applicable" solution. In my conversations with non-technical managers I spend much more time arguing against the "best" solution, and for what best fits our situation. If I can't reach them I will break out this line: "Nothing would make me happier than to spend more money and time on new technology, but I think we can meet your needs with X."

melvinram 16y ago

A lot of comments here seem to be missing what the post was intending to communicate (IMO.) It's not about whether starting from scratch is okay or not. It's not about whether mixing various technologies to get to something that works is okay or not. It's about aligning business needs with the execution plan and the resources available.

elliottcarlson 16y ago

I was brought in to a company a while back and took on the leadership role for a while (then brought in a friend to actually be the CTO as I wanted to be pure hands-on). When I arrived at the company, the original code base was a mess - originally outsourced to India, then given to a company in China and then a developer in the Czech Republic. The code was using amazing code like "$sourceboy = $sourceboy;" and tons of other gems. Anyhow, the decision was quite clear a rewrite was in order. The original code base received a little love here and there to make it work, but in the end we replaced it all and the company ended up selling for a little shy of 8 digits. While you may not be able to just scrap it all, there is no reason you can't do things the right way behind the scenes and then relaunch the right way over time. I think a good CTO or leader should recognize what will be better for the company, and perhaps at times that does indeed involve maintaining what you have - but if it is indeed broke; it's also in your best interest (as well as the company's) to fix it.

DanielRibeiro 16y ago

The point it makes is one aspect that Mike Cohn's chapter on Financial Prioritization really gives great insight (http://my.safaribooksonline.com/9780137126347/ch10 http://my.safaribooksonline.com/9780137126347/ch10). In the end, such issues are a business decision, and making it can be very detailed and complex or very concise and simple, depending on things like project size and how agile must you be. But they are business ones. Looking into them through any other lens risks a series of possibly very bad decisions.

rickmb 16y ago

The role of the CTO depends on the context. Sometimes you lead, sometimes you just facilitate. Sometimes you focus on technical quality, sometimes you focus on business objectives. It all depends on the balance within the company and the companies objectives. Bottom line is that you base your strategy on what the company needs, not on some abstract notion of a good CTO. The only consistent objective is to make yourself as superfluous as possible by creating a balance between engineering quality and business objectives that maintains itself without constant management interference.