“People” includes finding the following types of team members:
- early employees (not co-founders but next 6-12)
- employees (“real employees”)
The temptation is to get co-founders and early employees who are all coders and then get a contractor or “real employee” who does test/QA but as John Steuart, a partner in the VC firm Claremont Creek pointed out in a recent panel at Startup Epicenter on “Scaling up Your Product Development” the real risk comes from not hiring/attracting two kinds of people:
- Prior experience working in a startup that successfully scaled up rapidly.
You need someone who has successfully negotiated the rapids of high growth and know s how to spot problems very early. You have to consider your infrastructure not to be a robust wooden structure that will creak and groan and flex under stress but more like a glass sculpture that will give very little warning before it shatters under load. You have to have someone listening for the barely perceptible high pitched screech of too much stress before current systems, processes, methodologies collapse.
- Marketing & Business Development expertise.
Size of market, share of market, and price points that the market will support for your offering are typically 10-100X the risk of any development challenge that you face in a new or emerging market.
The key to successfully adding a new person to the team in the early days is to recruit people you already know, have worked with before and had prior shared success with. Or people that other current team members can vouch for based on direct prior work experience.
Why? There is a model of team developed called “Forming Storming Norming Performing” that was originally proposed by Bruce Tuckman in 1965. Essentially with folks you have already worked with you can either skip the forming/storming phases or move through them (and not get stuck) quickly whereas a new team finds it very hard to avoid a period of poor performance as they learn to work together. And not all teams progress beyond Storming/Norming to actually perform which accounts for a reasonable amount of “infant mortality” in new businesses.
You should prioritize the management hires first. Not absolutely, in the sense that you should hire strong people, against a plan, whenever you find them. But in general it’s a better idea for a couple of reasons
- They give you more bandwidth for the hiring process.
- It’s harder to hire folks to work for a manager who is yet to be hired.
- It’s normally better to let a manager build their team, and they may be able to bring folks with them from prior successful teams. This is not to say that other strong players won’t refer good people as well.
A few bright high energy folks go a long way. A few can energize a team and help you to challenge some basic assumptions (if you will listen to them). But you also need folks with relevant work experience who understand what the company will become if you succeed.
Fred Brooks has noted “adding people to a late software project makes it later.” There are a number of reasons for this, and it’s not always true, but in general you have to budget for new hire orientation and acclimation to the team, as well as the ongoing communication overhead of more people on the team (“many hands make light work” does not always apply to software development). This not only means that they are not as productive during their first few weeks to months but that they also take cycles from other team members in getting oriented. To the extent that you can plan for this by assigning a “buddy” (or having a manager on board first as well) or investing some effort in documenting existing development processes and practices (and maintaining a repository of past decisions, whether it’s a simple e-mail archive or a wiki for specs or a content management system) you will cut the amount of calendar time and “other people” time needed to ensure a new hire is a productive member of the team.
I think you have to plan for a “probationary period” of 3 months where you make sure that a new hire is fit and able to satisfy the minimum requirements for the job (this should be in your offer letter and be reflected in a minimum vesting period for any options). Be more concerned about a misfit around values than a lack of knowledge (unless the person actively mis-represented their experience). The first is not likely to change, the second can be easily remedied if the person is motivated and you and your team are able to invest the time.
Finally, “trust is built over time” and across a series of interactions. Nothing should make the hair stand up on the back of your neck faster than someone you’ve just met saying “trust me.” And vice versa: if you find yourself saying “you’ll just have to trust us” you should consider how to substantiate that you will do what you are committing to. if you don’t have a work history with some shared successes with your potential team member(s) you need to take things one step at a time: create some small shared successes before you take larger risks. Unless you both know someone who can vouch for each of you to the other, and will help you spin up the firm, take things one step at a time and be clear on what you are asking for and what’s in it for the other person.
Trackback from your site.