I was reading an article titled ‘Engineering wants to rewrite‘ on the SVPG blog and couldn’t help keying in my own thoughts around the dynamics engineering has to work its way through in a technology startup. To quote the article:
When a company does get into this situation, everyone typically blames engineering. But in my experience, the harsh truth is that it’s usually the fault of product management. The reason is that for the past years the product managers have been pounding the engineering organization to deliver as many features as the engineering team possibly can produce. The result is that at some point, if you neglect the infrastructure, all software will reach the point where it can no longer support the functionality it needs to.
Most startups work at break-neck speed and the focus is always on features. The uncontrolled pace of piling up features without thinking of infrastructure and architectural limitations is a key component in this collapse. In a startup, a high rate of feature addition is inevitable and needs to happen. In this view, how should the Engineering and PM verticals be prepared to ensure a catastrophe is not waiting down the hill as products roll out? Here are some thoughts .
1. Hiring the right engineering leaders: An architect is a must in any technical startup and should have the required experience to drive scope of features. If it is difficult to hire an appropriate architect, the engineering leads should play an active role in deciding feature feasibilities and proposing required architectural changes early in the process. Companies often consider this as a luxury and tend to cut cost by hiring more product managers (or business analysts), hoping that they will turn out a well-spec’d PRD making it obvious for the engineering team to code it up. This just doesn’t work. Having too many people to manage and too few to work doesn’t go far. Often an absence of an assertive engineering leader makes it difficult for the engineering problems to be shared in a meaningful manner.
2. Defining the product owner: Every product should have an owner; and the ownership should be complete. Products should be owned by individuals who have the best understanding of the product and can best represent the product to a customer. This need not always include people from a particular vertical. Without a product owner role clearly announced, products and features keep going in vicious circles that may never reach customers. It should be the product owner’s responsibility to share customer feedback in it’s original form and as frequently as possible.
3. Involving the engineering all the way: In a McKinsey Quarterly interview of Bill Campbell (membership required), he emphasizes the need for allowing engineers enough clout for enabling an innovation culture in the organization. Nothing turns on an engineer as to see a product work and sell and nothing turns them off as working on idiosyncratic features and a pile-up of ill-managed code-base that seems to be going nowhere.
4. Building a peer relationship between PM and Engineering: SVPG again has a wonderful write-up on this, so I don’t need to write much. Read this article – Product Management vs Engineering.
Startups in particular need to be careful about these issues because fast pace development is not a luxury it can afford to skip, it is a necessity.