First two Months as Head of Engineering in an Early-Stage Startup

When I stepped into the role of Head of Engineering at an early-stage startup, I knew it was going to be fast-paced, uncertain, and filled with constant challenges. What I didn’t realize, however, was just how much I would learn in the very first month. Leading engineering in a startup is not just about writing code, running sprints, or scaling infrastructure,it’s about building an engine that keeps the whole company moving forward.

While 2 months is a very small time but I feel like these are helpful tips for my fellow engineers in similar boat.

Startups Move Fast- Really Fast

Everything you’ve heard about the speed of startups is true. Decisions that might take weeks in larger companies are made in hours here. Features go from idea to production in a few days, sometimes less. And priorities shift constantly as we test, learn, and iterate.

The pace can be overwhelming at first. Multiple threads move in parallel, and it’s easy to feel like your attention is being pulled in ten different directions at once. I quickly realized that attention and time are the most valuable resources in a startup. You need to learn where to place your focus, because not everything can get the same level of energy.

My background is entirely in big tech where you get assigned to a project by the EM, spend a week gathering requirements, write a design doc and do some meeting reviewing that. There are experienced people in the team who have done that before and you can ask them for feedback and guidance.

Startups are different. You still do all these things by yourself, in days(and sometime hours) and deploy in production behind a feature flag. And, thats the differentiator as well- they can outpace Bigtech in terms of speed of delivering features and customer support.

Agency Is Key

In a startup, there’s no room for sitting back and waiting for someone else to take the lead. If you see something broken, you fix it. If you see an opportunity, you chase it. You have agency to make things happen.

But with that freedom comes responsibility. You can’t just move fast for the sake of it. Every action has a ripple effect, and as a leader, you have to make sure those ripples move the company forward rather than sideways.

Startups are not that organised in the start and there is lot of scope and opportunity to improve processes. You got to take the lead and move the needle.

Building Systems Early On

It’s tempting to live in firefighting mode. Fixing bugs, answering questions, shipping features nonstop. But I learned quickly that my real job is to build a engineering machine, not just to do the work. That means putting systems in place early:

Processes for code reviews and deployments
Lightweight documentation for onboarding
Clear communication channels to reduce context-switching
Monitoring and metrics so we can see problems before they become disasters
Tooling for things which are manual and error-prone
Security from the start

Startups don’t need heavyweight processes, but they do need enough structure to avoid chaos. The systems you set up in the first month may be scrappy, but they become the foundation for scaling later.

Taking Breaks (and Not Panicking)

The sheer pace can be overwhelming. It feels like there’s always more to do, more fires to put out, more things to optimize. In those moments, I reminded myself of two things:

Don’t panic. Things will fall into place. Not every decision needs to be perfect. Startups are about momentum, not flawless execution. Just keep moving forward and the net total outcome for a day should be positive.
Take breaks. When you’re leading, your energy sets the tone for the team. Burnout is contagious. If you pace yourself, the team will too.

Learning to Delegate

As someone who has spent most of their career writing code and building products, delegation didn’t come naturally. But I learned quickly that in a leadership role, delegation is not optional-it’s survival.

The job isn’t to do everything yourself. The job is to build a system where others can succeed. That means trusting your team, giving them ownership, and stepping in only when you’re needed most. There are times when I am tempted to immerse myself in particular feature\bug. However, slowly I have realized that I need to integrate my people, systems, code, processes and build a machine. If the machine is designed well, it can take care of the velocity, quality and learning for all of us. And my time is well spent there.

That said- I do write code everyday but it is of different kinds spread across the systems. For example, Optimizations at Hotpaths, pipelines, tools, documentations, tests, glue code, scripts etc.

Wearing Multiple Hats

In a startup, titles are blurry. As Head of Engineering, I wasn’t just thinking about technical architecture or managing engineers. Some days I was the product manager, other days I was the recruiter, sometimes even the unofficial QA tester.

This breadth is both the challenge and the beauty of the role. You get to stretch yourself in directions you wouldn’t have in a larger company. But at the same time, you can’t escape depth. There are moments when you need to dive deep into code, architecture, or debugging and own the technical craft.

So much breadth that the tech stack I geniuinely operate on looks like one of those rookie CVs where you list down all the technologies :-)

Not Everything Will Be Fun. And that’s Ok

There are many tasks I don't enjoy doing. That happens to all of us. Maybe it’s wrangling an outdated dependency, maybe it’s chasing down a production bug at 2 AM, or maybe it’s sitting through another vendor call. These things will pass. The key is to not get stuck on the unpleasant parts, but to keep your eyes on the larger goal: building something that lasts.

Use AI tools to your advantage

Generting code is just one use of AI tools. I tend to be cautious here. However, there are many glue tasks where we can use AI tools to our advantage and increase our productivity. A 20% increase in productivity is a huge Win. Polishing emails, code reviews, generating readmes, documents, test scripts, MVP code, tools etc. is where AI tools are really helpful. And you can achieve more with a small team.

Final Thoughts

The initial few months in a startup leadership role is like being thrown into the deep end. You learn fast, make mistakes, and grow even faster. The lessons I’ve taken away are simple but powerful:

Move fast, but with intention.
Build systems, not just features.
Don’t panic. Things fall into place.
Take breaks and protect your energy.
Delegate and empower your team.
Embrace breadth, but dive into depth when needed.
Remember: your job is to build a machine
Use AI to your advantage

I’m only at the start of this journey, but if the first two months are any indication, it’s going to be an intense, challenging, and incredibly rewarding ride.