Why Your First Developer is Critical

Anthony Thomas of Sticker Mule

Anthony Thomas tells us how he made the leap from manufacturing to starting a tech team at Sticker Mule. He explains why your first developer is so critical to your founding team.

  • Here's what to listen for:
  • 00:51 What was your background prior to starting Sticker Mule?
  • 01:39 What was the drive to go from manufacturing into starting Sticker Mule?
  • 03:13 Did you see other companies doing what you wanted to do?
  • 04:02 What was your co-founder’s background?
  • 06:09 Did you start your company as a non-technical founder?
  • 07:42 Should a non-technical person learn how to code?
  • 10:35 Did you build any basic background in tech?
  • 11:40 Are you able to empathize more with developers having learned something about software?
  • 15:09 How did you build a technical team as a non-technical person?
  • 16:56 What interested you about open source?
  • 20:47 What do you think led your first developer to work with you?
  • 22:39 Why did you think the first developer was so critical?
  • 27:42 How are you able to evaluate a developer as a non-technical person?
  • 29:41 How do you guide the roadmap for your team?
  • 34:15 What’s an example of a time you wanted to do feature polish?
  • 35:19 What are some of the biggest productivity killers for your development team?
  • 36:16 What do you mean by incomplete and changing specs?
  • 37:18 What has helped make your specs more concrete?
  • 43:24 What challenges have you faced as you scaled your team?
  • 46:27 What advice would you give Anthony prior to starting Sticker Mule?

"We have an operational background. We have to figure out the software design and development component."

"I always regretted not learning how to code."

"To be good at anything you need to work at it relentlessly for a few years."

"If you’re starting your company and not already technical, you have more important things to work on."

"I try to learn as much as I can and gain a deeper appreciation of software development."

"There’s not always high impact things to do. During my downtime I try to pick up as many things as I can."

"The less clear something is, the longer it’s going to take to develop."

"The more simple and concrete it is, generally the easier it’s going to be to figure out how to implement."

"I went to @rpi and I think that school just gives you a deep appreciation for engineering."

"We had a similar perspective on the importance of simplicity and the importance of a good UX."

"Really smart engineers want to be around other really smart engineers and want to avoid more mediocre ones."

"If you do bring a B player onboard, the work they do becomes part of your code for the foreseeable future."

"I put a lot of effort into saving our developers’ time by explaining things clearly and concisely."