DEV Community: Mario Hayashi

Trade-offs leading tech at early-stage startups

Mario Hayashi — Tue, 05 Jan 2021 12:06:40 +0000

If you're a first-time tech founder or lead at a startup, you'll find yourself spending an inordinate amount of time making trade-offs. You'll need to pick a tech stack that works for your team; decide how much time to invest in visual design; balance your vision with the most valuable thing you can deliver to your user right now.

This post intentionally confronts this controversial topic head on. I feel it's a topic that's not talked about nearly enough. Tech founders and leads often find out they'd spent countless hours on creating something no-one wants only after the fact (myself included). Having built tech from scratch at multiple startups and talked to other tech founders in the past, I've noticed that some (if not many!) first-time founders and tech leads find out the hard way that they may have taken the wrong turn when they were presented with a trade-off.

Here, I talk about the most common "questionable turns" taken that I've experienced for myself, heard about or seen others experience. These thoughts may be controversial and you might not agree with most of them but I will feel I've contributed something if you might agree with just one!

Tech stack: Some founders spend lots of time thinking about the tech stack, trying to pick the "perfect" technologies. It's good to explore. But don't spend an inordinate amount of time thinking about it. Before I joined my first early-stage startup, I was given helpful advice (from my CTO at the time) to "just build". Your startup might not exist in 18 months. Pick things that work right now.
Hire the right people: I was really lucky when we hired someone who was extremely talented at my first tech lead role. I learned things daily from him. He had opinions (something I've come to value a lot). We iterated fast. I've seen the opposite however too: hires who've struggled to push any code and shown not much engagement despite trying to accommodate. Founders inevitably need to make a decision whether or not to let that person go, so make sure to hire well (or be prepared for it to hurt!).
Trust: Give everyone the benefit of the doubt. At the beginning, everything might be all over the place. That's ok. Introduce or suggest the right processes that you and others can trust. That way, structure will come and you'll be able to make progress. If there's distrust from the get-go, it'll be hard to make it work long-term. Everything will feel "transactional".
Testing: One experienced CTO once told me that testing is overkill at a startup pre-Product-Market Fit (PMF). And I think he's mostly right: at many startups, if you're iterating fast, you'll be throwing away lots of code. Yes, there are some exceptions — code for financial transactions, mission-critical applications, etc. where bugs can be disastrous — but for most pre-PMF startups that are creating a few REST APIs and a React.js front-end, focusing on testing may be overkill. Start testing when your product starts to stabilise. Be comfortable with tech debt. You can address tech debt when you reach Series A and your team is growing (when there's an obvious need for tests). It's ok to do things that don't scale at first.
Documentation: Only document as much as you need to communicate with your team. Creating a big project implementation plan may be a waste of time in a small, nimble team. Instead, make sure to communicate in daily stand-ups, comms tools, etc. Similarly, documenting code is secondary at an early stage. You may throw away lots of code and the API may change a lot. Note: this is not to be confused with good practices, such as good naming conventions and code structure, which are a must. Documenting code will become a productivity multiplier once you have more than a few engineers but not until then.
Goals: Make sure to define goals. You might think building tech counts as progress. It is but only if it's contributing to your company's wider goals. Without goals, you'll have less alignment in the team (yet another risk you can't afford at an early stage) and you're leaving success to chance.
Analytics: Similarly, make sure to install analytics from an early stage, tracking the most important metrics. I've seen founders regret not measuring early enough. That includes me!
Design: Both UX and UI design are fluid, especially at the start. You're still trying to find PMF, so naturally your UX will evolve. UI design and the visual language will change as your branding becomes more clear. Therefore, spending an inordinate amount of time creating the perfect design system is a bit of an overkill. I would suggest sitting down with the designer to work out the most pragmatic path to a product that allows users to accomplish their jobs (if you're using JTBD). Often designers are just trying to paint the "ideal" picture. Designers are very pragmatic and will design around technical limitations if you flag them. Also, some product designers may prefer using existing design systems to iterate faster (such as Material, Bootstrap or Tailwind).
Speak to users: You might be getting siloed in "tech", either because responsibilities are defined in binary or there's so much product development to do that you don't have time for other things. If it's the former: ownership doesn't mean others can't be involved. Speaking to customers can be driven by your co-founder but your team will benefit from your involvement as you'll better understand what product to build. If there's too much on your plate: ask yourself, would you prefer to do things the right way or do the right things? Speaking to users de-risks the possibility that you're building the wrong thing.

Here are some rule-of-thumbs that have helped me, with some of the trade-offs above:

