The bit about hiring contractors, especially for vital functions such as infrastructure and support is bad advice. A high quality contractor charges a very high hourly rate (it also usually isn't feasible to give them a sizable equity grant in its place), so you're left hiring people who would prefer a full time job but can't get one. This creates a poisonous and unpleasant atmosphere, which makes you even less likely to hire strong people full time.
I understand that "war for talent" is a popular narrative, but you note that those writing about it are almost always journalists who aren't programmers themselves. Non-technical writers don't understand quality developers want something more than a paycheck: they want to work on challenging problems, with people who they can learn from and in a company that has a shot at making an impact on the world. If you want to hire quality people than you should take hiring (all steps: from employment branding to interviewing to closing) a top priority: give employees time to interview candidates (expect each engineer to interview at least two or three candidates each week), be willing to let a position go unfilled for a _long_ time until the right person is found.
In short, be ready to reply "we'd like to do Y, but either we must strip out a feature X from Y, spend more time working on it or transfer an engineer working on Z to work on Y". If you're working on a hard technical problem, then your investors and customers shouldn't have a problem with that. If you're not (and there's nothing wrong with that), change your hiring strategy appropriately e.g., if you're building CRM software, stop trying to go after TopCoder finalists and ex-Google Search Engineers and instead look for engineers who are interested in business and product design/development. The former aren't going to be interested in joining you (other than at an exorbitant rate) until you're ready to use their talent, the latter will help you build the business to the point where you will need their help scaling it.
To use a vulgar analogy, the strategy of hiring a contractors to "move faster" is analogous to a man having nine one night stands hoping to conceive a baby in a month ("because I can't find the right long-term partner, and nine months is too long to wait anyway"): it's wrong on many levels and will poison your culture. It's long been known (Brooks' Law) that adding more "bodies" to a project to a project that's at risk of being late will only make it more late. Creating a company full of dubious quality contractors (with no loyalty, no "fire in the belly" about the product) will make your company look toxic to engineers used to working at "talent brand" companies where engineers are passionate about what they're working on and are confident in their technical abilities.
The CEO's real job is to manage the managers ("no, we don't have the resources to ship X at time T"), and sell the company (including to prospective employees). The blog post doesn't read "wow, this is a company worth leaving or turning down an offer from {Google, Facebook, Microsoft, etc...} for!".
I don't approve of her leaning on contractors so much, but HN comments have be to the most well written exemplars of armchair quarterbacking I have ever seen.
I agree that a startup should hire multi-talented people. But it's a bit extreme to say that startups should hire people who can do UI design, backend programming, and do business deals. Certainly such people are useful, but they're incredibly rare and are probably more interested in founding their own startup.
Also, I don't agree with the "just contract it out" philosophy. The problem you run into with contractors is that even if they're good, they don't have anything invested in what they produce. They don't have to live with it long-term.
I'm not saying that it's bad to hire contractors, only that you have to be careful with them. And I certainly don't think that it's a good idea to hire contractors because they're easier to find and fire than full-timers. In fact, many times it can be harder.
The important thing that I think Jess forgot to mention is that inDinero doesn't contract out critical parts of the sites. It's usually smaller things that we want to get done that aren't important enough for the full time engineers. Example is a small ad that we run to get user feedback on the dashboard page, something easy to build but not super critical part of the site.
We also make sure all contrator code goes through code reviews, which takes up my time but ensures that no code enters our site that isn't up to our caliber of quality.
P.S. I'm an engineer (Rohan) who works at inDinero in case that wasn't obvious.
I come from a retail management background, so I'm a newbie to the tech industry.
The guys who taught me retail management put extreme emphasis on training. Training and knowledge dissemination was a top priority for the management teams I worked with. Once I was managing my own stores, I adopted this world view and had great success.
Coming from this background I'm sometimes surprised there aren't more articles about improving the flow of knowledge and communication within organizations.
So what gives? I learn a lot of stuff on my own (as do most of my tech savvy friends), is that the way things work in tech? Or are training and communication just not discussed very often because they're seen as so elementary?
training in the UNIX industry is largely ignored (or done so badly that it might as well be ignored) by the business folks. But informal mentoring is extremely common.
Your UNIX folks will informally organize themselves around the best people, regardless of the org chart you try to impose from above. Part of the job of being the senior person is mentoring the newer people. This is done informally, but fairly consistently across most places I've worked.
It really depends on the organization. But in general, it's expected that you take some level of ownership over your own training. On the other hand, it's impractical to expect that people will know every element of your technology stack. Most of the time, it's expected that you know the core of the technology stack (like the programming language), but it's ok not to know every technology. And even then, you're expected to be able to get up to speed on what you don't know quickly and without sucking up too much of your peers' time.
The problem with knowledge transfer in the tech. industry is one of purpose. The vast amount of implicit knowledge, the little tricks and gotchas that are always different from job to job and the lack of systematic documentation make any sort of formal training program extremely difficult to implement.
> Someone who can do business deals, write code, and do user interface design, is 5X more valuable to us than a typical backend engineer.
Absolutely.... If you can find someone who is _equally_ good at all of those. Very rarely (I personally have never) you will see someone _equally_ apt (and good) at both left (Writing programming logic, Solving tough technical problems etc. ) and right ( designing User Interactions, Doing business deals etc.) brained work. Humans are not programmed like that.
Sure there are people who can get by doing multiple domains, but they are rarely fit/enjoy/brilliant at all of them.
Talent is subjective and fairly assessing one's own abilities is impossible, but I have been employed in both programming and design jobs and have received a lot of positive feedback in both domains. Given that, I think the thought processes behind each are very similar:
In programming, design is just as important as logic. Code not only needs to be functional, but it also needs to look good. A visually attractive codebase is much more maintainable due to the basic human response to beauty.
In design, logic is also just as important. When designing an interface, for example, you are constantly solving problems about how the user is going interact with the design. The process of getting there is exactly the same as solving a programming problem.
I think there is a lot of ebb and flow if you don't typecast yourself. As a young kid I was quite interested in the arts. I remember spending a lot of time drawing and honing my visual skills because that's what I enjoyed doing. As I got a little older, I became fascinated by logic problems, remember spending a lot of time learning how to program.
Interestingly, as it relates to this discussion, now that I have grown older still, I actually have become much more interested in business and is one of the reasons why I follow this website. While I've closed a few deals along the way, my business deal abilities definitely lag behind the aforementioned skill sets. That I chalk that up to being much less experienced, not because of any genetic hinderances, however.
It is of my opinion that the biggest limiting factor is time. I was, perhaps, lucky that I started young which afforded me more time to put focus on both design and programming. Whereas for someone else who started programming in college it becomes difficult to fit in time for other interests, such as learning design. I know I spend less time doing business type work than I would otherwise like to because my plate is already full with other jobs. Because of that I miss the opportunity to grow in that area.
Eh, I think there is an expense angle to that as well. I can get pretty good unix people for cheap, if I'm willing to take someone with poor communication skills. I can get someone with good communication skills for cheap if I'm willing to take someone with poor technical skills. Now, some of this can be solved by training, and some of it can be solved by making different people work together, but not all of it.
There are people who really are good at everything; but those people are as useful as they are rare, which makes them expensive. Usually, if you want a generalist, you are right, you take a skill hit vs. paying the same money to a specialist with large weaknesses in other areas.
After reading most of the posts in this discussion, I really feel like people here see contractors as uninvested workers. I always invest 100% of myself in every single project I join as a contractor, and this is very important for me, which makes me read your comments like insults to what I do.
My age and relative lack of typical corporate experience may of course give me a bad vision of the market. Maybe most contractors are not working the way I do, which would make the advice Jessica gives a bad one. But even in this case, generalization may prevent you from working with interesting people.
Disclaimer: I'm working as a self employed engineer, mostly doing jobs with my team, and far from being someone "who would prefer a fulltime job but can't get one".
I like reading Jessica Mah's blog, so I'm sorry to jump right into the nitpicking. But something in she wrote doesn't sit quite right with me...
She writes that finding talent in silicon valley is like trying to find water in the sahara, but then a few sentences later says "We had a lot of talented people apply for full-time jobs, but they either lacked culture fit, or cost too much money."
Unfortunately, there's a lot left unsaid here, and it would help to hear something more specific. For example, what was "too much money"? What attributes contributed to a candidate's "lack of culture fit?"
If you're looking for fast on-boarding I would recommend Vagrant (http://vagrantup.com). It's built for reducing project setup overhead which can be an expensive proposition if you're juggling resources as she suggests in the article.
> It's typically difficult, if not impossible, to scale up and down your engineering team in the way you can spawn up new cloud servers. We're trying to change that by having a reliable source of contract engineers who can help us grow non-essential components of our codebase.
Sounds like an awful place to work. Treating your most valuable asset as a commodity? Let me know how that works out for you.
> ... non-essential components of our codebase ... to build lower priority features that our core team doesn't have time to get to." [emphasis added]
Sounds like they've already got their most valuable assets, the employees, where they need them the most (presumably on core product). Using contractors to fill the lower priority gaps doesn't seem so bad in that context.
However, I could see it becoming an issue if something that was previously considered non-core suddenly turned out to be critical (e.g after changing direction based on customer/market feedback)
Agree with Ted. I've heard so many horror stories from people who thought this way in the beginning. Yishan Wong, would give you good stories about, how zuck tried the contracting route when Accel funded them and very soon pressed the hard revert button.
Jessica - I'm a YC founder too, and most people have strong opinions on this. (http://bit.ly/9uDFfe); Maybe, you should ask pg, what he thinks.
Her approach seems to be saving money by outsourcing less critical stuff and spending the savings on team-building trips and a more experimental culture driven by a smaller and more competent core team. That really isn't a bad idea at all.
I think that if you hit a situation where you want to create something, but lackthe expertise or time in house, it is perfectly reasonable to outsource. Sometimes "good enough" is the best way to go for a startup. I think you should have the expectation that at some point you will have to completely redo it (although that is a risk with any development). The cost of repeated work is often worth the value of iteration and speed.
Agreed - but this is what happens when a 20 yr old is the CEO. Could MSFT have been started by contractors? I don't think so. Also, quickbooks online is 10X better, get those contractors working!
[+] [-] strlen|15 years ago|reply
I understand that "war for talent" is a popular narrative, but you note that those writing about it are almost always journalists who aren't programmers themselves. Non-technical writers don't understand quality developers want something more than a paycheck: they want to work on challenging problems, with people who they can learn from and in a company that has a shot at making an impact on the world. If you want to hire quality people than you should take hiring (all steps: from employment branding to interviewing to closing) a top priority: give employees time to interview candidates (expect each engineer to interview at least two or three candidates each week), be willing to let a position go unfilled for a _long_ time until the right person is found.
In short, be ready to reply "we'd like to do Y, but either we must strip out a feature X from Y, spend more time working on it or transfer an engineer working on Z to work on Y". If you're working on a hard technical problem, then your investors and customers shouldn't have a problem with that. If you're not (and there's nothing wrong with that), change your hiring strategy appropriately e.g., if you're building CRM software, stop trying to go after TopCoder finalists and ex-Google Search Engineers and instead look for engineers who are interested in business and product design/development. The former aren't going to be interested in joining you (other than at an exorbitant rate) until you're ready to use their talent, the latter will help you build the business to the point where you will need their help scaling it.
To use a vulgar analogy, the strategy of hiring a contractors to "move faster" is analogous to a man having nine one night stands hoping to conceive a baby in a month ("because I can't find the right long-term partner, and nine months is too long to wait anyway"): it's wrong on many levels and will poison your culture. It's long been known (Brooks' Law) that adding more "bodies" to a project to a project that's at risk of being late will only make it more late. Creating a company full of dubious quality contractors (with no loyalty, no "fire in the belly" about the product) will make your company look toxic to engineers used to working at "talent brand" companies where engineers are passionate about what they're working on and are confident in their technical abilities.
The CEO's real job is to manage the managers ("no, we don't have the resources to ship X at time T"), and sell the company (including to prospective employees). The blog post doesn't read "wow, this is a company worth leaving or turning down an offer from {Google, Facebook, Microsoft, etc...} for!".
[+] [-] jimbokun|15 years ago|reply
Isn't this the same as the generalists she recommends hiring?
[+] [-] alnayyir|15 years ago|reply
[+] [-] j_baker|15 years ago|reply
Also, I don't agree with the "just contract it out" philosophy. The problem you run into with contractors is that even if they're good, they don't have anything invested in what they produce. They don't have to live with it long-term.
I'm not saying that it's bad to hire contractors, only that you have to be careful with them. And I certainly don't think that it's a good idea to hire contractors because they're easier to find and fire than full-timers. In fact, many times it can be harder.
[+] [-] HaloZero|15 years ago|reply
We also make sure all contrator code goes through code reviews, which takes up my time but ensures that no code enters our site that isn't up to our caliber of quality.
P.S. I'm an engineer (Rohan) who works at inDinero in case that wasn't obvious.
[+] [-] zinkem|15 years ago|reply
The guys who taught me retail management put extreme emphasis on training. Training and knowledge dissemination was a top priority for the management teams I worked with. Once I was managing my own stores, I adopted this world view and had great success.
Coming from this background I'm sometimes surprised there aren't more articles about improving the flow of knowledge and communication within organizations.
So what gives? I learn a lot of stuff on my own (as do most of my tech savvy friends), is that the way things work in tech? Or are training and communication just not discussed very often because they're seen as so elementary?
[+] [-] lsc|15 years ago|reply
Your UNIX folks will informally organize themselves around the best people, regardless of the org chart you try to impose from above. Part of the job of being the senior person is mentoring the newer people. This is done informally, but fairly consistently across most places I've worked.
[+] [-] j_baker|15 years ago|reply
[+] [-] quanticle|15 years ago|reply
[+] [-] random42|15 years ago|reply
Absolutely.... If you can find someone who is _equally_ good at all of those. Very rarely (I personally have never) you will see someone _equally_ apt (and good) at both left (Writing programming logic, Solving tough technical problems etc. ) and right ( designing User Interactions, Doing business deals etc.) brained work. Humans are not programmed like that.
Sure there are people who can get by doing multiple domains, but they are rarely fit/enjoy/brilliant at all of them.
[+] [-] skidooer|15 years ago|reply
In programming, design is just as important as logic. Code not only needs to be functional, but it also needs to look good. A visually attractive codebase is much more maintainable due to the basic human response to beauty.
In design, logic is also just as important. When designing an interface, for example, you are constantly solving problems about how the user is going interact with the design. The process of getting there is exactly the same as solving a programming problem.
I think there is a lot of ebb and flow if you don't typecast yourself. As a young kid I was quite interested in the arts. I remember spending a lot of time drawing and honing my visual skills because that's what I enjoyed doing. As I got a little older, I became fascinated by logic problems, remember spending a lot of time learning how to program.
Interestingly, as it relates to this discussion, now that I have grown older still, I actually have become much more interested in business and is one of the reasons why I follow this website. While I've closed a few deals along the way, my business deal abilities definitely lag behind the aforementioned skill sets. That I chalk that up to being much less experienced, not because of any genetic hinderances, however.
It is of my opinion that the biggest limiting factor is time. I was, perhaps, lucky that I started young which afforded me more time to put focus on both design and programming. Whereas for someone else who started programming in college it becomes difficult to fit in time for other interests, such as learning design. I know I spend less time doing business type work than I would otherwise like to because my plate is already full with other jobs. Because of that I miss the opportunity to grow in that area.
[+] [-] lsc|15 years ago|reply
There are people who really are good at everything; but those people are as useful as they are rare, which makes them expensive. Usually, if you want a generalist, you are right, you take a skill hit vs. paying the same money to a specialist with large weaknesses in other areas.
[+] [-] uniclaude|15 years ago|reply
My age and relative lack of typical corporate experience may of course give me a bad vision of the market. Maybe most contractors are not working the way I do, which would make the advice Jessica gives a bad one. But even in this case, generalization may prevent you from working with interesting people.
Disclaimer: I'm working as a self employed engineer, mostly doing jobs with my team, and far from being someone "who would prefer a fulltime job but can't get one".
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] geebee|15 years ago|reply
She writes that finding talent in silicon valley is like trying to find water in the sahara, but then a few sentences later says "We had a lot of talented people apply for full-time jobs, but they either lacked culture fit, or cost too much money."
Unfortunately, there's a lot left unsaid here, and it would help to hear something more specific. For example, what was "too much money"? What attributes contributed to a candidate's "lack of culture fit?"
[+] [-] johnbender|15 years ago|reply
[+] [-] known|15 years ago|reply
[+] [-] tedjdziuba|15 years ago|reply
Sounds like an awful place to work. Treating your most valuable asset as a commodity? Let me know how that works out for you.
[+] [-] amirmc|15 years ago|reply
Sounds like they've already got their most valuable assets, the employees, where they need them the most (presumably on core product). Using contractors to fill the lower priority gaps doesn't seem so bad in that context.
However, I could see it becoming an issue if something that was previously considered non-core suddenly turned out to be critical (e.g after changing direction based on customer/market feedback)
[+] [-] myprasanna|15 years ago|reply
Jessica - I'm a YC founder too, and most people have strong opinions on this. (http://bit.ly/9uDFfe); Maybe, you should ask pg, what he thinks.
[+] [-] trevelyan|15 years ago|reply
[+] [-] mchusma|15 years ago|reply
[+] [-] johnrob|15 years ago|reply
[+] [-] suking|15 years ago|reply