Didn't Work Wednesday: Staffing Draftwizard

I mentioned in a past post that I would have more Draftwizard mistakes to talk about through the course of this series. Today, is one of those days.

Actually, today’s mistake isn’t just another Draftwizard mistake, it’s what I consider the single biggest, and most painful, mistake I’ve made across any of my projects over the years!

So what is it? Pretty simple really, I hired staff too early.

Draftwizard had been breaking even, I was a believer in the industry as a whole, and I was anxious to grow into a ‘real’ company.

Plus Statsfeed was doing really well and was providing me with some capital to invest back into my other interests.

I thought I knew what I wanted to have done within the Draftwizard system (mis-judged product-market fit), and as luck would have it, I also had a really smart friend who was ready to make a job change (mis-judged smart for good fit).

It seemed like it would work out great.

In reality, there were a lot of things I just didn’t know, and other things I just didn’t pay attention to…all of which caused this to really be a HUGE mistake.

1. Turns out Draftwizard didn’t really have product-market fit. This meant that we still needed to be doing a lot of testing, experimenting, and evolving. There wasn’t a defined formula that I could just teach someone and let them go to work. There were clues and breadcrumbs that were revealing themselves, but we still needed to identify and follow the real ones.

2. Because of #1 - I really needed a partner (or multiple partners), not an employee. The person I hired was smart, and hard working, but wanted/needed direction. They were more geared towards execution than strategy (in this case). They had expressed this concern up front, but I was over-confident in my own vision and plan…I thought I would be able to put them on the right path fairly easy. They were right, I was wrong. In the *really* early days, you need everyone to be pitching in on the strategy (as they execute).

3. I hired a friend simply because they were smart and available. They executed on everything I asked them to and they did it well. But they didn’t know the industry at all, they weren’t passionate about the product or the vision, and they weren’t 'wired for the startup world’. This makes for a great employee down the road, but is a company killer in the first 10-20+ hires. In fact, I now believe about the first 5 people involved in the company should really be (strategic) 'partners’…the next 5-10 should be considered 1st hires (i.e. 'startup’ people hungry to pay their dues on the way to their own eventual startup – and still very strategic)…and then *maybe* you can start moving into hiring really smart, hard working, 'employees’.

4. We were 100% remote. Again, not a huge issue for an employee down the road, but not something that really fosters the 'startup’ juices or is conducive to rapidly finding product-market fit. We couldn’t easily feed off of each other’s wins, questions, or ideas…and we didn’t suffer through problems together either.

5. I had no idea how expensive an employee really was (both in time and paperwork). I had to pay for a payroll service and taxes for multiple states. Worse - after a year of trying to make it work, I finally had to face reality and let them go (I tried to make it easy by tapering down the hours/work)…after I was completely out of money and they were officially off payroll…I still had to pay the companies share of unemployment for a few months (out of pocket because the company was completely broke). This also made my company and personal taxes a bit of a mess.

6. It was painful for the employee too - the job didn’t pay a lot, there was no real direction given on a day-to-day basis, and even though they executed really well on all that they were asked to do, I *still* had to let them go after a year.

So overall - it was pretty painful for both of us (and played a major role in the ultimate downfall of the Draftwizard system).

Still, I gained incredible experience and a priceless education throughout my side of the pain…and if nothing else I know for certain that it’s a mistake I won’t come close to making again!

This post has received 48 loves.


This is the personal blog of Kevin Marshall (a.k.a Falicon) where he often digs into side projects he's working on for digdownlabs.com and other random thoughts he's got on his mind.

Kevin has a day job as CTO of Veritonic and is spending nights & weekends hacking on Share Game Tape. You can also check out some of his open source code on GitHub or connect with him on Twitter @falicon or via email at kevin at falicon.com.

If you have comments, thoughts, or want to respond to something you see here I would encourage you to respond via a post on your own blog (and then let me know about the link via one of the routes mentioned above).