DEV Community: Michael Lin

OCR - The most impressive feature in ChatGPT-4

Michael Lin — Thu, 28 Mar 2024 00:13:17 +0000

One of the features I’m most impressed with in ChatGPT-4 is its OCR capabilities ⬇️

I inputted a picture of a Pokemon card, and it was able to:

⚫ read blurry text description
⚫ assess the quality of the card
⚫ recognize the Pokemon depicted
⚫ correctly count and interpret symbols
⚫ extract text and numbers regardless of its position

I’m surprised this isn’t talked about more because it makes many OCR API’s obsolete.

For example using Amazon Textract to achieve this same objective would require extra logic to scan for text above, left, right, and below a key.

It also doesn't handle symbols, synonyms, and abbreviations well.

What was many lines of code and error prone before is now replaced with just a few lines of code using OpenAI’s API.

If you're interested in building on these API's, I've linked to the GPT-4 Vision docs here:

https://platform.openai.com/docs/guides/vision

🤖 I Built a Customizable Chat-GPT Bot. Here’s How to Build Your Own (with screenshots)

Michael Lin — Fri, 09 Jun 2023 07:01:00 +0000

I’ve been working on a side project lately.

It’s a Chat-GPT bot that you can train to answer questions by uploading PDF documents with custom context.

Recent conversations I’ve had with clients inspired this project. In the last few weeks, three different people asked me about building Chat-GPT related bots. Some use-cases for a tool like this include:

Building a Personal Chat-Bot - A nutritionist wanted to reduce their time spent answering repetitive questions by providing Chat-GPT with the most common questions they get and having the bot answer for them.
Enterprise Knowledge Management - Another client had a folder of business strategy documents and Powerpoints, and wanted a way to query them for stats and insights when preparing for meetings.
Cover Letter Writing - One client spent a lot of time writing cover letters for jobs and wanted a way to feed it examples of past cover letters that resulted in an interview. That way the bot could write a custom cover letter in their style for any job.

Despite the different use-cases, they all have two things in common:

Each client had custom context they wanted to feed Chat-GPT
They needed a way to ask questions about that context

Although I ended up building custom solutions for these clients, I felt it was possible to build a generalized version of this chat-bot for anyone to upload context to and use.

So I spent the last week hacking away, and I just finished building it!

You can see a screenshot of the product below.

You can also try it out right now 👇

Try the Demo Chatbot

Below, I’ll discuss how this product works, how to get a copy of this bot up and running yourself, and areas for further improvement.

How to Use This AI ChatBot

Using this ChatBot involves 3 steps:

Copying your OpenAI API key over to the app
Uploading your PDF files as context
Inputting a question

So get started, create an OpenAI account and get your API keys at this link here.

Then paste it into the API Key form in the first box of the app. See the screenshot below.

Now upload all the context you want to train Chat-GPT with.

Do this by clicking the 2nd box below, uploading all the PDF files, and clicking “Construct Index”. This step will prepare them for querying later.

You can think of indexing like organizing a room. If you spend time upfront organizing, then when you search for your keys later, it won’t take as much time because everything is where it should be.

So by constructing the index first, the app will organize your data so that future searches will finish faster.

After you’ve constructed the index, you can ask questions about the context you gave it. Go to the next box, input your question, and click “Query Index”:

Afterwards you should see a response to your question below:

Which is indeed what the test document says. Magical!

Note that indexing is an optimization. It is possible to skip the indexing by:

Uploading the files
Inputting your question
Clicking “Query without Indexing”

However there are two limitations that come with not indexing.

First, there’s an upper limit to how many words we can stuff into a prompt. This limit is around 3000 words, or 4k “tokens” as Open AI calls it.

If we don’t index, we would have to stuff all the text from our files into the prompt, which would likely be more than 3000 words.

This would cause us to get an error like the one below:

Second, if we don’t index first, Chat-GPT can be slow to return a response. When I skipped the index construction and directly called “Query without Indexing,” it took the bot over 15 seconds to return a response in the example above.

However, when I constructed the index first and then queried it, it took the app about 7 seconds to return a response.

So constructing the index helps improve the speed at which the Chat-Bot returns answers.

How to Build This App Yourself

The tech stack for this app is:

Python Flask server as the backend
Heroku for deployments
Bubble as a no-code UI

In fact, if you just:

Clone this repo
Create a Heroku account and connect it to that repo
Copy all the settings I have in this demo Bubble app to connect it to your server.

Your chat-bot should just work!

I’ll go over these steps in a bit more detail below, but first let’s go over the key components of this app, starting with the
Python Flask Server.

Python Flask Server

The Flask Server is the code that makes all the buttons in the app work. It contains 3 API’s that correspond to the 3 buttons on the page.

Construct_Index()
Query_Index()
Query()

The full source-code is here. I’ll go over the most important parts of the code below.

Construct_Index()

Constructing the index is fairly simple, as Open AI has an API for this. The first line of code below is what generates the ndex, and the second line is what stores that index in a file locally on the server.

Query_Index()

This is also fairly straightforward as it just loads the index we created from the last step, and then passes the users’ prompt straight to it:

Query()

Note that this API won’t construct an index, and it will call OpenAI’s API directly with the context stuffed into the prompt like this:

Note how we have to manually append the context to the prompt if we don’t construct an index first.

Deploying to Heroku

This is also fairly straightforward.

First, get all the files that I have in this repo by:

Creating your own Git repo
Going to my repo, and clicking “Code”
Then copy-paste the “cloning” URL, and typing “git clone ” in your terminal

After you push all of the code to your own repo, your repo should have all the same files and look the same as mine here.

Click “Code” then copy the “URL” to clone this repo for yourself.

Now create an account on Heroku and then go to your dashboard here to create an app by clicking “New” -> “Create new app.”

Once you finish the setup process (which should take less than 1 minute), you’ll be on your Dashboard page that looks like the below screenshot, where you just hit “Connect to Github” and input the name of your cloned repo.

When you’re done with that, you can click into the logs by clicking “More” -> View Logs”

And if you go in and see “Build succeeded” in the logs, then you’ve successfully deployed the app!

In fact, if you now navigate to “https://.herokuapp.com”, you should see a page like this below:

Bubble UI

Now the final part of this is to create a user interface (UI) like a website or app and connect your Flask server’s API’s to the buttons in your UI. For this part I used a no-code website builder called Bubble.

This part is actually fairly straightforward. I made the UI for the demo publicly viewable, so you can create a new Bubble app and copy exactly what I did here.

Then make these changes in the “Plugins tab”

And it should just work!

Limitations

The biggest issue with the code right now is that it stores the index locally on the Flask server. If there are too many users using this, then everyone’s index would get stored on disk and eventually it would run out of memory.

I plan to fix this eventually by storing the index in an external database, for example in AWS.

There is also no error-checking so if a user makes a mistake (for example if they forget to paste in their API Key), they will get a cryptic error message and not know what to do.

Also currently only PDF’s are supported, and the UI obviously needs some work, particularly on Mobile.

But at least it works!

Anyways, why don’t you give the app a try and let me know how it goes. If you have any questions on setting this up, or encounter any bugs, feel free to message me and let me know!

Relevant Links
Test the chatbot out here.

Link to the open-source code here.

Link to the Bubble UI here.

Questions? Comments? Need your own Chat-GPT bot built? Contact me on social media here.

💡 If You Liked This Article...

I publish a new article every Tuesday with actionable ideas on entrepreneurship, engineering, and life.

BONUS Get a free e-book w/ my writing coach's contacts when you subscribe below. (Check the welcome email).

Join 3,839 subscribers on my newsletter here.

3 Engineering Mistakes That Kill Startups

Michael Lin — Thu, 08 Jun 2023 10:55:00 +0000

I’ve been doing engineering consulting in fractional CTO roles for about a year now. And my current work is vastly different from my previous work in corporate.

For one I work with a much more diverse clientele. At Amazon I worked mostly with other engineers. With consulting most founders I work with are non-technical.

So a higher premium is placed on communication - explaining technical issues in the simplest way possible for clients.

Furthermore since most startups build product from scratch, I thought this would make engineering easier. It turns out that’s not necessarily the case.

Many of my clients spend over 6 figures and several months of time to get an MVP built only for the project to take way too long or never get delivered.

And they come to me to figure out how to get their product back on track.

Fortunately, this situation is completely preventable. And having seen this situation play out for dozens of clients now, I’ve noticed that these projects tend to go south due to the same 3 mistakes.

It happens when startups:

Misprioritize the order in which features are built
Pack too many features into the first iteration of their product
Let perfectionism get in the way of speed

If founders focus on avoiding these 3 mistakes, they can prevent countless months of frustration, and deliver their product to customers faster.

1. The Order in Which You Build Features Matters

The first mistake that founders make is they don’t ask engineering to build features in the right order.

Often founders will bring a design doc with a list of features for their product, and then ask engineering to go build it.

However, when listing features to build, the order in which you build features matters.

Specifically, you want engineering to build the core technology first, not last.

The core technology is the part of your product that customers derive the most value from.

For example, if you’re a search engine like Google, returning the right search results is both more difficult to build and delivers more value for customers than the “I’m Feeling Lucky” button.

So the search algorithm is what you want engineering to build first.

For a ride-share product like Uber, connecting you with a driver at your door in under 5 minutes is vastly more important than any account settings pages.

So the matching process between the driver and rider is what you want to focus on building first.

Which page would you build first?

I’ve seen many engineering stories play out where agencies will spend months building a UI for example, but when it comes time to build the actual software, they fail to do so.

If an agency is unable to build a particular feature that’s critical for your product, you want to find out about this ASAP.

I saw this even in a recent call. One client was trying to build a website with a financial calculator embedded in it after spending thousands of dollars with another engineer.

When I asked what happened, they showed me what their last engineer built:

The engineer spent two months building out these two pages, but they never got to the core part of their app which is the calculator!

And when it came time to build the calculator, it turned out that they couldn’t do it because some of the calculations were too mathematically complex.

Had the client asked for engineering to build the calculator first, they could’ve uncovered this confusion faster, and determined whether building the core technology was within their previous hire’s skillset.

So as you build your product, three questions to help you prioritize features include:

What part of your app do you consider the “core” technology?
What part of the app is the hardest and riskiest to build?
What features in your app have you seen already built in other products vs. something that is totally new?

With number 3, if there are parts of the product that you haven’t seen others build before, you may want to validate that that portion is technically feasible before building anything else out.

2. Asking for Too Many Features in the First Pass

A corollary to building features in the wrong order is also asking for too many features built.

This happens when clients view engineering as building “a list of features.” For example, if they see a car they see it as the sum of all the features in it including the:

Signal lights
Heated seats
A/C

And they would view building a car like checking features off a list.

