I don't fully agree with this, it depends on what type of project you are working on.
There is a certain type of cowboy programmer that depends on thinking quickly and having a good memory. This type of programmer can write code that works, really quickly -- provided the size of the project can fit entirely in their head. Because of this, they can do really well on small size projects but they never learnt proper code design and architecture skills, because they never needed them. This type of programmer ends up not being able to scale as the size of the project gets larger, because eventually they reach the limit on how much code they can remember at one time, and the lack of code design that lets you reduce the number of things you need to be aware about in order to write new code without breaking anything really starts to bite you.
Maybe I did not state things very well. This isn't just about short term projects. Some things will take many months of work to complete (e.g. v1 of some key scalable infrastructure).
It is not about doing short fast sprints - it is about being long term productive as a member of a team. Productivity includes good design and thinking through what is needed up front. But it is also about marrying thoughtfulness to efficiency.
Just so I understand: You're always willing to trade intelligence and experience for someone who produces more, for essential key components of your startup. So you would hire a less experienced person who writes more code over a very experienced slow developer, do I have that right?
All that does is trade the short term risk of not having as much developed with the long term risk of having a broken system. It means you're potentially betting your business on someone who isn't the best, just because they seem more productive.
In summary, you risk making a Friendster instead of a Facebook.
Let me know if I misunderstood your point.
I hire on both: smart people who get it done. And getting it done is relative. Unless you're in consulting, velocity is almost never the issue compared to correctness, so a smarter, slower person is sometimes the right choice. A member of my team took a long time to come up to speed, and is now kicking ass and making the right decisions to keep things on track.
No. What I am saying is intelligence and experience are crucial (intelligence more then experience in my book). Also crucial is the ability to get shit done and culture fit.
I want candidates with all these things.
If someone is very very bright but not very effective, or terrible for the culture of my startup, I would not hire them.
If someone was an amazing culture fit, but not very bright, I would not hire them.
"Coming up to speed" makes sense. It is all about the context in which the person is working, what they did before etc. Productivity takes time to scale, as does trust in one another, working as a team etc.
But there are some people that you give a lot of time and attention to that just don't get a lot done.
There is a certain type of cowboy programmer that depends on thinking quickly and having a good memory. This type of programmer can write code that works, really quickly -- provided the size of the project can fit entirely in their head. Because of this, they can do really well on small size projects but they never learnt proper code design and architecture skills, because they never needed them. This type of programmer ends up not being able to scale as the size of the project gets larger, because eventually they reach the limit on how much code they can remember at one time, and the lack of code design that lets you reduce the number of things you need to be aware about in order to write new code without breaking anything really starts to bite you.