Monthly Archives: March 2012

Careers in Product Management: A Generalist’s Lament

When I interviewed for a technical product manager’s position with my current employer I was asked if my background managing a low-power wireless networking stack for embedded devices with 128K of flash would be transferrable and appropriate for a company who provides educational software sold to school districts and running on large enterprise-scale systems in the cloud. I said ‘sure’ it can.

My argument ran that a good C engineer could become a good Java engineer. The good in the engineer does not come from his knowledge of a particular programming language but rather from his aptitude for abstract thinking, ability to decompose problems and to work as part of a team. A good product manager is a good product manager. Whatever the product vision is (and whatever the product is) it needs to be articulated in simple terms to audiences internal and external, it needs to be launched, its performance and metrics tracked; it must be squared against competition and it must be decomposed into a set of requirements and priorities for the engineering.

Admittedly, in making this argument then I put my own interests ahead of the truth. I’d be lying if I told you that I didn’t worry that once I transitioned into this new universe there would be a huge learning curve to overcome, much like there is a huge learning curve to overcome in going from C to Java. I also knew that the chances of this hypothetical C developer being hired by a Java shop were ┬áinfinitesimally small. “How much better were my chances”, I wondered?

Whether through the sheer powers of elocution or luck, the chances turned out to be much better indeed. I was hired, and the transition I worried about for myself has gone off without a hitch. I’ve now been in my new role for 6 months, and I don’t feel particularly disadvantaged by my background to be in this very different domain. And that’s the essence of my lament…

Is there something intangible about a market that my 5 years of experience failed to surface? If I’d been in embedded for 10 years, would I be less capable of making this transition or is it all ultimately the same stuff? Are we, the product managers, just delusional about our so-called vertical expertise and are our skills more interchangeable than we care to admit?

If this is indeed the case, count me disappointed. It means that either we can never become exceptionally good or that there is just isn’t that much that’s specific to any one product. While there is still no limit to how much experience and expertise we can accumulate, would this observation imply that it doesn’t matter where we do it or whether we hop across multiple domains in the process?


Does your project have magic code?

I love magic code. It’s both a sign of a rapidly evolving software where priorities are fluid and sometimes moving on is the only option, and a rapidly evolving organization where code ownership tends to switch and new owners tend to write around things, leaving magic code at the margins of the codebase.

Magic code is sometimes a testament to poor or non-existing code review and documentation practice. Someone wrote it, then they left. Then this other person came in and tried to untangle it, and all we got was a broken build and we haven’t touched it since — no time and no energy to understand it, if leaving it intact gets the job done.

Magic code is scary, especially when it resides at the bottom or at the heart of your software stack. This magic code is always guarded by select few who know of it’s central nature in the world, but can’t explain how it makes the system work, which gives rise to a kind of religious following. We know it’s important, we know it rules over us, but we can’t tell you how it functions or why it works they way it works, and… we are afraid to challenge it.

Absence of magic code can be scary too! That’s the opposite problem. When everything is neat and proper, when everything makes sense, when there is no unexplained, preternatural totem to worship and obey. This is usually a sign that too much time is spent preening the code base, fixing the technical debt, and doing so obsessively, refactoring and generally making things perfect for the sake of perfection.

Neither extreme is good, and both are equally unrealistic. As is often the case with matters with two extremities, it’s all about the balance.

Does your code base have magic code?

The one interview question I always ask

I’ve just gotten past a peak interviewing period where I would interview 3-5 engineering and product management candidates every week. I’ve used this question for as long as I’ve interviewed people, and it has never failed to reveal something not-immediately-on-the-surface about every single candidate. So I was not surprised that it still works, but I did get a little better at understanding why. Continue reading