Pick speed and limit scope: The Product Management Triangle: you can only pick two of speed, scope and quality. Obviously pick speed, as iterating is key to developing product at an early stage. Of scope and quality, try to limit scope so as to minimise the sacrifices you make with quality. Also, limiting scope will help you iterate faster.
Over-communicate: Always over-communicate your intentions. You might be a small team but it never hurts to share too much. It's never too early to introduce 1-on-1's. If silence is the norm in your startup, ask yourself if that's ok. If silence is the manifestation of lack of trust or "we have nothing to talk about but work", then it might need addressing. Your opportunity cost is your time, so make sure that whatever you're working towards is communicated!
Be pragmatic: Not everything is black-and-white. So making a rule in the first week and expecting it hold for the next months is unrealistic. Take information as it comes and act on the information. The startup that processes the information most efficiently (the advantage of being a startup!) often makes the most progress.

These are just some of my thoughts around tech founder trade-offs. Some may be controversial but I hope there may be some things that you could relate to, from your current or past experience.

10 things they don't teach you about AWS

Mario Hayashi — Thu, 31 Dec 2020 13:05:05 +0000

Some things that I've picked up over the years that may not be obvious when starting out with a new AWS service.

Create SSL certificates in us-east-1. CloudFront's provisioning infrastructure is based there, so is only compatible with us-east-1 certificates.
IAM. May not be obvious to the newcomer: permissions are granted via statements in Policies, which are assigned to either Identities or Resources.
CloudFormation vs Terraform. CloudFormation features oddly sometimes lag behind Terraform, which uses AWS's API under the hood (not CloudFormation's).
Lambda deployment too big. Consider AWS Lambda Layers when your deployment package size has exceeded Lambda limits.
AWS Lambdas suffer from cold starts. Tackle it by reducing your package size. Also, you get at least the same amount of CPU in the init phase as in the handler. You get the init phase for very close to free, so move as much application code as possible outside of your handler function. Subsequent invocations can also reuse resources outside the handler.
SQS deliverability: Standard queues guarantee at least one delivery, FIFO queues attempt one delivery. Make sure your application code makes the correct assumptions/de-dupe as necessary.
AWS KMS is your friend. Use it to encrypt your keys. Think twice about what goes into environment variables or Parameter Store.
AWS RedShift performance. RedShift queries perform a lot better with Distribution Keys. Set them up early.
AWS Cognito customisation. ~~You can't customise AWS Cognito verification emails.~~ As suggested in the comments, you can now customise verification email with code. (See docs.)
AWS Credits. Most accelerator programmes offer you AWS Credits. Join one and ask for them.

Edit: Helpful resource, in case you haven't come across it — Open Guide to Amazon Web Services (GitHub).

Cover: "AWS - Amazon Web Services Office in Houston, Texas" by Tony Webster is licensed with CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/

Do web/mobile app copy changes get handed over to you in Notion/Sheets?

Mario Hayashi — Mon, 14 Dec 2020 03:53:54 +0000

Hey! 👋

This Q is for devs who work on web/mobile apps and have PMs/marketers/designers who write the copy for these apps in Notion/Google Sheets...!

How frequently do you get asked for copy changes (in Notion/Google Sheets)?
How annoying/easy is it for you to update the copy in your web/mobile app?

I wanted to research your opinions, as I'm the maker of CopyOcean (posted about last week), which turns web/mobile app copy in Notion Tables into GitHub/Gitlab Pull Requests. Your feedback will be very helpful! Thank you 🙏

Write copy in Notion, export to JSON

Mario Hayashi — Wed, 02 Dec 2020 22:20:59 +0000

Hey there! 👋

I made a Low-Code project that I’d welcome feedback on —

Aimed at devs, PMs and copywriters, CopyOcean takes copy from a Notion Table and exports it to JSON, so developers can easily drop it into the app (https://www.copyocean.com). It also makes i18n a breeze!

It was motivated by experience in product development where copy management was often messy and ad-hoc. Unnecessary communication overhead, outdated copy and lost productivity were some of the problems that came with copy changes. CopyOcean attempts to solve this problem by using Notion Tables as a central source for copy and helping you add the copy to your product with a machine-readable export (JSON).

Would love to know from you (a) how your copy process looks like today and (b) whether this is of interest! Of course any other thoughts welcome.

Made a blog on software contracting/freelancing

Mario Hayashi — Wed, 07 Oct 2020 13:40:56 +0000

Hey! 👋 Just wanted to share a blog (contracto.dev) I made to describe my experiences as a software contractor. I usually take on jobs like React.js, Node.js, Serverless and more.

If you're curious about software contracting, its challenges and benefits, I've written a couple of posts on it:

Let me know if you have any Qs!

Where to start with SQL? A few posts to help beginners

Mario Hayashi — Mon, 05 Oct 2020 17:13:24 +0000

There are tonnes of SQL resources out there. This small project I made over the weekend — How do I SQL? — collates them to make it a bit more digestible. Hope it helps!

Why SQL? https://howdoisql.com/why-sql
List of SQL resources: http://howdoisql.com/resources
List of SQL courses https://howdoisql.com/courses