Going From Developer To Leading A Team Of 4 Engineers At A Fast Growing Startup In My 20s - Mistakes & Lessons

In the beginning, I focused on coding rather than focusing on the team.

I was 24, working at a Seed-Funded startup for a year, and in about 2 months, I went from regular developer to be in charge of 4 other recently employed developers. At first, it made me feel fantastic - my value was recognized, but after a while, it drained me.

I sought help, and this is what I learned to thrive in the position.

You are NOT a developer anymore! Your job is to help others be great developers. Be ok with others taking credit.

If you don't understand this, you will hate your job.

The biggest issue I had, in the beginning, was that I tried to keep coding, and I secretly hated people constantly interrupting me with questions. The startup founder told me this gold gem:

"As a leader, your performance is now tied to the performance of your team, not your own".

If you heed this advice, you will save a lot of frustration, have more time on your hands, and be overall a happier individual.

Here is how to do that specifically:

#1. Don't make your team dependent on you. You'll start to hate them!

The more developers figure things out on their own, the better they remember the solution.

How to do it: Give only the expected result, sprinkle some hints about technology or places to start, and let them fly off. When your team asks for help, help using rubber-duck debugging. Them articulating the problem to themselves (through you) will help more.

#2. To maintain sanity, have clearly defined office hours.

If you expect questions and problems during a set time window, you will welcome your team, thus maintaining excellent communication.

Say to your team: "I am available for any problems or issues between 12 PM - 4 PM". By doing this, you can carve out some time for your coding but make sure to make the office hours window more significant than the coding window.

#3. When somebody makes a mistake, improve the system to make the error impossible in the future.

When somebody fails, your first instinct will be that the problem is with him, and the developer will feel that and distance himself from you.

Here's what to do: Try to understand all the developer's steps. Automate all the pieces that are sensitive to human error, like PR descriptions, testing features, deployments, etc. Mistakes make your systems better.

Implement these actions if you want your experience as a manager/technical lead to be great. You still will have some time to code, and your team will be happy.

I hope you liked this post! Let me know what else to write about!