During the dot com bubble, I was a founder and startup CTO. At the beginning I wondered what to do as a CTO. There were many conflicting views on that position. From programming to vision, from technology to processes, from tools to people. After some time and more years at managing development teams and departments, my view on the CTO role is much clearer. I’ve distilled the (web) startup CTO job down to:
- Write code – often forgotten, but you need to be able to write code, and if you’re one of the first technical hires, there is not enough work for you if you do not write code.
- Decide if to hire or to outsource. There are reasons for both, but I’d say in 90% of cases one should hire. The CTO needs to decide which way to go, and – especially important be prepared to defend his decision. Buying is usually not the way to go for a technology or web startup. This doesn’t mean there can’t be a mix, there are often projects which can and should be outsourced.
- Hire developers, testers, admins and operators. Several times I’ve been asked to be the CTO for a startup, as in Germany most web startups are founded by ex-consultants or economics majors. They usually have no clue – nor should they have – about good or bad developers. As a CTO you need to provide this knowledge and hire the best you can get for your budget.
- Know how to scale development and processes (from 1 to 10 developers e.g.). Development changes significanty if you go from one to five and then to ten developers. You need some kind of process (I for example prefer Lean and Scrum). As a startup CTO you need to provide this in the first years (certainly not first months).
- Know technologies, craft an architecture and technology strategy.
- Know how to scale an application (from 100 to millions of users).
What do others think about the CTO role? Werner Vogels, CTO of Amazon, defines four roles a CTO can have:
- Infrastructure Manager
- Technology Visionary and Operations Manager
- External Facing Technologist
- Big Thinker
Many people have contributed to shaping the CTO role in startups. Indus Khaitan thinks the “5 Bare Minimum Things A Web Startup CTO Must Worry About” are:
- Security
- Availability & Monitoring
- Application Errors
- Backup
- Source Control
I do agree with them, though I’m not sure Source Control is in my Top 5. Security depends on what you do and what framweworks you use, so this might not be an issue for some time into startup life. Availability gets more and more important when your customers increase and revenue over your plattform increases. Monitoring is a must from the beginning, it’s hard to add later – you lose especially a lot of insight if you have no monitoring, insight which is dearly needed in your first incident. Backup is often forgotten or underrated – do not forget to see if you really can get your site going again from a backup.
Eric Ries writes on the role of the CTO:
The CTO’s primary job is to make sure the company’s technology strategy serves its business strategy.
with five specific skills:
- Platform selection and technical design
- Seeing the big picture (in graphic detail)
- Provide options
- Find the 80/20
- Grow technical leaders
This is a great oversight of the CTO responsibilities, there is much more juice in that article, go ahead an read it.
Tony Karrer ponders the question “Startup CTO or Developer”:
What worries me a bit is how often I read that startups should hire a developer / hands-on lead developer. I understand the desire for hiring someone who is going to product product. But often the result of a Founder hiring a developer or lead developer or even a VP engineering is a gap created between the founders and the developers. [...] By the way, I’m not suggesting that startups should hire a full-time Startup CTO who is not hands-on. Rather they should get a part-time Acting CTO who can help close the gap.
Then there is the open question, after you’ve been some time into a startup, what is the difference between a CTO and a VP of Engineering? A very good answer can be found – at least it was enlighting to me – at Mark Suster blog in “Want to Know the Difference Between a CTO and a VP Engineering?”:
The CTO [...] So I believe that every great technology startup has the technology visionary inside the company. This is the person who lays the foundation of what should be built. [...] And first and foremost a VP of Engineering is a people manager.
The VP of engineering is basically managing people and processes, while the CTO is managing technology and the vision. My take on this:
- In the beginning you better need a CTO that also does a VP/E job.
- Later you can split the position and hire a VP/E for processes – if needed
Coming back to the tilte of the post: “Want to Become a Startup CTO?” – These are skills to have and the role to play. I hope this made the CTO role clearer, technical and non-technical founders. See if this is really for you, perhaps know what your boss should do and focus on. What is your take or experience on the CTO role?
BigPipe is a way of thinking for web pages. It introduces the concept of pagelets, small parts of the website. BigPipe was implemented at Facebook:
BigPipe is a fundamental redesign of the dynamic web page serving system. The general idea is to decompose web pages into small chunks called pagelets, and pipeline them through several execution stages inside web servers and browsers. This is similar to the pipelining performed by most modern microprocessors: multiple instructions are pipelined through different execution units of the processor to achieve the best performance.
BigPipe renders the structure of a webpage and then adds the content via JavaScript, a kind of inlined AJAX. The result is that users see content earlier and progressivly. Just reload a Facebook page and see how different parts are loaded. This reduces latency and especially changes the perception of users: They think the website is faster. A side effect of splitting the page into pagelets is how each pagelet can be rendered in parallel with asynchronous IO on the server or with an IO thread pool.
With threads, message piping or a worker model very long running service calls do not stop the page from loading, it will only prevent showing the pagelet that is slow. Each thread can have a timeout and you can kill long running or blocking service calls – a SLA for page calls.
Sam Pullaras mustache.java follows the same principles, breaking rendering into parts each with it’s own thread to reduce latency.
I’ve implemented a proof of concept of BigPipe in Java (should run as-is in every servlet container):
This will result in the following HTML code – see how content2 is rendered before content1. Due to threads the order in which content arrives is non-deterministic.
Some problems I’ve encountered:
- You need the correct content type, content encoding and doc versiom, otherwise the page will not render progressivly
- Your framework needs to enable flushing the output at certain points, so content is pushed to the browser
I would like to have some framework support and I’m taking a look into how to do this in Play.
Updates: 1. I do love Scala as proven by this blog 2. I’m critical of the things I love 3. I’m ok with a language that is marketed as a research language, I’m not ok if this language markets itself as post functional, the next big thing and a Java successor.
Update 2: Community response as expected: Everything is fine, personal attacks, move on. How sad. Sorry, shouldn’t have written this as pk11 pointed out.
Scala is Unfit for Serious Development (where serious means you want to make money from it, compared to a hobby). Fact. Because it’s object oriented? No. Because it’s functional? No. Because of the complex type system? No. Because of the love of symbols over words? No. It’s unfit because the developers and the community are unwilling. Since one week I haven’t written one productive line of code, but have been stuck in 2.8 version hell. One little upgrade due to a bug in a library put me into this hell trying to get the code running again. The major points are:
- The developers are interested in language research and writing papers, not in making a language for real development
- The version hell that is 2.8 – calling this version 2.8.0 is deceptive. As Python (3000) or Ruby (2.0) this should have been a major version called 3.0
- The developers do not care about binary compatibility, deprecated, soft migration or API compatibility. Things are changed on a whim – from one RC to the next, and they change major parts of the language/libraries in point releases
- They remove and add classes just as they see fit
- The community loves cutting edge. Instead of fixing bugs they upgrade to all new released RCs – so have you. It’s called cutting edge for a reason: You’ll cut yourself. And it’s called bleeding edge because you will bleed.
In 15 years of Java I never had those problems. I could focus on writing production code.
The sad thing is: There is no alternative. No statically typed, functional, object oriented language with enough libraries to get going. Would love to use C# if it’s not from MS. Due to no other options I will stay with Scala (Clojure with static types would be heaven [edit] or with x:String instead of #^String x). A sad day.
Thanks to @pk11 and @debasishg for their help and patience.
From Martin Odersky – see comment below:
Wow, what a controversial posting, and what an avalanche of reposes. Let me just
clarify some points.
1. 2.8 is a difficult release, on the order of Python 3 vs the 2.x series. We are almost there.
2. RCs are by definition bleeding edge, and unfit for serious development. Wait until 2.8 final is out — I expect that to happen within the week.
3. “Scala’s developers are interested in language research and writing papers, not in making a language for real development.” That one you got totally wrong. In fact I am about to take a leave from university and found a startup to do commercial Scala support. I am taking some of the key Scala developers with me.
4. Binary compatibility: Yes, it’s a tricky issue. I have said in the past that we will address this issue for releases from 2.8 onwards. And that’s still the plan.
