It’s all so situational. In an early stage startup you really have to focus on the most critical things. I would question doing a lot of marketing early when it may be more important to do sales or just low scale, high touch customer testing/research. If it’s not worth your time to do it personally there is a huge risk in trying to hire someone to do it. The reason is that most people with the credentials to “run a function” in a successful business will be used to way more resources than a startup has. ICs with experience in the role will likely have only worked in structured environments where they will have all kinds of assumed constraints that are not relevant to this brand new startup.
That’s not to say I disagree with your points in general, but just that hiring is every bit as much of a minefield as doing things yourself. In either case you have to understand what is most crucial for the next stage of growth and prune everything else obsessively.
I agree it's situational (there's also a good argument that e.g. being a pretty mediocre customer-facing guy is an extremely useful learning curve about customer needs for a very early stage technical CEO despite what they don't learn about enterprise sales). The general nature of the advice was part of the objection to the original comment.
If you're really motivated to participate in x you should try, if you're a bootstrapping solopreneur you may have no choice, but if you're looking at mitigating hiring risk, a month trying to code/sell/design outside your comfort zone doesn't really move the needle on figuring out how to evaluate programmers or whether your startup actually needs a sales team. (If anything, you're more likely to get the wrong answers from the DIY approach because maybe the sales function actually would be beneficial if it was carried out by someone who could sell...).
That's where you get more insight in less time from leaning on people in your network who actually are marketers or salespeople or product people to get a view, especially if they're not financially incentivised to propose a particular route.
If you want to mitigate the risk that ICs need structure and resources, you focus your hiring on candidates that have worked without structure and resources. But even having a codebase written by someone learning not to rely on Scrum meetings and JIRA tickets to prioritise is still better than having one written by someone learning to code.
100% agree to all of this. There's an interesting balance of domain knowledge/skills/experience and potential/learning speed/adaptability. You are ostensibly hiring for the former, but the latter is a multiplier in a startup environment. A huge number of candidates will be in the 0-1 range compared to a more structured company. You need the >1 folks.
Comments
It’s all so situational. In an early stage startup you really have to focus on the most critical things. I would question doing a lot of marketing early when it may be more important to do sales or just low scale, high touch customer testing/research. If it’s not worth your time to do it personally there is a huge risk in trying to hire someone to do it. The reason is that most people with the credentials to “run a function” in a successful business will be used to way more resources than a startup has. ICs with experience in the role will likely have only worked in structured environments where they will have all kinds of assumed constraints that are not relevant to this brand new startup.
That’s not to say I disagree with your points in general, but just that hiring is every bit as much of a minefield as doing things yourself. In either case you have to understand what is most crucial for the next stage of growth and prune everything else obsessively.
I agree it's situational (there's also a good argument that e.g. being a pretty mediocre customer-facing guy is an extremely useful learning curve about customer needs for a very early stage technical CEO despite what they don't learn about enterprise sales). The general nature of the advice was part of the objection to the original comment.
If you're really motivated to participate in x you should try, if you're a bootstrapping solopreneur you may have no choice, but if you're looking at mitigating hiring risk, a month trying to code/sell/design outside your comfort zone doesn't really move the needle on figuring out how to evaluate programmers or whether your startup actually needs a sales team. (If anything, you're more likely to get the wrong answers from the DIY approach because maybe the sales function actually would be beneficial if it was carried out by someone who could sell...).
That's where you get more insight in less time from leaning on people in your network who actually are marketers or salespeople or product people to get a view, especially if they're not financially incentivised to propose a particular route.
If you want to mitigate the risk that ICs need structure and resources, you focus your hiring on candidates that have worked without structure and resources. But even having a codebase written by someone learning not to rely on Scrum meetings and JIRA tickets to prioritise is still better than having one written by someone learning to code.
100% agree to all of this. There's an interesting balance of domain knowledge/skills/experience and potential/learning speed/adaptability. You are ostensibly hiring for the former, but the latter is a multiplier in a startup environment. A huge number of candidates will be in the 0-1 range compared to a more structured company. You need the >1 folks.