Limiting Developer Head Count

8684305904_e74c2053cb_b

Yesterday we had an interesting discussion with our product people about further boosting our hiring plans. Our CPO (Chief Product Officer) advocated even more aggressive hiring to make product development move faster while myself in capacity of VP of Engineering advocated a more limited approach. My first argument against expedited hiring was that we've just employed several people and bringing them up to speed will already substantially slow down the existing team members. Employing even more fresh people would essentially bring us to a standstill and our capability of developing new software would be severely limited for at least few weeks.

My second argument revolved around feed the beast phenomenon. Namely, if developers start walking around idly without a backlog of tasks waiting them to do, pressure builds upon product managers to start giving programmers work just to keep them busy (thus "feed the beast" moniker). But even giving superficial tasks to programmers takes away precious time from product developers and defocus them from a real task of product and customer discovery.

Another reason why I prefer lower developer head count is that limited resources make product managers focus on the essential features of their product and prevent them getting infected with featuritis. Scaling of a product to more use cases is a great way to hide a missing product-market fit and the one that kills you by a thousand cuts.

Finally, thinking of the amount of code that 15 engineers can produce I become terrified about the effort that will be required to support and maintain that code in the future. With millstones around your neck it's impossible to run fast and I don't want that to happen to future Zemanta.