Learning by doing

The past month was a very satisfying one in term of workflow. Finally we've managed to devote more time in terms of full days (and nights) to Plunify. Finally many other commitments have been fulfilled, freeing up precious time.

This post is a bit fuzzy in that I just wanted to summarize a few things we've reflected upon in the last few weeks:

Nudging the flywheel
Jim Collins in his wonderful book, Good to Great, mentions the importance of working incessantly on little things that make up one's overall goal. Eventually (hopefully) every little ounce of preparation builds up enough momentum to propel your startup/organization forward.
I feel that this train of thought is not just about leaving no stone unturned but also about gauging the relevance of tasks that we are working on. It sounds obvious, but before doing most things, we've come to ask why we're doing them and how they can help our overall goals. For example, building a business relationship with distributor X to sell FPGA design guides or writing a script to automate file transfers across servers. Since time for a startup is precious(gotta make $ before the $ runs out!), we really have to evaluate what we do.
Interestingly once such questions are asked, we usually get a gut feeling of what's "right" and "wrong". And it really helps focus us on the "right" tasks, not to mention deepens the sense of satisfaction when such tasks are completed.
Of course no one can predict the implications of every task. Discussing it within the team and with outsiders should help determine its relevance in the overall scheme of things. If it seems right after a good night's sleep, just do it and add momentum to your flywheel. Plunify's is only just starting feel its molecules stirring.
Sometimes the Wheel weaves as the Wheel wills πŸ˜‰

Learning by doing
While getting from Step 1 to Step 2, inevitably Steps 1.001, 1.002 pop up in-between. Whether it is inadequate planning or just the way things are at the beginning, I don't know. But it certainly spices up the day! We could be coding a feature to remotely access a server and suddenly find that the PHP library we're using requires some tweaking. That tweaking might lead to more Googling which in turn causes us to download a compiler to re-compile changes to the PHP library.
The point is, we'd have never realized the existence of these extra steps without getting our feet wet. So to anyone who might be hesitant about venturing out on a limb: just take the first couple of steps and you'll find out the potential of your idea, quicker than most forms of advance planning and forecasting.

Engineers without borders
Working with people over the world automatically broadens one's perspective. From the start, we wanted Plunify to support multiple languages and to sell to customers. Hence every webpage has to have a corresponding Chinese or Japanese version. It's been fun asking friends if they are interested in translating pages for us. Does anyone know how to properly translate, "FPGAs are the predominant devices used in Programmable Logic Design today" into Chinese or Japanese for us? πŸ™‚
The energy of the FPGA community is also nothing short of amazing. For example, no matter where we ask, people always have comments and ideas on how FPGAs can be made simpler for users. A potential board member could be emailing us from Indonesia while we're Skype-ing with an advisor in Japan. Is this the power of the "community" that people always talk about?


Leave a Reply