However, this will almost certainly create delays in an engineering project, as it will generate a huge list of features to build and overwhelm engineering.

Instead of viewing the product as a list of features, I often tell clients to focus more on what the problem they’re trying to solve for the customer is.

For every single feature ask, “How does this feature help solve that customer pain-point?” to help cull down the list of requests for engineering.

For example the main problem a car solves is it helps a person get from A to B faster.

For an initial prototype then, we certainly don’t need the air conditioner, nor do we need a trunk, nor do we need heated seats.

If we focus on the problem, this calls into question whether we need a car at all, because perhaps a scooter, a bike, or even a skateboard could help get a person from A to B faster as well.

I often encourage founders to think about what the “skateboard” version of their initial product is, rather than thinking in terms of features.

It will help get a prototype out the door faster, sometimes reducing engineering estimates from months down to less than a week.

Example: Building a Thumbtack Clone

I recently spoke with a founder building a website similar to Thumbtack, but where you can call-in for assistance with booking.

Thumbtack is a website to book services from local pros.

Initially, they said they wanted all these integrations in their prototype including video calls, payments, and booking systems. Each of these integrations adds significant engineering work and delays the launch of their product.

But if a customer just needs help booking stuff, perhaps they don’t need any of these features. Just a way to see the list of services, call-in to specify what services they want to book, and have someone handle the rest over the call may be enough for a prototype.

In fact, this app is very similar to the first version of the food delivery app DoorDash. Although DoorDash has a lot of advanced features now, their initial website was only a number on a website that you called to tell them what food you wanted.

The founders would then call the restaurant to order the food, pick it up, and deliver it for you. No integrations or bookings, just a phone number with instructions in their MVP!

The initial DoorDash MVP

This prototype is simple enough that they could get this out within a week. But had they tried to incorporate all the fancy integrations and incorporated the huge list of features they have now, this could’ve easily turned into a multi-month project.

So in this case, I recommended the founder consider a version of their product similar to the DoorDash MVP for their Thumbtack clone as opposed to the original version they had in mind.

Building the “skateboard” version of a product, and staying focused on solving the customer problem rather than just building a list of features will help trim a multi-month project down to one measured in weeks.

3. Aiming for Perfect Engineering Architecture

The last mistake that often leads to delays is striving for engineering perfectionism.

Founders often want their product to have the perfect architecture and be perfectly scalable from the get-go, which places a big burden on engineering to meet.

They’re often worried about an outage if they get a Facebook style launch when 22,000 people visited the first version of Facebook within four hours of launch.

Even Facebook looked very different in the early days.

The reality is that most launches are actually very quiet. Countless times I’ve seen founders launch and get far fewer visits than they expected. I know because I remember launching RecordJoy.com on Reddit once expecting to rocket to fame.

Not only did I fail to get a single upvote, I also got banned from the Subreddit for spam 😢.

Sometimes this perfectionism also comes from trying to emulate the engineering practices at the biggest tech companies. They see the clean code bases and the microservice style architecture, and assume that’s how it should be done for their startup as well.

However startup engineering is very different from corporate engineering. At FANG, the companies have already reached product-market fit, so maintainability and scale are of greater concern.

Startups however are still searching for product-market fit, and they will likely need to pivot so many times that their initial system may never get used.

Often it’s better to get something functional working, validate that this is truly what customers want before investing further resources in scaling it out.

In some cases, you may find that the “hacky” solution that you initially built may take you further than expected.

This was the case for Stack Overflow.

Example: Stack Overflow’s Monolith Structure

Alex Xu, the author of System Design Interview book, once discussed StackOverflow’s architecture in a tweet.

He pointed out how if you tried to design StackOverflow with on-premise servers and a monolith in an interview, you would likely not get the job because it is considered bad engineering practice and unscalable.

But that’s actually how StackOverflow was built!

As you can see, the “perfect” architecture for StackOverflow would involve breaking down the website into separate components, like the comments, user management, and questions, and isolating each one in its own microservice.

Yet their current system is not perfect, but is far simpler and faster to build, and has still managed to scale to over 100 million visits per month!

So, there is often a practical element to engineering as well. Instead of aiming for perfection from the get go, it’s better to take an iterative approach and get 1) something working and then 2) refactor it to make it more scalable when the time comes.

Or in Stack Overflow’s case, never refactor because their hacky prototype happened to scale well too 🙂.

Conclusion

Three different mindset shifts towards engineering can be the difference between getting stuck in a multi-month engineering slog, and getting something into the hands of your customers in a week.

As a founder, if you focus on:

Paying attention to the order in which you build features
Building the “skateboard” version of your product first
Prioritizing functionality over engineering perfectionism

You too can be on your way to your next billion dollar startup.

Just remember to throw me a few bones when you get there!

💡 If You Liked This Article...

I publish a new article every Tuesday with actionable ideas on entrepreneurship, engineering, and life.

BONUS Get a free e-book w/ my writing coach's contacts when you subscribe below. (Check the welcome email).

Join 3,839 subscribers on my newsletter here.

Stop Building Startups. Start Consulting Instead.

Michael Lin — Wed, 07 Jun 2023 22:44:03 +0000

Last week, a few readers emailed me wanting to hear more about why I started a consulting business and how to get started with one.

So if you’ve ever thought about starting a consultancy, this article is for you.

Many people equate entrepreneurship with building venture-scale startups.

But startups are only one of many ways to approach entrepreneurship. In fact, startups are probably the most difficult option you can choose.

Startups often don’t turn a profit for a long time because they prioritize growth instead. This is unsustainable for folks who have a family to feed or don’t have a lot of savings.

Furthermore, many founders don’t realize at what pace startups have to grow to justify venture funding.

In Andrew Chen’s book The Cold Start Problem, he says that venture-scale companies had to hit specific milestones in order to be in a position to IPO:

Year 1 - Establish product-market fit
Year 2 - Get to $2 million in Annual Recurring Revenue (ARR)
Year 3 - Triple to $6 million in ARR
Year 4 - Triple to $18 million
Year 5 - Double to $36 million
Year 6 - Double to $72 million
Year 7 - Double to $144 million

Imagine trying to get a business to $2 million in ARR in two years. That’s an insane rate of growth that is unreasonable for 99% of entrepreneurs–myself included.

Instead more entrepreneurs should consider starting a consultancy instead. It’s more attainable and will help you avoid all of the most common mistakes first-time founders make.

First, consulting guarantees that you solve a real problem.

A customer paying you to tell you about their problems is validation that the problem exists. It has you thinking about the client’s problem first instead of building a solution in search of a problem.

Second, consulting is faster to start than building a product.

As a consultant, YOU are the product. So you’ll avoid the typical mistake of building for 6 months only to realize you don’t have a way to generate traffic for your product. Consulting has you focused on marketing yourself from day 1.

Lastly, consulting is a stepping stone to building a product later.

It’s a way to get paid to do customer research as you ideate on what to build for your future customers. It’s no wonder that many companies actually start off as consultancies.

For example, Palantir started off with government consulting by helping different agencies unify their databases. Overtime, they noticed commonalities between all their clients and productized their offering into 3 main SaaS products.

Palantir’s 3 main SaaS products.

Imagine if they just tried to build their SaaS products without consulting first, it’s unlikely they would’ve had the understanding to build the right product. Consulting also helped them create a list of customers to sell their future product to later.

A Playbook for Starting Consultancies

A consultant is nothing more than an expert in their field. So starting a consultancy is a brand-building exercise in positioning yourself as an authority. And fortunately for you, it’s easier than you think because there is a playbook you can follow.

It goes like this:

Start a newsletter
Get potential clients on your email list
Write 10 articles on the topic you want to consult on.
Use those articles to sell consulting services
Use learnings from your work experience or (ideally) past engagements as content for future articles.
Rinse and repeat steps 3-5.

Content attracts clients which creates more content to write about which attracts more clients. It’s an infinite cycle.

The reason this works is because of the 90-9-1 rule on the internet. This states that:

90% of internet users are lurkers
9% will like and comment
and 1% will create the content.

So by writing articles, you are automatically in the top 1% of people talking about your topic on the internet.

That by definition makes you a leader.

Creating content automatically puts you in the top 1% of the internet.

In fact, I noticed this is almost the exact playbook that Dan Shipper uses to position himself as an authority on generative AI.

Dan is the CEO of Every.to, a newsletter and writer collective, and I learned about him from his popular guest-post on Lenny’s Newsletter about how to build a Chat-GPT bot.

When I looked into his history, I realized he is basically following this playbook.

Since December, almost all of his content on his newsletter shifted to talking about AI: how he uses Chat-GPT in his normal life, how it will affect writers, and tutorials on how he built bots.

This puts him in a good position to be a consultant, as people are literally in the comments asking if they can hire him to build bots for them.

His content is literally driving potential consulting engagements to build chat-bots for other people.

What’s also interesting is I noticed he is an AI startup scout for Sequoia, one of the largest venture-capital firms.

I suspect that he partnered with Sequoia because they know that his writing can be used as a lead magnet to attract AI startups. And those startups he attracts are also startups he can consult for on their AI strategy.

I noticed Dan became a scout for Sequoia around the same time his content shifted towards focusing on AI.

So to help you get started, write a few articles discussing:

What do people not understand about your field?
What are common mistakes people make, and how can they avoid them?
What does the future of your field look like?

Then as your library builds, consider gathering them up and then self-publishing a book on the topic.

A Setup for Multiple Income Streams

Writing a book on your field should be a goal of every single consultant.

There is literally nothing more authority-building than writing a book on a topic. And it doesn’t even have to be long.

Greg Lim, who has published over 20+ books on Amazon, often advises his students in his “Part-Time Amazon Author Class” (aff.) to write short books that are about 20k words long. That’s the equivalent of 20 articles, which is doable in about a year of writing.

Then you can use that book as a lead magnet for your consulting.

In fact there’s a wealth advisor I know named Dan Goldie who started a wealth management firm and later published a book called The Investment Answer detailing his philosophy to wealth management.

After publishing the book, he said his business exploded. Imagine if you do this for your field, it could really bend the trajectory of your consulting business as well.

Dan Goldie’s book helped him sell financial consulting services.

Furthermore, the book is a setup for multiple income streams. Consulting is expensive, but difficult to scale. A book however is highly scalable, but relatively cheap.

So books can be a supplementary income to help you capture the most price sensitive clients who might not be able to afford your services, but still want your advice.

With a book, you’ve now captured multiple points along the pricing-demand curve: one at the bottom with books and one at the top with consulting.

This is also a setup to create multiple revenue streams to even out the income variability with consulting.

Books complement consulting well because they are on opposite ends of the pricing spectrum.

Why You Have to Mine Out Your Existing Network

