Answering the Question You Should be Asking: How I Build Things
Tags: career, hiring
Published: 2019-08-30 00:57:35


I was thinking about my resume, and how limited it is. How I’ll have to go into my next tech interview and do 5 hours of algorithm challenges, even though that has nothing to do with my day to day work or what I have accomplished in the last 9 years of building products and profit. Instead of doing that, I’d like to tell you how I build products. If you like how I do things, let’s chat. Let’s not bring me in to solve a problem with recursion or a bubble sort. Instead, let’s talk about my ROI.

Let’s start at the beginning. You bring me in because you want to build a new product or a major initiative. You want to build a new Netflix or Spotify or Twitter. First I’m going to ask why. Asking why differentiates this product from what is already on the market, and how will it get you customers. I could just jump into the engineering challenge, but then I would never know if I was making the right features. I want to know why you are making it because I want to be able to create an MVP as fast as possible. 

I keep this quote in mind. “No plan of operations reaches with any certainty beyond the first encounter with the enemy's main force.” - Helmuth van Moltke. No product survives its first contact with the user. They think they know, and we think we know, but no one can know until it is in their hands. So if you asked me to make Netflix, the MVP is streaming a single video, or for Twitter posting a single line of text. Lists and profiles and sharing can all come later. 

I also like to think of everything that can go wrong, both engineering and human. What if a million people try to watch this video at once is an engineering problem. What if someone uses this platform to find someone they are stalking is a human problem. I won’t make products that don’t take into account the harm they can do to the most vulnerable. 

As part of the planning it's critical to work closely with all the stakeholders, both those close to engineering like Product & QA, but also those further away like Marketing & Customer Service. What are their expectations and what pitfalls can they alert me to. Building products is a team sport and it does not matter how much I score if my team loses the game. 

When it comes to the code, I try to do as little as possible. I am laser-focused on getting to the endgame, which is having that working product. I will never roll my own if I can plug in a library. Don’t get me wrong, I love trying out new technology, but it’s all about testing solutions instead of creating the 5th version of the same thing. You can see that in the products I’ve made which often involve connecting APIs to make both companies stronger. Or in the technical talks I’ve given about cloud providers and how to best utilize their products.

I’m happy to talk to you about your technical problems and how I can help to solve them. I can update legacy code to be more maintainable or make sure my coding style matches exactly how you like it. I will fix your finicky bugs and get your products out the door. I am an excellent investment, and I can’t wait to talk to you about it.