Peter Thiel is wrong about this specific thing
A contrarian perspective on contractor vs employee mission alignment
In Zero to One, Peter Thiel suggests that startups should only hire full time, on site employees that are given a stake in the company’s success.
In this, random, easy-to-find-on-Google post, Edward Igushev says contractors are, “Not part of the team, have no mission, and have no vision.”
If you’re reading this and have spent any time in the startup world, you know that it’s axiomatic that a startup will have its own, in-house dev team.
But let’s really think about this for a second. What is the real difference between an in-house developer and a contractor?
An in house developer is taxed differently.
An in house developer might have some potential upside in the form of incentive stock options.
There are some laws about things you can tell employees to do (how and when to work) that you technically shouldn’t tell contractors to do, so from this, you might be able to squeeze more out of an in-house developer without paying more as long as your squeeze doesn’t cause them to quit.
I don’t think there’s any other difference. Where does this whole idea come from that the in-house startup developers buy into the mission more? Have you been on Twitter? Doesn’t seem like in-house developers are all that mission driven. Look at this guy just trying to maximize his TC (total compensation):
Do you really think that your team of developers cares that much about your vision? Are they not just hoping that the company will succeed so that their options pay out? Who among us hasn’t learned to act in ways that earn us promotions?
This might sound contrite, but I don’t think there’s anything structural about the difference between employees and contractors aside from money that lends itself to vision alignment. When Uber’s drivers were making fat stacks, they were sooo aligned with Uber’s mission, and now that they’re barely scraping by, they are not aligned.
Let’s review where we are. We looked at the common wisdom from both the most powerful startup person in history, Peter Thiel, and a random guy on the internet, and they said to hire full time, on-site employees for your startups. Post pandemic, and with startup levels of cash, on-site isn’t even an option, and we also just saw stock options are the only structural forcing function for mission alignment for in-house developers.
My personal, contrarian experience as employee vs contractor
I now want to go through two memorable episodes in my own experience—one as an employee, and one as the owner of a business that sells teams of software developers as a service.
Me, a low loyalty employee
In the first episode, I was at IP Commerce, an early fintech that was trying to build what Stripe eventually built. I was an employee with stock options, and I was completely bought into the mission when I started. “To the moon!”
After a little over a year, I started noticing some dysfunction and tribalism at the company. Work felt more like vying for face time with CEO Chip Khan than making business progress. As a Product Manager, then Business Development Manager, I had done everything my 29 year old self knew how to do to point out the flaws in our approach. To anyone that would listen, I said, “You can’t start with a platform! You need at lease one killer use case to start with!” I wanted us to focus on a specific problem and build something customers would pay for, because so far all we had done was build APIs that could link payment service providers with application builders if either side of that market was interested. They weren’t.
Frustrated beyond belief, I applied to another fintech called Mocapay because a few key people from IP Commerce had already jumped ship and gone there. I remember having secret calls with Mocapay from my IP Commerce office, and on one of those calls, Mocapay CEO, Rod Stambaugh, said that Mocapay would give me a $5,000 signing bonus (in 2006), if I would leave IP Commerce without giving two weeks’ notice.
That was honestly a pretty awful thing for Rod to do. Don’t do that shit, people. Two weeks is not going to make a difference in your startup, and if it does, you’re a bad manager. But there I was with a loyalty test. I made a low loyalty, un-Thiel-like decision. Even though I was a full time, on-site employee with stock options, I submitted my resignation to IP Commerce effective immediately. And guess what? I still had the ability to exercise my options! LOL
I’m not particularly proud of that moment. I never spoke with IP Commerce’s CEO again, and I also burned a bridge with my direct boss Peter Osberg that I was later able to at least partially repair when, you’ll never believe this: the company that bought the assets of IP Commerce and placed Osberg in charge, hired Kelsus to build some features!
This low loyalty moment is especially interesting when juxtaposed with a more recent story.
Me (ie Kelsus), a high loyalty contractor
Kelsus had a client named Aion Robotics. They were a robotics startup looking to sell remote sentries and ranch management robots. Their CEO, Nick Nunno painted a vision of using top of the line hardware to produce autonomous robots at a fraction of the cost of what similar robots were going for from other startups (like Boston Dynamics or Blue River Technology—acquired by John Deere). If he could achieve his vision, ranches would be able to get cattle driving robots for $50,000 and construction sites would be able to get a mobile sentries for $20,000.
Kelsus put together a team of developers that built an Android-based controller app for the robots—one that allowed for either direct control or programmatic task planning, and we built a fleet management system using AWS’s IoT services. Two things started to happen as we worked that caused me some concern.
Aion started having money problems. They were bootstrapping the company with short consulting stints that the founders would do for defense contractors.
Expectations and reality started to diverge. We could see the real size of the project versus the timelines and budget that Aion had been driving towards, and they were very wrong.
Kelsus didn’t have any experience writing software for autonomous vehicles (which we had been vocal about—Aion were supposed to be the robot experts). When Nick declared that the project was already behind schedule but wanted significant additional features such as to be able to remotely steer a robot using an IoT messaging protocol called MQTT, we were clear in our communication about how unrealistic our timelines were. MQTT is an unreliable messaging technology meaning that the design of systems using MQTT must account for lost messages. When you’re remotely steering robots, you need to rely on your robot receiving instructions so it doesn’t drive into a parked BMW or a person.
As my earlier IP Commerce employee self, when faced with the prospect of no pay and completely unrealistic expectations from a boss, I would have resigned effective immediately. My company owning self—contract Jon if you will—saw things differently. Kelsus had a reputation in the community and we had made commitments to the project. We didn’t intend to work for free, but we also weren’t going to walk away from our client, potentially ruining Aion’s business, if the client could show us a reasonable path to finishing and funding our planned work.
We set some aggressive goals with Aion. We would continue developing for three more months despite being owed over $200,000 as long as we had a clear, achievable set of features, were paid in advance for any additional development, and were first in line when Aion started paying debts.
To Aion’s credit, they were able to do some additional consulting and pay down the total bill so that it wasn’t quite so large (still north of $100,000 😳), but unfortunately, they weren’t able to use the limited, and sometimes dangerous robotics system to secure additional funding.
It was an expensive lesson for Kelsus, but it’s instructive when viewed from the perspective of mission alignment. The developers on that project, Jose, Jero, and Juaquin crushed themselves to try to overcome a bad situation and build against an ever-growing pile of requirements. I daresay they even sometimes had fun:
So when you hear that voice in the back of your mind that tells you you’re supposed to have an in-house dev team, maybe check through the list of startup failures here, and see how many of them failed because their team wasn’t in-house. It’s zero.
Thanks for reading!
Send fintech startups our way! (Really. Do this. We want to talk to them.)
I’ll see you next week,