The second best way to start consulting is by asking people in your existing network if they know anyone who may need your service. Your network is the biggest asset you have, and you should mine this out before trying any other options.

Why should this be your first approach? It’s the same reason that pyramid schemes teach recruits to sell their products to their family and friends first. Even they know the power of direct connections.

Tapping your existing network should be your FIRST resort, not your last.

Some ideas for who to tap in your current network include:

Past Clients

Every so often it’s worth saying hi to past clients to check up on them because they may have upcoming deals to send your way. This is what real estate agents do when they send Christmas cards to all their former clients.

They’re doing this because mass sending these cards puts them top of mind in their past clients, which leads to extra deals every year.

Don’t Turn Recruiters Away

If a recruiter ever reaches out to you even if you’re not looking for a job, don’t turn them away! Recruiters are some of the most well-connected people around, and they might know companies who are looking for help on a consulting basis.

Here’s a script you can use if a recruiter reaches out to you.

“Thanks for reaching out. Do you see an opportunity for me to help as more of an advisor than a full-time role?
I’m currently not in the market for a full-time role, but I am open to other arrangements.”

Bradley Jacobs, founder of MyLance once sent out 12 notes like this, and got 11 no’s. But the 12th one said they were open to it, and he said this one “yes” suddenly pushed him to a $25k/month engagement consulting startups part-time.

So respond to every single recruiter that comes your way, and you might land yourself a nice consulting gig as well.

Bradley Jacobs’ consulting story.

Real-Life Communities

Don’t forget the existing communities you’re in: churches, sports leagues, and your friends are all people who can keep an eye out for deals relevant to you and send them your way.

Furthermore, every person you meet is a potential referral in the future. So always look for opportunities to slip in a request for them to send referrals your way.

The way I do it is if anyone ever asks me what I do for work, I’ll say I help startups build MVP’s and that I specialize in Chat-GPT integrations. And if they know anyone looking to build their own Chat-GPT app to send them my way.

I find making this ask when the topic turns towards work is a natural segue to slipping this request in.

If work doesn’t come up, then sometimes I’ll bring it up at the end of the conversation as a last request. People are usually more than willing to help.

Getting Over the Fear of Asking for Help

As a consultant, you have to be shameless about putting yourself out there and making these asks. I struggled with this because my parents taught me to never ask for help unless I absolutely needed it.

But in consulting, your network should be your FIRST resort, not your last resort.

In fact, it’s so important that I’m going to be shameless right now:

If you know anyone looking to build their Chat-GPT app, please intro them to me over LinkedIn - thank you for the referrals! 🙏

See, even I have to do it. And hopefully you’re not too bothered by it either. So if I can get over it and make these asks so can you.

Final Thoughts

My favorite part of consulting is meeting new people from all over the world, and hearing about what everyone is building.

Consulting will also teach you how valuable your knowledge and experience is. Many people worry that they don’t have enough experience to consult, but experience is relative. And for a client with no prior experience in your field, your advice can make a serious difference in their business.

So get out there, position yourself as an expert, and close those consulting deals. I believe in you!

💡 If You Liked This Article...

I publish a new article every Tuesday with actionable ideas on entrepreneurship, engineering, and life.

*BONUS * Get a free e-book w/ my writing coach's contacts when you subscribe below. (Check the welcome email).

Join 3,839 subscribers on my newsletter here.

The Robots are Coming. Is Chat-GPT Replacing You as a Software Engineer?

Michael Lin — Wed, 05 Apr 2023 05:41:43 +0000

When I first saw Chat-GPT, I went through the five stages of grief. First I was in shock. Then disbelief. Then anger that the robots were about to put me out of a job as an engineer.

I’m now in the fifth stage of grief, acceptance. And I welcome our new robot overlords and how AI will transform software engineering.

As the founder of a software agency that helps startups build MVP’s, I have begun advising our engineers on using Chat-GPT to speed up development time.

And having built several MVP’s for clients now with extensive use of generative AI, I’ve concluded that Chat-GPT will not replace engineers. Instead, it will shift more engineers into the role of a “code reviewer” of the code that Chat-GPT generates.

This is because Chat-GPT doesn’t understand the code that it writes. It merely outputs what it thinks is the most probable next line of code based on all the other code available on the internet.

But what is most probable isn’t necessarily always right.

For example, take the following code snippet:

for (int i = 0; i < 10; ...);

I’m sure if you’ve taken any programming class, you recognize this as a for-loop. This is how we write code to iterate through a data structure.

What Chat-GPT is really doing is finding similar code all around the internet and aggregating a list of characters with these probabilities of what should come next:

Then it will usually pick the top answer and input it into the response. Do this over and over again and you get a full code snippet, similar to how it writes full text sentences.

It’s important to note that in this example, Chat-GPT doesn’t actually understand that you have to increment the counter “i”.

It’s just that “i++” happens to be what follows most often based on similar code written on the internet.

It could be that we only want to iterate on the “even” indices, in which case, we would need to skip by two with “i += 2” instead of “i++”.

But since for-loops that increment by two instead of one are more rare, Chat-GPT is less likely to choose “i += 2” even if it’s the correct answer in our context. So with Chat-GPT, you still can’t fully trust its output every time.

Instead every engineer will be a senior engineer now, and Chat-GPT is the entry-level engineer that writes the code that they review before approving it and pushing it to production.

Chat-GPT is like calling Google’s auto-complete API after every word.

Furthermore, because Chat-GPT will handle more of the implementation details, it will place a greater emphasis on understanding system design.

Stack Overflow has plenty of code snippets for Chat-GPT to train on and get boilerplate code working.

But each startup has their own system design and architecture that Chat-GPT won’t have the context to generate insights about.

That’s where engineers will shine in this post chat-GPT world.

Because system design will be more important than ever-before, I pitched Alex Xu, the king of System Design, on guest-posting this article about the future of software engineering and system design in a post-Chat-GPT world.

Alex Xu was an ex-Twitter and Apple engineer before going full-time on his System Design content.

When he said yes, I jumped at the chance. So if you’re a subscriber of Alex Xu’s ByteByteGo newsletter, your time spent studying system designs is time well spent.

It’s your understanding of system architecture that will protect your job security as an engineer more than knowing the latest programming language.

Here’s why.

Understanding System Design is Crucial in a Chat-GPT World

The main reason why software engineers won’t get put out of jobs is because the questions you ask Chat-GPT dictate the quality of answers you get back from it.

But if you don’t understand software engineering, you won’t know what questions to even ASK chat-GPT.

In my seven years working at Netflix and Amazon, I’ve realized that 90% of software engineering isn’t about knowing the answers but about asking the right questions. The right questions will guide you to the right answers.

This is the defensible moat that engineers have because non-engineers won’t know how to query Chat-GPT to get the answers it needs.

Case Study: How to Build Levels.FYI

Consider a recent case study from Alex Xu where he discussed the architecture of Levels.FYI.

Levels.FYI is a website and app that documents the salaries of software engineers and the differences in levels between companies.

Screenshot of Levels.FYI

If a non-technical person were tasked with building this, I’m certain that even with Chat-GPT assistance, they would not be able to build this website because their questions would be too broad.

Someone non-technical might ask, “How do you build an app to show salary data?”

And note how general the response is.

How an Engineer Can Use Chat-GPT to Build Levels.FYI

However, an engineer can get more out of Chat-GPT because they understand the system design of the software and just need help filling in the implementation details.

For example, let’s say we wanted to build a simple version of Levels.FYI that takes in salary data from human inputs, aggregates it, and calculates averages per company.

As an engineer, I can already guess the architecture of this product. It’s likely that there are 3 parts:

A UI to display the salary data
An intake form for engineers to input their salaries and their companies
And a database to store the data from that intake from

A simple system design would look like this:

So because I know there are 3 parts to building Levels.FYI, I can ask specific questions to Chat-GPT to get the answers I need to build it.

For example, I would start with the intake form, and ask Chat-GPT for specific technologies I should use.

Notice its first suggestion is Google Forms, so let’s roll with that as our intake form. Now that we have a way for users to input their data, we have to look for a backend database to store that data, and a way for the UI to query for it.

So then I’ll ask Chat-GPT about what technologies I can use that have the API’s I need to do that.

Notice how I specifically asked for a “no-code” solution. This is critical because more code equals more problems. It’s more work to write and more to maintain, so I know my first goal is to achieve the business goal with as little code as possible.

This is where a non-engineer will go wrong, because they often equate engineering to writing code. However engineering is not about coding. Engineering is about solving business problems in the simplest way possible. And code is just a tool to solve that problem.

While a non-engineer may get stuck asking Chat-GPT about coding details, it’s my understanding of engineering as a means to an end that helps me specify the “no-code” prompt and get the answer about using Google Sheets as a backend.

Finally I just need to get a UI to connect to a Google Sheets API, so I query:

And now I have all the information I need to implement Levels.FYI.

I use:

Bubble as a UI
Google forms as an intake and
Google sheets as a backend

And now I can query Chat-GPT for the specifics of how to code it up, copy-paste it into an IDE and make sure it works before pushing it to prod. Thanks Chat-GPT!

The beautiful thing about my 3 queries is that using Google Sheets with Google Forms connected to a front end is exactly how Levels.FYI was created.

As Alex Xu documents, Levels.FYI scaled to millions of users using only Google Forms and Sheets as the backend!

From the Levels.FYI blog

So by using Chat-GPT intelligently, I reached the same system design that the Levels.FYI founders did by asking the right questions. These are questions that a non-engineer would not know to even ask.

Although Chat-GPT won’t give me the entire design of Levels.FYI, by breaking the problem down into smaller steps for Chat-GPT and solving each one individually, I can piece together the solution to build Levels.FYI.

This is what software engineering is about anyways - algorithmic thinking. This is what Alex Xu teaches, so I believe his knowledge will only be more relevant over time.

Don’t worry Alex - your job is safe! 😅

Final Thoughts

I could just be in self-denial and a month after publishing this article, I’ll end up homeless because the robots indeed took my job.

But for now, I truly don’t believe Chat-GPT will lead to mass layoffs.

Engineers are mostly professional Googlers anyways. So what’s the difference between querying Google versus querying Chat-GPT instead?

Chat-GPT is not a replacement for understanding software engineering.

Rather than fearing Chat-GPT, it’s time for engineers to start investigating how to use it more to help them work more efficiently.

Used the right way, Generative AI will help engineers focus on system design while taking care of the tedious parts of software engineering.

In turn, it will boost the productivity of engineers and create more jobs rather than destroy them.

I think. 🤔

💡 If You Liked This Article...

I publish a new article every Tuesday with actionable ideas on entrepreneurship, engineering, and life.

BONUS Get a free e-book w/ my writing coach's contacts when you subscribe below. (Check the welcome email).

