They’ll Measure You

If you happen to be a Product Developer in a large company, a day will come when you will hear the dreaded word. Metrics.

Human minds are traditionally weak in dealing with unstructured information. This leads to the propensity to measure something in order to understand it better. Measurement by itself is not a bad thing but reckless application of a successful principle into uncharted territory should be dealt with caution. Measurement of an activity is the first step in automating it. There are several intervening step but the direction is towards factory-ization. Look around in the manufacturing world and you will see dozens of examples. Look around in the software world and you will see that some activities have already started getting measured and incentives aligned with the metrics the measurement throws up (application support for example is measured. The measurement parameters – mostly ticket clearance velocity – are wrong but that doesn’t take away the fact that the activity is measured).

Developing products is a creative process and I have my inhibitions about such processes being measurable. Harper Lee would have definitely lost out to James Hadley Chase if she was measured on the number of books written. Charles Dickens would have won hands down if “words per book” was applied as measure of articulation (incidentally, Dickens was paid by the word, which leads to the first warning for measurers – “beware what you measure for thou shalt get just that”). There is no need to measure and discover the best developer if you have just seven working for you – everyone knows who the best is. Yes, there is a need to measure if you have seven thousand (if you have that many then most likely you have been factory-ized already. You have implicitly “allowed” yourself to be measured).

What you do is not what you are called (and vice versa)

This malaise is fast approaching dangerous proportions. The nomenclature of your title has started getting very different from what you do. A Product Manager is now expected to manage people (perhaps overseeing just a requirements factory) rather than managing a product. A Quality Assurance Manager doesn’t even test anything. A Development Manager doesn’t write code. The victory of title over function is perpetrated by large consulting/services firms where titles are currencies of different denominations that the firm monetizes. Product companies are poaching senior executives from these firms (why?) and walking straight into this mindset gangplank.

If you are in a product-centric company my advice is to keep your mind clear. Stick to your function, take it seriously. The lazy hides behind a title.

What’s that you’re solving?

It is not difficult to detect this pattern – smaller companies build, larger companies buy. There is a reason why this happens. Invariably, the smaller companies demonstrate signs of what my friend colorfully called HTML (hand-to-mouth-living) and are over zealous to solve a user-problem so they can sell quickly. This is the true reason why smaller companies are quicker to market, innovative and closer to customers. Product Development in these organizations are rapid and success happens even in nebulously defined teams. Over time these companies become successful, profitable and attract a lot of interest from the larger sharks. The pressure to monetize the investment (especially if a Private Equity firm has invested in the venture) gets progressively higher and then the sell-out happens.

The problem thereafter shifts to the larger acquiring company. It has already blown up good multiples in the acquisition so it needs to fix that. Precisely at this juncture the focus shifts, for the large company, from solving customers’ problems to the organization’s problems (Joel Spolsky writes about this). Hundred of thousands Dollars get spent on heavy duty architecture to rationalize internal plumbings and soon resourcing such projects draws traction away from teams who were perhaps making an honest attempt to solve the outside-world problem. More acquisitive a company is the more accentuated is this phenomena.

So is this phenomena bad? I don’t know. What I do know however is that this phenomena is for real and needs to be managed. The trick is to go back to the start-up mode for the outside-world projects and pick only those you’d invest your own money in. If you are in a large organization, the plumbing projects will always attract more resources – at least initially – so don’t expend energy fighting the battle on that front if you want to keep solving the customer’s problem.