Why early technical hires ask if your company is using contractors
If you’re a technical founder, CTO or VP Engineer, and you have hired at least one software developer before, you’ve probably been asked “what’s the structure of the product and/or tech team(s) today?”
It’s relatively obvious why a developer is asking this question—they’re getting insight into the size, stage, and decision-making style of your company, which can reveal a lot about the maturity of the processes and practices of software development.
You probably are not often asked “are any of these team members contractors?” When you do field this question, it’s likely not as obvious why it’s being asked.
I’ve talked to hundreds of technical founders in my career, and I’ve asked pretty much every single one this question. I’ve found that engineering leaders and software developers anchor to entirely different things when thinking about incorporating contractors into their engineering teams.
Technical founders tend to associate contractors with speed, flexibility and targeted skill sets. At early stage (i.e., pre-seed) companies, it’s relatively common for early hires to start as contractors while they wrap up another job in a full-time capacity. “Contract-to-hire” is an emerging business category with companies like Commit, Lean Hire and Lambda Studios. For founders, contracting is one of many legal employment statuses and while the decision might include some calculations of geographical financial arbitrage, technical founders tend to care pretty deeply about integrating contractors into their team as equals.
This means when a technical founder hears the question “are any members of your engineering team contractors?” they think, “Yes, and it’s been a really useful tool!”
This is not what a software developer tends to take away from that answer. A software developer is typically asking this question as a probe to understand company culture. There is a relatively widespread (and not necessarily correct) belief in the tech community that contractors work on projects, but don’t play an active role in building the future of a company. This is especially true in software development, where there is a massive industry of product studios, development shops, and outsourced overseas contracting firms. These teams tend to work in silos, are judged based on product milestones, and are more transactional. In practical terms, these engagements tend to be treated more as resources than as people, which carries the risk that new engineering hires will also be treated more as resources than as people.
This means when a software developer asks the question “are any members of your engineering team contractors?” the unspoken subtext is “do you respect the craft of software development, and by extension, respect me?” If you’re a technical founder and you’re asked the first question, you should assume the second question is also going unsaid and answer it in tandem.
Sarah Marion leads Founder Partnerships at Commit. She’s spent her career collaborating with early stage founders as they solve valuable problems.