Join 3,312 subscribers on my newsletter here.

3 Ways to Create Luck in Your Engineering Career

Michael Lin — Wed, 22 Mar 2023 00:21:27 +0000

I got into Netflix by going to the gym.

When I worked at Amazon in Seattle, I noticed a guy at the YMCA on the same workout schedule as me.

Over time we started talking, and eventually I invited him to my birthday party.

It was at this birthday party that he told me about working at Netflix.

He told me that Netflix pays “top-of-market” salaries. But if you weren’t performing they would let you go with a “generous severance package.”

At the time I wasn’t looking for a job. But on a whim I threw my application into the Netflix jobs portal to see what would happen.

Two days later a recruiter from Netflix reached out.

One month later, I landed the job.

The job description said I needed 5 years of experience when I only had 3 at the time. I applied anyways.

Inviting a stranger to my birthday party resulted in me almost tripling my salary overnight, and getting a promotion to Sr. Software Engineer that would’ve normally taken me several years to achieve.

I was only 24 at the time.

Hustle culture overemphasizes “grit” as the key to success, but doesn’t acknowledge the huge role that luck plays in our careers as well.

And contrary to popular belief, luck isn’t random. It happens when you:

Go beyond your assigned work
Create content
Are willing to drop everything to chase a lucky opportunity when it arrives.

Understanding these three elements of luck will help you get luckier in your life.

1. You won’t get lucky from only doing your job.

Luck lives at the edge of your comfort zone. So to get lucky, you have to constantly try new things.

A question to determine whether you’re experimenting enough in your life is:

When was the last time you did something for the first time?

And to get lucky, make sure the answer to this question is never too long ago.

Einstein understood luck well.

One of my greatest regrets while working in corporate was focusing only on my assigned work.

The issue is that when you only focus on your work, you’re likely doing similar tasks and working with the same people over and over again. It doesn’t create novel situations that generate luck.

Luck doesn’t just happen. You have to create it.

Knowing what I know now, I would treat “getting lucky” as if it were a separate job from the actual work. I’d spend more time putting myself in situations that could lead to lucky career breaks rather than only working hard.

I saw the importance of this with how a coworker skipped the line for a promotion at Netflix.

How a Networking Event Lead to a Promotion

One of my co-workers at Netflix got promoted from an engineering role to a management role in under a year — impressive for a place with no formal promotion process.

She told me the way she got promoted was by being active in the Employee Resource Groups, (or ERG’s for short) at Netflix.

ERG’s are like college clubs within companies.

It was at one of the ERG networking events that she heard a director in another department mention how they needed to hire for an engineering manager on a new team.

My co-worker expressed interest in the role, and since the team was relatively small, the director gave them a chance. She started off managing two engineers. Two years later, she now has eight reports.

This ERG networking event was critical for two reasons:

This job wasn’t yet listed on the internal jobs board, so there was no competition for the role.
It exposed her to people outside her department. She would never normally meet this director through her normal work.

Imagine if she tried to become a manager the traditional way. She’d have to go through years of frustrating promotion cycles. Plus she’d have to compete with a long line of co-workers also vying for this role.

Attending a single networking event saved years in her career.

So if you want extraordinary things to happen to you, you have to do extraordinary things. Only following orders won’t get you lucky. But

taking advantage of your company’s ERG groups
giving talks
attending all the happy hours and team events
and going beyond your basic duties as an employee

will do more for your career than staying late at night working.

2. Content Creation — The Cheat Code to Getting Lucky

Luck happens when you’re around new people.

And one of the easiest ways to expose yourself to new people is through content creation.

Since I started writing online, I’ve noticed that content creation is a cheat-code for getting lucky. Here’s why.

90–9–1 Rule of Content Creation

The first reason why content creates luck is due to the 90–9–1 rule. This states that:

90% of internet users lurk on platforms
9% interact with content through likes or comments
and only 1% of internet users create content.

Creating content puts you in the top 1% of internet users.

So creating content gives you substantial power. It automatically raises your visibility more than 99% of people, and positions you as a leader on the internet.

1% of internet users influence the other 99% of users through their content.

The second reason is that content is an asset that you create once and generates views forever. For example, in the graph below we can see how all the articles I’ve published on Medium so far have generated about 4,300 views over the last 30 days.

That’s the equivalent of talking to 143 new people EVERY. SINGLE. DAY.

I’ve spoken to more CEO’s since writing online than I have in the rest of my life combined.

Content creation is automated networking. If you talk to that many new people, you’re bound to meet someone who could change your life.

How I Got a Paid Speaking Engagement through Medium

For example, on my second article on Medium, I wrote an article about “How to Be a 10x Software Engineer.” This article immediately took off, reaching 6 figures in views as you can see below.

A month later, I received a message from the CEO of a company who read the article and invited me to come give a talk.

He forwarded me to his CTO, we discussed logistics, and I flew in to give the talk a few months later.

From a paid speaking engagement in July 2022 that resulted from writing on Medium.

So the lesson about content creation is:

You never know who might come across your content and give you the lucky break needed to advance in your career.
Luck has little correlation with how hard you work. I spent only 3 hours writing this article, less than any other article I’ve ever written. Yet it is one of the best-performing articles I’ve written to date.

You’re always one viral piece of content away from changing your life. So get creating!

3. Luck Comes at the Most Inconvenient Times

By now you’ve created a luck-prone environment for yourself. So what do you do when luck strikes?

You have to drop everything you’re doing to take advantage of a lucky opportunity because luck doesn’t wait. When luck passes, you often won’t get another shot again.

Furthermore, luck often comes when you’re least expecting it.

So a big part of getting lucky is both spotting it, and remaining flexible enough to take advantage of it when it comes during inopportune times.

Example: Henry Golding and Crazy Rich Asians

For example, Henry Golding was a relatively unknown travel reporter for many years before getting his big break as the star of Crazy Rich Asians.

Except his big break came at the worst possible time.

He was in South Africa on his honeymoon when the movie director begged to pull him for a Warner Bros screen test.

Even worse — he was only one day into his honeymoon when he had to call it off.

Realizing this could be a make or break moment for his career, Henry understood the fleeting nature of luck, and cut the honeymoon short to chase this opportunity.

Although I’m sure his wife was not happy about this, clearly it was the right move, as Crazy Rich Asians skyrocketed his acting career and his wife’s modeling career as well.

Henry Golding with his wife Liv Lo.

Henry Golding’s story teaches us about how to act when luck comes your way.

First you have to always keep your eyes open for lucky opportunities during the most inconvenient times— including one day into your honeymoon.

Second it’s important to not fully book yourself, so you have flexibility to pounce on these opportunities.

As a fellow entrepreneur once told me, you want to leave some “slack in the system” to allow luck into your life.

Final Thoughts

Luck has a bigger part to play in career success than what we would like to admit.

Rather than asking, “How do I advance in my career?” reframe the question as, “How can I create more lucky opportunities?” instead.

By trying more “life experiments,” putting yourself out there through content, and leaving some “slack in the system”, you create an environment where lucky career breaks can happen.

💡 If You Liked This Article...

I publish a new article every Tuesday with actionable ideas on entrepreneurship, engineering, and life.

BONUS Get a free e-book w/ my writing coach's contacts when you subscribe below. (Check the welcome email).

Join 3,175 subscribers on my newsletter here.

Is a Lack of Role Clarity Hurting Your Engineering Team?

Michael Lin — Tue, 14 Mar 2023 17:07:42 +0000

Engineering consulting was not what I thought it would be.

As a temporary CTO, I thought I’d spend most of my time helping startups solve engineering problems.

Yet one year in, I’ve found that most engineering issues I deal with are actually organizational issues.

And the most common organizational issue I’ve seen is a lack of role clarity on engineering teams.

Trying to complete projects without fixing org issues is like trying to run a 3-legged race.

Why Role Clarity Matters on Engineering Teams

Workplace teams are like sports teams.

Just as every athlete on a team has a specific role to fill, every team member in the workplace plays a specific role as well.

When every person understands and fulfills their role, the entire team wins.

But when there is a lack of role clarity, people step on each other’s toes, balls get dropped, and performance suffers.

A major source of engineering problems is a lack of role clarity among team members.

Lebron James understands the importance of role clarity when he tells his teammates to be a “star in their role.”

And furthermore I’ve discovered that this lack of role clarity exists at all levels of engineering orgs. This includes:

how engineers work cross-functionally
how CTO’s work with their VP’s
even with expectations on the CTO role itself

Engineering leaders must pay more attention to whether their team members are clear on their expectations and roles.

Providing role clarity will eliminate many of the mishaps that I’ve seen affect engineering orgs in my consulting practice.

1. Role Clarity on Cross-Functional Projects

Clear roles are particularly important for engineers working on cross-functional projects.

I’ve noticed that projects within a single engineering team tend to go smoothly because there is a clear line of command.

The engineering manager leads. The engineers execute.

The division of responsibilities between a manager and the engineers is clear.

But when it comes to cross-functional projects, the members of this project often aren’t in the same organization and they don’t report to each other.

This lack of ownership often leads to major problems down the line.

The Product Manager leads the cross-functional project, but the engineers technically report to someone else, creating a potential communication gap.

How Netflix Engineers Work Cross-Functionally

At Netflix, I saw this issue first-hand. Netflix often works cross-functionally on A/B tests. The working model before would involve a product manager leading the initiative, and managers “loaning” engineers to these projects.

However this model often lead to bugs and delayed deadlines. It turned out that while each individual engineer worked on their piece of the project, there was no clear owner for the end-to-end engineering design.

Note how there is a manager for both individual engineers, but no manager owning the entire engineering stack across the cross-functional project.

So while the engineers made sure their individual piece was working, it was when all of the engineers’ work came together that bugs would surface.

The individual engineers’ pieces would work, but bugs would appear upon integration.

So the solution to fix this was to explicitly assign engineering “lead” roles for all cross-functional projects. In particularly, we created two new roles in cross-functional projects:

Engineering Lead — the individual responsible for the technical architecture of a project.
QA Lead — the individual responsible for ensuring adequate test coverage.
You can see the new working model in the diagram below.

Note how now there is an explicit owner of the entire engineering aspect of this project now so that end-to-end gaps wouldn’t be missed.

Once we implemented explicit roles in cross-functional projects, the projects went more smoothly with fewer hiccups along the way.

So while many bugs look like pure engineering issues, the lack of role clarity around who owned the end-to-end technical architecture was the real reason for all the engineering issues.

Once those roles were defined, the engineering issues disappeared as well.

2. Lack of Ownership over Engineering Teams

Second, I’ve seen the issue of role clarity come up among upper-management in startups as well.

For example, I consulted with the CTO of a Series C startup on a migration that was taking too long. At first, I thought that this was due to poor project management.

