Ken Imboden on Lessons From MMC, Candlestick, and NuSym

Ken Imboden offers lessons learned on developing software products from managing at large firms, and successful and unsuccessful startups.

Ken Imboden on Lessons From MMC, Candlestick, and NuSym

I worked with Ken Imboden at  MMC Networks (acquired by AMCC in 2000). He managed a key group of microcode and embedded software developers whose efforts drove the successful adoption of MMC’s network processor chips. His role required him to manage both development and key customer issues and his judgment was sound across the board. He hired, developed, and motivated a very talented team and successfully buffered them from most of the chaos you would expect to find in a startup.

Ken went on to work at Candlestick Networks (acquired by Nortel in 2001) and co-found the now defunct NuSym Technology with Chris Wilson and Dave Gold. I reached out to him this week to get his perspective on lessons learned from working in software startups and he was kind enough to reply with this list of what he has learned from several startups over the years:

1. Focus obsessively and relentlessly on providing measurable value for the customer. Ensure that your daily activities reflect this.  Insist that your co-workers do likewise.  Any effort you expend must be justified by value provided to the customer.
2. All software is crap. (No?  Provide me with a counterexample.)  Most of the training that software developers receive, and most of the effort they expend, does not alter this fact, and in fact is perversely designed to ensure this result.  Decide what you can do to alter or ameliorate this fact.
   Humility is of great benefit in a software developer; hubris is of great detriment.
3. Aggressively manage multiple development sites. Otherwise the sites will drift their separate ways, often to cross purposes.  Excessive interaction among the sites is a must.
4. Periodically step back and dispassionately assess your company’s progress. Your goal is to generate profit — obscene amounts of profit.  (If you disagree, be sure to inform your prospective investors of your goals.  When you have gone long enough without funding, correct your goals and come back here.)
   • For a software firm, subgoals working backwards:
     • revenue,
     • purchase orders,
     • customer endorsements,
     • customer use,
     • customer use in a services model (taxicab mode),
     • in-house use,
     • development,
     • customer affirmation.
       (Note that software development is a small portion of the process.)
   • Periodically, ruthlessly measure your progress along the path of these subgoals.
5. Stop doing the wrong thing. If your periodic assessment reveals you’re on the wrong path, change something in your process.  Otherwise, plan to keep getting undesired results; do not be surprised by this.
6. Your initial idea is not your final product. Your first several ideas will not be your final product.  Customer affirmation of your idea is a necessary starting point.

Ken noted in closing:

I don’t think I’ve given you anything most folks did not already know.  The challenge is, of course, in the execution, especially reorienting the mindsets of egocentric and introverted software developers (pardon the redundancy), driving home the fact that the customer does not give a damn about their cleverness, the algorithms they implement, or their credentials.  The customer cares only about satisfying their own need.

Related Blog Posts

• John Cutler on Product Management Lessons Learned
• Alastair Hood: Lessons Learned Bootstrapping Verdafero
• Arun Kumar: 9 Lessons Learned Bootstrapping Kerika
• Byron Wien’s Lessons Learned in 80 Years: Seven for Entrepreneurs
• B.V. Jagdeesh on “Startup Leadership Lessons Learned”
• Michal Mazurek on Lessons Learned Bootstrapping Syften
• Moe Arnaiz: Lessons Learned Bootstrapping eMOBUS and Weeldi

Image Credit: “Vintage Compass Rose” images licensed; © Claudia Mora