Commoncog is about better business and career decision making. This is a fancy way of saying that Commoncog helps you become a better operator. It is written from practice.
Commoncog’s approach has been described as ‘50% academic / 50% practical’, and ‘the intersection between good writing, good thinking, and actual business experience’. I prefer to think that everything Commoncog covers must be useful — that is, must be rooted in some real world domain, with enough evidence that it’s worth trying out in your life.
One way to talk about what Commoncog covers is to talk about what it doesn’t. Commoncog is not interested in fancy business frameworks. It is not interested in high-falutin’ theories. It is interested in academic research only in so far as it has been tested through application (there’s usually a fair amount of work to put research to practice, so you have to be prepared to do that work, or check that the work has already been done!). Finally, Commoncog is suspicious of recommendations from non-practitioners.
That isn’t to say that Commoncog’s authors are uninterested in those things. Only that Commoncog promises to not write about those things; it assumes you have only the time for actionable ideas.
How am I going to do this? I aim to follow these principles:
- My primary recipe here is 'take interesting idea that seems to be useful, try it out in my life, and then write up the results'. If I'm writing about something that I haven't tried, I'll tell you about it. If it doesn't work out, I'll tell you about it. Full disclosure.
- I will bend this writing towards usefulness. I find that many business books and blogs are theoretical, or irrelevant to the individual career. It's not clear, for instance, how the rise of automation would affect you, today, or perhaps tomorrow. Even in the cases where I write about ideas, I will make an effort to eventually tie such ideas to the individual career.
- I will write with the appropriate level of epistemic humility, and I will cite with an appropriate level of epistemic rigour. On humility: I will use more confident language if I am writing about topics within my circle of competence, and less if I'm not. I will be upfront as to which it is. On rigour: when I cite scientific studies, I will keep in mind the weaknesses of null hypothesis statistical testing. I will perform checks — limited by time and my statistical sophistication — to verify that results are not rubbish. When citing practitioners, I would vet their recommendations according to my hierarchy of practical evidence. This is because you deserve to know if the techniques I write about are rubbish. (More about this principle here).
Why am I doing this? This is simple: writing is thinking. Writing this blog forces me to think better, which should — I hope — allow me to make better-informed, strategically sound business moves.
I hope you'll find some value in following my journey.
And You Are?
I ran the engineering for EPOS — a point-of-sale provider in Singapore — for three years. Our business thesis was that POS systems were the way we could ‘own’ a business's data, which in turn would form the beachhead from which we could sell other products like CRMs, inventory management, accounting packages, etc. We pivoted to this business after a year of consulting, sold both hardware and software, and bootstrapped our way from 0 to $4.5 million annual revenue in two years.
Shortly after that I ran marketing for Holistics for two years, where, right before I left, I helped them double their annual recurring revenue over the course of eight months.
In a previous life I did Novelr, and helped to create the Web Fiction Guide. I also built a Hacker's club in university.
I like Python, Go, green tea and cats, and good books — lots of good books, though you can probably guess from this site.
I'm always happy to receive email. You may reach me at cedric [@] commoncog.com, or ping me on Twitter.