But I soon discovered that the real issue with their migration wasn’t a technical issue, but due to their poor org structure instead.

Take a look at their org chart here.

Can you see what’s wrong with the org structure here?

There are several issues with this org structure. Among them include:

Product Managers in the wrong org — The product managers reported to the CTO when they should’ve been in a separate product org instead
Too many direct reports — The company had 15 engineering teams, and a 70-person engineering org. Split between the CTO and the VP, they had on average 7.5 teams reporting to each, which means 35 direct reports for both the VP and CTO!
No clarity of roles — There was no clear division of responsibility between the CTO and the VP over who owned which teams.

In fact, the CTO told me that the VP was more of a “right-hand man” and they practiced “tag-team management.”

So if there was an issue with a team one week, and the VP was busy, the CTO would manage the team. If the CTO was busy, then the VP would step in. So there was no clear ownership over who owned which teams.

The CTO and VP “tag-teamed” on issues, but there was no clear division of responsibility over their separate teams.

So what started as a migration issue turned into an organizational one instead. I discussed with the CTO what organizational structure made sense, and we agreed that:

He needed more VP’s under him to cut down on the number of direct reports.
He has to create a new product org for the PM’s and move them under a new Chief Product Officer.
He had to clearly define roles among his VP’s, and call out who managed which of the 15 teams. The tag-teaming days were over.

The proposed new org structure

A few months after, the CTO told me that their re-org was a success.

You can see the CTO’s message below:

3. Why Engineers Struggle as First-Time CTO’s

Lastly, I’ve discovered that CTO’s are often unclear on their role as well.

Many first-time CTO’s were engineers in a previous role. And they report to the CEO the same way an engineer reports to an engineering manager.

But this is the wrong way to look at the CTO role.

The CTO should view themselves not as a subordinate, but as equals to the CEO. They can’t just wait on the CEO to give them orders, because the CEO could be waiting on the CTO to tell them what to do instead!

CTO’s have more power than they realize, because without their buy-in the product can’t move forward.

Not understanding the level of autonomy expected in a CTO role can lead to disastrous results for a startup.

This quote applies particularly to CTO’s.

Why CTO’s Shouldn’t Always Say Yes to the CEO

In another startup I consulted with, the CTO told me that they felt “overwhelmed” from trying to balance both the CEO’s priorities with their own.

They told me that the CEO had two main priorities:

Changing their business model to a flat subscription fee
Expanding to new markets

The CTO had one main priority:

Finishing a tech debt cleanup.

The tech debt cleanup had already lasted for over a year, and balancing the cleanup with the need to innovate overwhelmed the CTO.

How would you manage this situation if you were in their shoes?

I discovered that there was actually a communication issue between the CEO and the CTO.

First, the CEO didn’t understand the challenge of implementing a new business model.

They didn’t know that the codebase had assumptions about how they charged their customers previously, making this change difficult.

Second, the CTO didn’t understand that they had the power to speak up and mention these challenges to the CEO.

So what happened was the CEO issued their priorities, and the CTO tried to execute on it, leading to their engineering teams getting overwhelmed.

But there was actually a solution here.

Had the CTO spoken up and mentioned the difficulty of implementing the business model change, they could’ve worked with the CEO to suggest that they prioritize their 2nd goal — moving to new markets instead.

This involves no work for engineering, because every new customer in the market is just another entry in the database. So while the rest of the company tries to expand to new markets, this would buy the CTO some time to finish their cleanup.

Adding customers from a new market is easy, because it’s just another entry in the database.

And by the time this expansion finishes, they would have already redesigned the code base to make the business model changes easier.

So the learning here was that this new CTO was acting more as an “executor” and doing what they were told. But the CTO didn’t realize that they are no longer just an engineer, but they had the power to change business priorities as well.

Had they communicated to the CEO the technical challenges of these business priorities, they could have worked together to switch the order of priorities to buy the engineering org more time, while still achieving both business objectives.

Final Thoughts
Engineering leaders should pay close attention to whether their team members know their roles and responsibilities.

Doing so will help you avoid these painful mistakes that plague startups.

💡 If You Liked This Article...

I publish a new article every Tuesday with actionable ideas on entrepreneurship, engineering, and life.

BONUS Get a free e-book w/ my writing coach's contacts when you subscribe below. (Check the welcome email).

Join 3,175 subscribers on my newsletter here.

Build Your Brand, Not Your Business

Michael Lin — Wed, 08 Mar 2023 07:59:49 +0000

I wanted to be a billionaire.

So I did what everyone in Silicon Valley does — start a startup. Then this happened:

I quit my job
I spent 6 months building a product
I launched it
I got 0 customers

Suddenly I was running out of cash, and I had no clue what went wrong.

Looking back, I know my mistake. I focused too much on building a product, and not enough time on the distribution channel.

The channel is how you will drive traffic to your business — e.g. your YouTube channel, Instagram page, or blog.

I now believe that people who want to work for themselves should NOT start by building a product. Start by building a distribution channel instead.

Why Channels Matter More Than Products

The number one reason why I believe in a channel-first strategy rather than a product-first one is because:

You’re more likely to fail from the lack of a distribution channel than from an inability to build a product.

Here are 3 reasons why the channel matters more than the product.

A Better Product Alone Won’t Win

Product is no longer a differentiator. Any Google engineer can copy your website, but they can’t copy your channel. So a distribution channel is a business moat in itself.

You can copy a UI, but you can’t copy a brand.

Reusing Channels for Other Products

Most products fail. But you can always reuse a channel to sell something else later.

This is what Beyoncé does. If a product of hers flops, she can always change the link in her bio to promote another product.

In fact, she recently did this when she changed her bio to promote her clothing line instead of her website.

Beyoncé reuses her channel to sell different products.

Channels Take Longer to Build Than Products

It takes time to build a channel — you don’t get to rank one on Google overnight. So you need to start building this ASAP.

For example, if you want to build a software business and your growth will mostly come from content marketing, don’t start by building the software. Start by pumping out articles on your blog.

Canva uses their blog as a lead magnet for their card-making tools.

Your readers will eventually see the product you sell. You can convert those repeat readers to paid customers later.

The Best Distribution Channel is Your Brand

It’s clear that the channel matters more than the product. So if you want to quit your job and start a startup, you should start by building your brand first. This is because:

Your brand is a distribution channel in itself.

If you have tens of thousands of followers, it’s guaranteed that you can monetize later. Focusing on your brand has several other benefits:

Business Moat — No one is a better version of you than you. So no one will ever be able to copy your business.
Faster launch time — there’s no code to write if you’re building a brand because the product already exists — it’s you!
Expertise — You’re already an expert in your domain, so you can produce content around your advice immediately.

How to Build Your Brand

Here are 3 questions to consider when building your brand:

What do people ask you for advice on?
What can you talk endlessly about?
What are you best at: pictures, videos, writing, or talking?

The advice that people ask you for is the world telling you what content to make.

How you got your job, is graduate school worth it, and advice for your younger self — these are all questions people ask. Each of these can be a separate brand.

What you can talk about endlessly means you’ll never run out of content on this subject.

And what you are good at is your future channel.

Combine these three things, and you have a brand. Some examples:

If you’re an engineer at a top tech company, you love giving career advice, and you love videos, you can make a YouTube channel helping people break into tech.

Rahul Pandey, Tech Lead, and Joma Tech all have YouTube Tech brands.

Let’s say you are passionate about engineering, but you prefer talking. Then you can create the same content, but with a podcast. One Netflix manager did this with his “Front End Happy Hour Podcast.”

More engineering advice, but with a different channel using podcasts.

Or if you prefer writing, then you can publish on Medium or Substack like me.

In the above examples, the same product combined with three different channels creates three different businesses.

Same Product + Different Channel = Different Business

You can mix and match any channel with any product, and you’ve got a new business. The opportunities for your brand are endless.

How to Monetize Later

As you start off, your number 1 goal is to get more followers. To do this, you should focus solely on providing value for free to your audience. It’s not about you — it’s about teaching others.

Don’t monetize until you reach 10–20k followers on any one platform. This is because when you monetize, only a small fraction of your followers might convert.

Making a few hundred dollars now is nothing compared to the thousands you will make when your audience is bigger.

Substack for example only has a 5–10% paid conversion for newsletters. But if you have 10k followers, and 10% convert to paid for $10/each per month, you have a very livable 10k/month salary, or 120k/year annualized. Not bad for your first business!

Two examples of how people monetize channels later include:

Making money from the content directly via ads, paywalls, or sponsorships. Twitch, OnlyFans and (paid) Substack newsletters are three examples of channels where you can directly monetize your content.
Keeping the channel free, and selling other paid products instead. This includes selling merchandise, consulting, courses, or your future startup’s product. Dave Ramsey is an expert at this.

Over time, you can combine these ideas to layer your business with multiple streams of income.

Chess Grandmaster Eric Hansen did this with his Twitch stream. Look how he used his expertise (chess) and combined it with a channel (Twitch) to create a brand (ChessBrah).

Then he layered it with several income streams by selling merchandise, Twitch subscriptions, and sponsorships.

How to Start Building Your Brand Today

If you want to start a business, you need to start building a channel now.

My homework for you is to start by posting one piece of content on a platform of your choice by the end of next week.

Your first piece of content doesn’t have to be perfect. Your first YouTube video could just be you talking into your phone for a minute on “3 Quick Tips for How to Do __.” Another idea is “What I Wish I Knew Before I __.”

Launch quickly. Don’t spend more than a day making your first piece of content. Your first try won’t be your best, but that’s OK.

Your goal is to do whatever it takes to get to 1,000 organic followers on any platform of your choice.

And if you get to 10k followers, it’s less risky to go all-in on your business since you have a channel to work with already.

Go out, let the world hear your message, and get creating! Feel free to DM me your first piece of content - I’d love to see it! ✨

💡 If You Liked This Article...

I publish a new article every Tuesday with actionable ideas on entrepreneurship, engineering, and life.

BONUS: Get a free e-book w/ my writing coach's contacts when you subscribe below. (Check the welcome email).

Join 3,071 subscribers on my newsletter here.

Why You’re Not Getting Promoted (as an Engineer)

Michael Lin — Tue, 28 Feb 2023 21:15:29 +0000

Engineers often try to get promoted by focusing on their technical skills. Like writing more unit tests. Or learning a new programming language.

After all, the best engineers get promoted. Right?

Being good at your job is different than advancing in your career. The people who get stuck only do what they’re told — and then wonder why they’re not getting anywhere.

Me waiting to get promoted

The people who get promoted manage their careers like it’s a separate job. They don’t wait for opportunities to happen. They make them happen.

In this article, I discuss the 3 most common career mistakes that cause engineers to get passed up for promotion.

