Every startup should have a full-time Head of Engineering, but many can’t afford one. In that case, there’s an alternative model:
Hire really smart junior engineers, in the top 2%, and multiple such engineers. They together take on the responsibilities of the Head. Which are too much for one junior engineer to handle alone. By definition — if a junior engineer could take on these responsibilities alone, he’d be the Head and not a junior engineer.
Junior engineers may make mistakes that may take a quarter or two to course-correct. That’s the tradeoff with not having a Head.
For this model to work, multiple things have to be in place when it comes to the junior engineers:
First, when hiring, give significant weight to a demonstrated ability to learn, more than knowing any particular stack. For example, one of my engineers delivered a project in two weeks on a new platform. This is especially important in this setup since there’s no full-time Head to turn to.
Second, don’t hire for the minimum skills needed. A founder asked me, “We need him to do only frontend, so why care about backend?” This is a short-sighted attitude, since you don’t know what you’ll need someone to do, especially for this model, since you don’t have a full-time Head to fall back on. To take another example, say someone knows two backend stacks like Firebase and Rails. You might say that’s redundant, since we’ll use only one stack. But that’s again short-sighted. The engineer who knows two stacks is a better hire, since he’s more likely to know the stack we end up using. Or be better at picking which stack to use. Or know if the current stack isn’t working out. Or if the company pivots, the skill was dismissed as irrelevant may turn out to be relevant.
Third, hire system engineers if possible, not just application engineers.
Fourth, don’t be miserly regarding their salary. If they have an offer, match it, even if it’s towards the high end of the market range. Don’t obsess about ₹5 lakh, since that’s still a fraction of what a full-time Head would earn — that would be penny-wise and pound-foolish.
Fifth, incent these junior engineers to stick around for years, such as mentioning in the offer letter that their salary will be doubled when the company raises a series-A round (or achieves other business metrics like revenue).
Sixth, founders of a company adopting this model should be supportive and positive. More than usual. Say an engineer says something will be done in two weeks. It doesn’t get done. The founder asks again. And the engineer says again, “Two more weeks”. And it’s not done again. At this point, some founders told me, they were very unhappy with the engineers. At one level, this is understandable. But estimation is a skill engineers develop very late in their career. Founders should be cognisant of that.
When we’re stepping outside our comfort zone and doing things we’re not qualified to do, it’s scary. We’ll naturally be worried: maybe we’ll fail. Maybe we’ll look bad to others. Maybe we’ll be criticised. And so on. All this requires encouragement to overcome. Being negative, or coming across as negative even if not intended, can backfire, and make people lose their confidence, or retreat to their comfort zone. If I’m climbing Mt. Everest, I need a cheerleader, not a critic.
Seventh, talking to a couple of competent engineers who worked in this model, I identified a few more things that should be in place: the team should have at least three engineers so that people have others to consult when they have problems, rather than feel that the entire weight is on their shoulders. And having three engineers doesn’t help if each person works on one area without collaboration. There should be code reviews. Refactoring. Pair programming. Retrospectives. Tech talks to help people understand. The founder should periodically get his friends, who are senior technical people at other startups, to chat with the team about whatever is bothering the team. And so on. It shouldn’t just be about the milestone of the month, every month. The company should send them to a relevant conference at least once a year, like try Swift for iOS engineers. This leads to growth, and a feeling of “Yes, I can handle challenges, with all this support behind me” not that “I’m thrown in the sea to sink or swim”.
In summary, if you can’t afford a Head of Engineering, here’s how to run a startup without one, as long as you understand the tradeoffs and are comfortable with them.