Mission Statement – Keep and refine project ideas

When I am mulling over a new idea, I find that writing the idea down is a useful exercise for it forces you to structure your thoughts, to tease out the essentials, and to do away with obtrusive chaff and filler. Words lend substance to thoughts and grant them a measure of permanence.

Having a handle on this phase of idea elaboration allows one to explore the very nature of what your mind can vaguely frame. Words on paper are all about precision. When writing, you make a conscious choice to use one word and not the other. You make a conscious choice not only about the choice of words, but also about their number, the voice, and the pace.

It’s not only about communicating the idea to yourself, once written down an idea as it would have been communicate to others. It is the message that fills the gap between a mere thought and a full-on action. “Why on Earth am I doing it and what I intend to do” begs a precise and deliberate answer. To execute an idea before putting down the mission in words seems grossly misguided.

Because I believe it helps to set things in words before they are set in stone, on paper, in ink, in oil, or in code (and in the fine tradition of computer engineers building tools to scratch their own itch), I and Tyler Hughes (who has graciously volunteered his time for this project) have build Mission Statement.

Because it’s not the thought that counts, it’s the message…


The precipitous slide into obscurity

Staying on top of social media and engaging with online communities — be it Twitter, Facebook, Tumblr, Pinterest — is turning us all into creatures driven by compulsion. Like sharks which must keep moving to survive, the moment we stop making noise online is the moment we start to suffocate and drown. Call it a struggle for relevance, if you wish.

Continue reading

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

Defining the vision for Raffl

I am taking “How To Launch your Startup Idea for Less than $5,000” class with Michael Karnjanaprakorn of SkillShare fame. For the first time this class is taught as a mix of interactive sessions, self-paced study, and weekly assignments, and I am happy to be a part of the experiment.

I don’t really expect any major epiphanies from the assigned reading and watching — I am already familiar with a lot of the material. Instead, my hope was that the class would help lend structure to the entrepreneurial dabblings I’ve started getting myself into.

In the spirit of transparency (for which this blog is undoubtedly famous), I decided to project my class assignments, discoveries and experiences here for all of you to follow. Also, I decided to use the Raffl idea as a vehicle for this class.

So, let’s start with Assignment 1 – Vision:

Continue reading

2011 Recap: 80,000 miles, 3 moves, 2 new jobs, and more

To say it was a tumultuous year would not do it justice. To think it was only a year would be to underestimate it by at least a lifetime. Continue reading