None of them involve getting better at your current job.

A Lesson from American Politics

When a new US president gets elected, their first task is to hire the right people for their team. They have to pick their advisors and choose who to nominate to their cabinet.

It’s during these political transitions that careers get made. When Joe Biden won the 2020 election, many politicians made huge strides in their political careers when he nominated them to his administration.

Kamala Harris (VP) and Pete Buttigieg (Transportation Secretary) both got promoted after Biden was elected.

These politicians got promoted when a political re-org happened. You have to pay attention when a corporate re-org happens. That’s when you have the highest chance of getting promoted.

Promotions Happen During Corporate Re-Orgs

Just like in political transitions, departments get axed and new teams get created during corporate re-orgs.

This paves the way for roles to open up — and that’s your chance to move up.

You have to imagine ways that you can fit in this new org that align with your career goals. Then propose it.

The key is to find win-win situations where you:

advance the goals of leadership
do it in a way that aligns with your career goals

Don’t make the mistake I made, where I ignored all the re-org emails that upper-management sent at Netflix. “If it doesn’t help me work faster, I don’t care,” I thought.

Pay close attention to shifts in the team structure, because that could be your chance to get your dream role.

Case Study: Spot the Promotion Opportunity

Imagine a team where a director splits their team into 3 squads under them.

2 squads have a manager.

1 squad has engineers who report straight to the director.

Can you spot the promotion opportunity?

Right now the director has too much on their plate.

They have 2 managers + 3 engineers to manage = 5 people to manage. They have to play double duty — first as an engineering manager for the 3 engineers, and second as a director for the two other managers.

If you’re in this org, this is the perfect time to become a manager. Ask the director if you could manage this 3rd squad. If you became a manager, everyone benefits:

the director cuts their reports from 5 to 3
the manager-less team has more direction
you advance in your career

You’re the manager now.

More opportunities to get a promotion can open up if there is a further re-org in this team. If:

one of the squads splits further
a new squad gets created
they will need new managers to manage those squads.

And since there are 15 engineers now, you could make a case for a TPM/PM to manage all the infrastructure on this team as well.

More roles created as the team expands.

I’ve noticed while working at Netflix that many of my coworkers’ careers were made during re-orgs. My previous boss got promoted when the team split into 4. He raised his hand to manage one of the squads and got the job.

Another re-org happened at Netflix where they moved the VP of Product into another org. He laid off the old product team and new engineering teams emerged.

A coworker of mine saw this opportunity to ask if she could manage one of the new engineering teams. Now she has 10 engineers reporting to her.

Re-orgs are opportunities. Pay close attention to org structure, and try to find ways that you could fit in a higher role when a new leader comes in.

Collecting the Wrong Experience

Another career mistake involves trying to collect more experience. “Only after I get 1 more certificate,” they say. “Then I’ll be ready to get promoted!”

The problem with collecting more experience is that the skills required to get promoted to the next job are entirely different than the skills to be a superstar at your current job.

You need to learn the skills to operate at the next level, not to operate better at your current one.

So most people are learning the wrong set of skills that won’t help them get promoted.

Some people collect experience like baseball cards

Case Study: Entry-Level vs Principal Engineers
I talked to a friend recently who was starting their career in big tech. They wanted to move up the engineering ladder and asked what it would take to become a principal engineer.

They stayed late at work often and worked weekends because they wanted to get promoted faster. By their logic, working more meant they could crank out more features and advance in their careers faster.

I guarantee this will not get them promoted.

Taking care of your health is taking care of your career.

What my friend doesn’t understand is that principal engineers aren’t SDE 1’s on steroids.

It’s not about cranking more features out — “the intern cranks out one feature per day, but the principal engineer cranks out a dozen.” The principal engineer operates on an entirely different level.

SDE 1’s and interns are usually given small, independent tasks. Building features, writing test — things that they can do in isolation from the rest of the team.

As you move up the ladder, you’re tasked less with completing individual tasks, but helping other engineers move faster. A principal engineer helps the entire company move faster.

Migrating to AWS was one of the top priorities for engineering leadership at Netflix in the early 2010’s.

Tasks that a principal engineer might work on involve:

standardizing the way code is written in the company
centralizing duplicate work between teams
migrating the company to the cloud

These tasks affect every engineer’s workflow — principal engineering level work. I have a saying for senior level engineers:

If your work doesn’t help multiple engineers move faster at once, you’re not operating at a senior engineering level.

So my advice to the entry-level engineer who wants to develop the skills to operate at the next level is to think less about completing your individual work faster. Instead, think more about how you can help your team move faster.

This includes:

making sure your team is on the paved path at your company
setting up alerting properly so issues are detected quickly
setting up continuous deployment so features get pushed out faster

This work will reduce the operational load on your team. Your boss will notice and your teammates will thank you for it.

Expecting the Manager to Drive Your Promotion

Lastly, waiting for your manager to drive your promotion is the single biggest career mistake of all. You could waste years of your life waiting for a promotion that never comes if you expect others to drive it for you.

Your Manager’s Viewpoint

The issue is that managers have too much on their plate already.

If you mapped out a pie chart of their attention, 99% of their time is spent thinking about their own job security, their own deadlines, and their own promotion.

Your promotion at most will only take up 1% of their time.

That 1% is everything to you though.

It’s not your manager’s fault it’s this way — it’s an issue of incentives.

If you can’t get fired for it, it’s not a priority. A manager will never get fired because you didn’t get promoted. So there is no incentive for a manager to prioritize your career growth.

The career chicken and egg problem.

The lesson here is that you need to take responsibility for your own promotion. You have to do your own research and figure out:

how the promotion process works at your company
who will be at the promotion decision meeting
what work can be used to build a promotion story

Not all work is created equally. You have to make sure you’re doing the work that will help you get promoted. This means revenue-generating features and work that moves needles.

No one ever got promoted by being a scrum master. No one ever got promoted for writing a few extra unit tests. It’s up to you to find the work that will get you promoted.

Conclusion

Great work alone will not get you promoted. It’s the career building work you do that will.

Engineers tend to be very good technically, but lack the political savviness to notice openings before they arise. They focus too much on the wrong kind of technical expertise, and don’t take responsibility for their own career destiny.

No one cares about your career success as much as you will. Don’t wait for things to happen. Take responsibility for your own career success, and watch your career flourish.

💡 If You Liked This Article...

I publish a new article every Tuesday with actionable ideas on entrepreneurship, engineering, and life.

Join 3,001 subscribers on my newsletter here.

Mo’ Code, Mo’ Problems - Engineering Advice for Non-Technical Founders

Michael Lin — Tue, 21 Feb 2023 08:13:37 +0000

I often hear the same startup stories play out among founders. It goes like this:

They quit their jobs
They spend 6 months building a product
They launch
They get 0 customers

And then they run out of savings and wonder what went wrong.

The issue is they spent too much time on engineering, trying to recreate the sleek apps on their phone for their startup.

But the software we use every day was the result of years of iterations and thousands of engineers working together. In the early days, many popular apps weren’t as polished as they are now.

Evolution of Stripe’s homepage

Startup founders can’t copy what Big Tech companies do because they have fewer resources. Instead startup founders must prioritize speed by cutting features, letting go of their perfectionist tendencies, and timeboxing their MVP to under a month.

In this article, I share 3 engineering “tricks” to launch an MVP faster. These tips include:

Aiming for no-code solutions first
Replacing engineering with operations instead
Collecting emails before building the full product out

These 3 techniques will save you months of engineering work so you can focus on what matters: sales and building distribution channels.

Mo’ Code, Mo’ Problems - Why Founders Should Investigate No-Code Solutions More

One mistake founders make when building a startup is rushing to hire engineers first. However, founders can build most MVP’s by themselves using no-code solutions where you drag-and-drop features around. They don't require any engineering expertise to use at all.

For example, if you want to build a website out, there are so many no-code website builders, you might as well use those instead of trying to build it from scratch.

Similarly for marketplace startups, there are already so many marketplace templates out there, you might as well use those instead.

As I often tell clients, “More code, more problems.” Coding is difficult, time-consuming, and expensive. The more you can get away with using no-code solutions, the better. Here are some of my favorite no-code tools that I’ve collected over the years:

Website-Builders: Umso.com (my favorite), Ghost, Notion + Super.so, Kajabi (what Justin Welsh uses), Webflow (there’s a big learning curve, but others like it)

Testimonials: Testimonial.to

Design Templates: Canva

In-take forms: Typeform

Scheduling: Calendly, Acuity Scheduling

Email Collection: Umso, Carrd, ConvertKit, Notion + Super.so + Chilipepper

No-Code Mobile App Builders: Flutterflow, Wappler.io, Adalo, Appgyver

I built this consulting landing page in 2 days using Umso.com. Link here

But What If the Perfect Solution Doesn’t Exist?

Oftentimes a founder will tell me that an off-the-shelf solution doesn’t exist because it’s missing certain features. But you can still use no-code tools for parts of your product, and only write code for the features that aren’t included.

For example, entrepreneur Rahul Pandey and his CTO Alex Chiou are the founders of a career mentorship app called Taro. Even though they are engineers by training, they still use off-the-shelf solutions wherever they can.

While their app allowed users to ask questions to Rahul, he needed a way to send community-wide announcements. Instead of building this out, they put all their members in a separate Slack community and use the @all command in Slack to ping everyone for updates.

The founders of Taro use a combination of Slack + their own app so they don’t have to rebuild notifications features

These are two ex-Meta engineers who are capable of building these features, yet they still look for opportunities to cut down the work by combining existing solutions. By not having to re-build notifications features, they’ve saved themselves months of engineering time and can focus on their core product instead.

So if a team of ex-FANG engineers take shortcuts by using no-code solutions, then it’s a lesson for all founders to not reinvent the wheel wherever possible.

💡 Pro-tip: Before building anything, always Google around for existing libraries, templates, and tools that can do the job for you.

Replacing Engineering with Operations

Travis Kalanick, ex-Uber CEO, once said that “Product is slow, but ops is fast.” In the time it takes for engineering to solve a problem, the founders could have solved it faster manually. So founders should utilize engineering only when they’re overwhelmed with operations.

The most famous example of this is with Patrick Collison of Stripe. When he founded Stripe, he never built out the “onboarding” flows for customers. Instead, he installed Stripe on their computers manually, thus saving their engineers from a lot of UI work.

“Do things that don’t scale” - Paul Graham, founder of YCombinator

Doing things manually is a way of validating the necessity of a feature. If you wait until you get enough customer support emails to build a feature, then you know that the engineering work is worth doing because it will reduce operations significantly.

Furthermore, many of these features that founders ask engineers to solve for are edge cases. By definition, they don’t happen that often, so it’s actually less work to handle it manually than for engineering to guard against all of them.

And by relying more on operations to cover customer issues, you might discover that you never actually needed the feature you wanted built out at all.

I discovered this myself when I was building out the log-in page for RecordJoy.com.

Example: RecordJoy’s Missing “Forget Password” Feature

RecordJoy.com is a screen-recording website that I bought with a business partner on Microacquire in 2021.

Screenshot of RecordJoy.com when we bought it

When we bought RecordJoy, our first priority was to monetize it by adding in different payment plans. But in order to do this, we had to build a way for users to create accounts or else we couldn’t charge them.

So in the process of building out these registration pages, we realized there were actually a lot of small features that we had to build to get it working. One of them was a “Password Reset” flow.

Normally we take features like this for granted. But because we were so limited in time as a two-person company, we even cut the “Password Reset” flow out, as you can see in the image below. Instead, customers had to email us if they wanted to reset their password.

Notice how there is no “Password Reset” on this login page

It turned out that customers barely noticed this feature was missing. In our 1-year owning RecordJoy, we only received 2 emails ever from customers asking us how to reset their passwords. And for those two customers, we manually triggered a “Password Reset” email through Google Firebase, which was our backend database.

We had to manually trigger password reset emails when customers forgot their password.

Handling these two emails cost us 10 minutes, whereas building the screens and features out would’ve taken a day or two. This might not seem like a lot, but small tasks add up. And when you consider the opportunity cost of building a password-reset flow vs. spending that time improving core features, these small tasks become quite expensive over time.

So the lesson here for you as a founder to reduce engineering scope is to:

Consider whether or not you can manually handle engineering tasks. This includes even obvious things, like password reset or onboarding flows.
Consider whether any features you’re asking are edge-cases or a critical part of the user journey. If they are edge-cases, it might be better to cut those features out.

Collect Emails Before Building the Product

My last piece of advice to cut down on engineering time is to make your MVP an email collection page and launch that first.

The reason for starting with an email-collection list is three-fold:

First, it’s faster to build an email collection page than it is to build a full-fledged product. You can launch an email collection page in just a day or two. And it gets you focused on generating traffic for your website sooner, which you’ll have to do even if you built your product out.

My recommendations for building email collection pages.

Second, there’s diminishing returns on your engineering work the deeper you go into your product. Most products are like a funnel. The more a user has to click, the more people who will drop-off. So building a one-page email collection page focuses your work on the homepage which has the most traffic anyways.

Lastly, this email list might form the foundation of your future product as well, as many successful businesses started off as just a newsletter before growing into a full-fledged product over time.

Example: AppSumo and Noah Kagan

AppSumo is a marketplace to buy cheap software products through life-time deals. It’s a 9-figure business at this point, and one of the most astounding things about this marketplace was that Noah Kagan didn’t commit to the current version of the website till 2019. It started off as a newsletter first.

The very first version of AppSumo.

In fact, you can see the first iteration of AppSumo above in 2010 when it was just an email collection page. What’s crazy is that by collecting email addresses for 3 years, he built this list to over 150,000 people, and it is the main driver of traffic to his website with almost 50% of revenue coming from his email list, and 6.7% of all organic traffic!

His email list still generates 50% of all revenue for the site. (source)

The brilliance of this is that the newsletter creates value faster for his customers than a website. It may take time to generate traffic for a website, but with a newsletter, he could email them with software deals the very next week.

Second, Noah combined this email list tactic with the previous tactic about leaning into an “ops-heavy” approach to replace engineering. Initially if software companies wanted to get listed, he’d have to onboard them manually. When his product became popular, he automated this process through his website.

AppSumo CEO Noah Kagan

Compare this with how most people would’ve built the product. Many founders would start off by building a marketplace and then running into a “cold-start” problem where there aren’t enough buyers or sellers on either side to make the marketplace valuable. By building out the newsletter, he validated there was enough demand to justify the engineering work to build out the website.

His company is easily worth more than $100M now, and it all started from an email list. The email-list could be the humble start of your big business idea too.

Final Thoughts

Many founders have misconceptions around engineering, thinking that engineering is about writing code.

Engineering is not about writing code. Engineering is about solving business problems in the simplest way possible. And the best way to solve engineering problems is if you don’t have to write any code at all. By

utilizing existing solutions
replacing engineering with operations
using email newsletters as an MVP

you can avoid all the engineering headaches and launch your billion dollar idea faster. I’m rooting for you!

💡 If You Liked This Article...

I publish a new article every Tuesday with actionable ideas on entrepreneurship, engineering, and life.

Join 2,912 subscribers on my newsletter here.

The Best Engineers Think Like Investors, Not Builders

Michael Lin — Tue, 14 Feb 2023 21:18:02 +0000

I lived in the library during college.

“The more textbook theory I studied, the better an engineer I would become,” I thought.

Yet when I started working, I noticed that the best engineers in the industry didn’t necessarily know more theory than new grads. They just brought a different mindset, the investor’s mindset, to work.

It was this mindset that helped them ask smarter questions, prioritize better, and set themselves apart. Like an investor they:

focused on work that paid off sooner than later
calculated if the work was worth their time or not before diving into it
weighed the opportunity costs of their work

In this article, I discuss 3 common problems every engineer will face in their career, and how the investor’s mindset will help you make the right technical decision every time.

1. When will your work payoff?

In investing, there’s a concept called the “time value of money.” This refers to the fact that money now is worth more than money later. You’d rather have an investment pay off one year from now rather than five years from now.

Engineering work has “time value” as well. Engineering projects that payoff now are worth more than engineering projects that payoff later.

We saw this recently with Facebook stock. It dipped by 50% from its all-time highs when executives revealed their Metaverse investments might not pay off for as long as “15 years later.”

Meta invested over $10B into it already too.

Just as how the long payoff period of the metaverse spooked investors, engineers should avoid work that pays off too far into the future. This mistake happens particularly when it comes to engineering migrations.

Why Migrations Are Costlier Than You Think

From an investment standpoint, engineering migrations are a guaranteed upfront cost, for uncertain rewards in the future. And these rewards don’t pay off for longer than most people realize.

Consider the timeline of a two-year migration below.

The cost is guaranteed, but the rewards are not.

First, the two years we spend migrating now are worth more than the two years we benefit from the migration later. So the break-even point for a migration is longer than four years later.

Second, the rewards of any migration must exceed the cost of the work. It doesn’t make sense to spend two years to save two years. You might as well not do the migration at all then.

You should discount the rewards in years 3 and 4 because it is in the future.

I have a rule that any engineering work must have a minimum of 2x of the rewards to justify the cost. If I spend a month migrating, it has to save me two months of time to payoff.

With this rule, if you spend two years on an engineering migration, you must enjoy the benefits for double the migration time to break even.

Thus, the break-even point for a 2-year migration is actually four years later — or six years from the beginning of the migration.

Are you willing to wait 6 years to see the payoff of a 2-year migration?

The longer a migration takes, the greater the risk that it may never pay off. Other risks include:

Changing business priorities— The company might deprecate the team’s service, rendering the migration obsolete.
Exit risks — If a startup gets acquired, these migrations won’t affect the valuation of the startup, and thus delivers zero-business value.
Execution Risks — A single execution mistake (eg a data leak) could nullify all rewards of the migration.

The lesson is that engineering should bias toward projects that payoff sooner than later, or risk never seeing the rewards at all.

2. Is this project worth your time?

Warren Buffett once said that a company’s returns are “far more a function of what business boat you get into than it is of how effectively you row.”

The same principle applies to engineering. Working on the right project (getting in the right boat) is more important than the details of the code you write (how hard you row).

This is particularly important when it comes to buy vs. build decisions in engineering.

Although I admit I get excited by greenfield projects, it’s important to not dive right in and default to “build.” Like an investor doing due diligence, engineering must calculate the costs and benefits before deciding to go either way.

Some questions I ask to decide this include:

If we purchased a solution, how easy is it to integrate and maintain?
Is this feature a core competency of the company?
How expensive is it to build this at all?

With this last question — it’s important to estimate the costs of any “build” proposal to make sure the expected rewards are proportional to the engineering effort. One way to establish a baseline for this is to:

Estimate how many hours a project will take.
Multiply this by your hourly engineering rate.
Use this as a guideline for the cost of a project.

The deeper into the blue or red zone a project is, the more compelling the decision to build or buy respectively.

While cost is not the only consideration, sometimes doing this exercise alone can help engineering decide which path to take.

Example: Buy vs. Build with RecordJoy.com

I came across this decision myself when my business partner and I had the choice to buy a screen-recording website called RecordJoy.com for $12,000 or build it from scratch.

Screenshot of RecordJoy.com when we bought it

We estimated that it would take us two months to build the website ourselves, or 320 engineering hours. Assuming our time was worth $100/hour, it would cost $32k to build ourselves.

The choice to buy RecordJoy then boiled down to whether we’d rather spend $12k to buy RecordJoy now, or $32k building it ourselves. It was cheaper to buy the website than to build it, so we bought the website.

Building RecordJoy from scratch is much more expensive than buying it.

Looking back, this decision was the most important engineering decision that we made while working on RecordJoy. It allowed us to focus our energy on building paid features rather than the product itself.

It also reduced the engineering risk. By buying RecordJoy, we had a guaranteed product we could use immediately vs. a product that we have no guarantees of finishing two months from now.

As for RecordJoy, we grew this company from no revenue to $700 a month in recurring revenue with a few months of work. We sold the company on Microacquire.com in April 2022.

Microacquire sent me a gift congratulating me after I sold my company on their website.

3. Will this project move the company needle the most?

In investing, there’s another concept called “opportunity cost.” Opportunity cost is what you give up when you make a choice.

For example, if I wanted dessert and had the choice between cake and ice cream, the cost of choosing cake isn’t just what you paid. The cost of cake is the foregone opportunity of enjoying the ice cream as well. So with every choice, one door opens and another closes.

Every technical debt cleanup has an opportunity cost too. Cleaning up one system means we can’t cleanup another. So it’s critical to make sure that the cleanup we work on drives the most impact.

I compare managing technical debt to that of cleaning a house. Just as how your house will never be fully clean, it’s impossible to fully eliminate technical debt. However, some rooms in your house are more important to clean than others.

Why clean the garden if the inside of the house isn’t clean?

Why clean the guest bedroom if the main bedroom isn’t clean?

A clean guest bedroom

Similarly, some technical debt helps the team move faster than others.

The alerting system for a billing service is more impactful than the alerting for an internal tool. The testing infrastructure for the homepage is more important than for any other page.

The lesson for engineers is to always consider the opportunity costs of your work.

Don’t clean your guest bedroom until your main bedroom is clean first!

Example: Doma’s Migration from Heroku to Azure

Doma, a real-estate software company, had a technical debt cleanup recently where their focus on cleaning the main bedroom paid off.

To prepare for their IPO in 2021, they had to migrate their cloud infrastructure from Heroku to Microsoft Azure. They gave themselves half a year to plan and execute on this migration.

However, towards the end, Doma had an issue with their contract with Heroku. Heroku wouldn’t allow them to renew their contract at a lower volume, and only presented Doma with the option of another longer-term contract. So if Doma didn’t complete the migration to Azure in time, they could have their cloud infrastructure cut off.

They gave themselves 41 days to execute the migration, but this issue cut their timeline down by a month, down to 11 days.

A slide from Doma’s presentation on their migration to Azure.

Considering their contract with Heroku had an imminent deadline, not completing this migration could cost the company millions of dollars. Any other engineering work paled in comparison to the impact of not completing this migration in time.

In response, Doma issued an all-hands on deck for their engineering teams. Every team had to prioritize migrating off of Heroku because the opportunity cost of this migration was too high. Doing any other work would be the equivalent of cleaning the guest bedroom, when the main bedroom, the Heroku migration, was on fire.

Doma’s focus paid off. They migrated all of their remaining apps to Azure in 8 days—with 3 days to spare for testing. Their investor mindset allowed them to weigh the opportunity cost of the migration vs. other work and avert a crisis. They IPO’d soon after.

Final Thoughts

In engineering, developing the investor mindset will get you further than knowing the latest tech fad.

If you spend more time considering 1) the financial costs 2) the payoff periods and 3) the opportunity costs of your work, you will make better technical decisions and save time.

💡 If You Liked This Article...

I publish a new article every Tuesday with actionable ideas on entrepreneurship, engineering, and life.

Join 2,851 subscribers on my newsletter here.

How to Quit Your Tech Job (the right way)

Michael Lin — Wed, 08 Feb 2023 02:31:42 +0000

I gave a virtual talk yesterday. It was for a career mentorship app called Taro.

Rahul Pandey, one of Taro’s co-founders, hosted the event. He often invites engineering leaders at well-known tech companies to give guest talks for Taro.

So when a member asked Rahul if I could come speak at one of Taro’s monthly live sessions, I jumped at the chance.

Rahul Pandey, co-founder of Taro.

To prepare for this talk, I browsed around Taro looking for questions and I noticed one theme. Many Taro members were thinking about quitting their jobs.

So I centered the talk around three common questions I saw about quitting. They include:

Whether or not you should leave your job
How to prepare to leave your job
Whether or not to ask for a severance package before leaving

Let’s address each of these in turn.

Should You Quit Your Job?

Before you quit, reflect on why you want to leave in the first place. Every “dream job” has tedious parts. Make sure your decision to leave is not an emotional one, and you’re leaving because of a fundamental issue you can not resolve at your current company.

I left Netflix because I couldn’t switch into a product manager role. There was no formal process supporting this transition, which is a structural issue I could not resolve at Netflix.

However, I often hear reasons for quitting that aren’t fundamental issues with the job. For example, if you don’t like your manager, you can resolve this by switching teams and staying at your current company.

Understanding why you want to leave will shed more clarity on whether it’s the right move or not.

Also, quitting is a financial decision. If you have to cut vacations, move away from friends and family, and say no to more social events because you can’t afford it, then those negatives may outweigh the negatives of your current job, and you should stay.

If you have to sacrifice too many vacations, then you might not yet be ready financially to leave.

You should also consider the impact leaving will have on others as well.

Someone with multiple kids reached out to me a few months ago with questions about leaving their job. However, I found out they were the sole bread-winner in the family, and their spouse was a stay-at-home parent. In this case, leaving jeopardizes their role as a “bread-winner”, so they have more obligations to consider.

If you’re torn about leaving or staying, the following questions can bring clarity:

Why do you want to leave your job? Why can’t you fix this in your current company?
Do you have any obligations to others? Will quitting jeopardize your ability to fulfill those obligations?
What difference will an extra year’s income make to your life quality?

On this last point, an extra year’s income has less impact the further you are in your career.

When you start off, the difference between no savings and your first 10k in savings is huge. But if you had 100 million in savings, there’s nothing you can do with 101 million that you can’t do with 100 million.

So if an extra year’s income from staying won’t make much of a difference, then that’s more reason to leave.

How to Prepare to Quit Your Job

So you want to leave your job and you know you will be OK financially after quitting. What should you do now to prepare to quit?

I recommend collecting more assets on the side. This includes things like:

building an audience on social media
creating digital products (like courses, pdfs, checklists, templates to sell)
expanding your network
producing a content library

When you leave a job as a W-2 employee, the only thing you have to show from the work is your savings. The reputation you build over the years fades as you lose contact with former colleagues. You don’t own your work either so you don’t have any IP.

Try to fill this gap while you still have income. One of my favorite examples of someone who did this successfully before quitting is…Rahul Pandey of Taro himself!

Example: Rahul Pandey and Taro

Before starting Taro, Rahul Pandey was a Stanford CS alumni working at Pinterest and Meta. He quit corporate in January 2022 and in April 2022, he launched a career mentorship app called Taro.

Rahul Pandey’s launch announcement.

Almost immediately Taro caught on fire. Taro has 4.9 stars on the App Store, and 300+ glowing reviews.

And just 3 months later in July of 2022, he ended up getting into YCombinator. So how did he succeed so quickly after leaving?

It turns out that Taro’s success was 2 years worth of preparation in the making.

Rahul and his co-founder Alex of Taro

While he was at Meta, Rahul grew his social media presence. He filmed over 200+ career advice videos and amassed over 72k subscribers on YouTube before quitting. He also had substantial followings on LinkedIn and Twitter as well.

Rahul has a sizable presence on social media.

He also leads multiple engineering communities. He has a “Tech Career Growth Slack group”, a community of 12k+ members interested in engineering career advice which formed the foundation of Taro later.

He also has a newsletter with over 20k+ subscribers interested in career mentorship. Both of these communities are major assets because they’re an instant audience for any future product he builds.

These two communities formed the basis of Taro later.

Lastly, he has passive income. He has a course on LinkedIn Learning, he taught classes at Stanford on Android development, and makes some extra income from his YouTube videos as well.

So if you look at his startup success, it came from all the work he had done for the last two years.

Rahul had a lot going for him before quitting his job.

Imagine if he quit his W-2 job and tried to go straight from Meta to Taro without any of these intermediary steps. It’s hard to imagine he would have the success he has today.

It’s unlikely Taro would succeed if Rahul didn’t take the steps in the middle first.

So if you’re thinking about leaving, here are two exercises to help you on your entrepreneurship journey:

Try growing to 1k followers on any platform of your choice: LinkedIn, IG, Twitter, YT, Medium, or TikTok by posting every day for 30 days straight.
Try making at least $1 from the internet before you leave. This could be through selling courses, PDF’s, e-books, coaching or consulting calls.

Should You Ask for a Severance Package?

In my opinion, if you’re planning to quit, you should try to ask for a severance package before leaving for one simple reason: if you don’t ask, you won’t get it.

You might be concerned it will make the relationship with your manager awkward. But you’re actually doing them a favor.

When layoffs come, upper management will mandate each manager to cut a set number of people from their team. If you volunteer for the layoffs, you’ve made your manager’s job easier because now they don’t have to decide who to cut.

It might be good for your teammates as well because otherwise the manager may lay someone off who didn’t want to leave.

Also there’s not much downside to asking. The worst case scenario is they fire you, but then you’d get the severance package you were looking for. And if they don’t give it to you, that’s the same as leaving voluntarily without asking anyways.

When it comes to negotiating a severance, I’ve seen two main ways of driving the conversation:

1) Using the pandemic as an excuse

2) Using a bad performance review to speed things up.

Regarding the pandemic, one line you can use if your company implements a back-to-office policy is,

“I’ve relocated during the Pandemic, and I’m not coming back to , and I would like to discuss a severance agreement.”

Someone told me they used this line when they were trying to get employees back into the office. They got a severance right away.

Second, if you’ve had a recent bad performance review, consider speeding up the process by asking for the severance package upfront since most people don’t get off of probation anyways. See this article for the script I used for that.

I recommend following the framework provided in the book “Non-Violent Communication” to handle difficult conversations like this.

Regardless of what you say, keep two things in mind:

1) Don’t blame anyone

2) Don’t come off as demanding

Here’s an example script I might use where I focus on neutral observations, feelings, and needs instead:

“I’ve been feeling very burnt out. A lot of it is due to career issues where the team’s goals aren’t aligned with my own career goals. And it’s only diverging further over time.

All I want is to feel more fulfilled in my career. You’ve been an amazing manager, and I’m so thankful for everything you’ve done for me. But at this point, I can’t find the career fulfillment I was looking for in my current role, and I don’t think there’s much you can do as a manager to fix it.

I know the company is focused on cost-cutting right now through the layoffs, and I wanted to discuss volunteering to be a part of these layoffs and the severance package with it.

That way, the company can save money, you find a better fit for the team sooner, and I can focus on the career fulfillment I’m looking for, a win-win situation for everyone.”

Lastly, timing is important as well. If you want to leave, time the exit near the 1st of the month as opposed to the 31st of the month because employee benefits are renewed on a monthly basis.

If you leave on the 1st, it’s like getting a full extra month of benefits. But if you leave on the 31st, your benefits may end the very next day.

Final Thoughts

Regardless of what you choose to do, my final words of advice is to act with urgency if your career is not going the right way. If you stay an extra two years at a job you wanted to leave, and did this over five jobs in your lifetime, that’s ten years of your life doing work you never wanted to do.

Also consider this metaphor I use to make hard life decisions.

Imagine yourself driving down a road. If you realized you were going in the wrong direction, you would never keep driving down that road.

You would stop and U-turn around as quickly as possible.

Yet often in life we know we are going down the wrong life road. And yet we continue to drive down those wrong roads for years at a time.

If you are willing to stop and U-Turn immediately while driving a car, then you should act with that same urgency while driving down wrong life roads as well.

So here are some final questions for you to ponder:

1) What career roads are you going down?

2) Which of these roads are the wrong direction?

3) How many more years do you want to keep driving down this path? What can you do to U-Turn and start going in the right direction this year?

I know life is uncertain right now. But you should recognize that this is an exciting time in your life as well.

I promise you will look back on this time as a pivotal moment in your career. This is the moment when you take control of your life and stop letting life just happen to you.

I hope this advice helps you get back on the right career roads as quickly as possible. I’m rooting for you!

💡 If You Liked This Article...

I publish a new article every Tuesday with actionable ideas on entrepreneurship, engineering, and life.

Join 2,801 subscribers on my newsletter here.