What I have learned from running a small software consultancy

Me and two friends started Glio in September 2012. By day Glio was a consultancy, offering website development (mainly with WordPress on LAMP) and graphic design services. By night Glio tried to be an incubator — we hashed out hypotheses and ran lean experiments, but unfortunately nothing sustainable ever emerged from these endeavours.

We finally shut Glio down sometime at the end of 2014. It goes without saying that I learnt loads during these two years. This post attempts to chronicle these learnings.

  • You’re in for the long haul. Despite what Silicon Valley might make you think, building a company is going take time. At times, it’s going to be boring and unglamorous. It’s definitely going to be hard work. Make sure that you realise the gravity of this, and make doubly sure that your partners realise it.
  • Separate your role as an owner from your role as an employee. As a owner it’s expected of you to bring leadership to the table. As an employee, it’s expected that you do quality work and that you are remunerated in return. Don’t confuse the two roles. Working 60 hours a week doesn’t make a good owner. Leadership, vision and care makes you a good owner.
  • Being really good at something does not mean that you should start your own business offering the skill. This speaks to the previous point. Being really good at X and getting paid for it, versus being really good at X and trying to sell it to unknown customers in a repeatable, sustainable and scalable way are two very different things. If you want to start your own business, make sure you’re the kind of person that loves the latter (otherwise go work for a boss).
  • It’s about the other eight business model building blocks too. The Business Model Generation book outlines nine building blocks that constitute a business model: value proposition, customers, customer relationships, sales channels, key activities, key resources, partners, cost structure and revenue streams. We often found ourselves in the situation where we focus only on one building block, value proposition, and completely ignore the other eight building blocks. If you’ve got a good idea, just build it and they will come, right? Wrong. You need all the other building blocks figured out too, and those are the hard ones.
  • The admin around starting and running a business can be complicated and tedious. Outsource these tasks where it’s worth it to do so (we did our own tax for a long time, and then outsourced it and haven’t looked back since).
  • Process is important, but values are more important. While a solid process will help you to control scope creep, for example, values will make you understand why it’s necessary to control scope in the first place. A good comprehension of the former without any presence of the latter will just cause headaches.

Growth comes from real failure

There is a certain narrative that is prevalent in contemporary startup cultures. Its story goes something along the lines of “failure is good so long as you’re learning from it”. On the surface it suggests speed and adaptiveness: fast-moving iterations driven by a tight feedback loop calibrated to avoid waste (who wants to spend hours building something nobody wants, right?). I’ll be the first to admit: it sounded smart, tenacious and brave.

But this version of failure has a subtle consequence: stagnancy. All of a sudden the act of failing becomes a mundane event, just one of many more to come. Failure loses its power. It strips you of the ability to question the bigger picture. Each time you fail, you are encouraged to take a different angle and try again (until you fail again, rinse, and repeat).

The truth is that real failure hurts. Real failure drives you into a dark corner and forces you to reconsider what you value in life. And then you grow.

A quick review of Exploring Everyday Things with R and Ruby

I’ve recently learned a lot about Ruby, and I’m also quite interested in R, a programming language for statistical computing. The book Exploring Everyday Things with R and Ruby naturally piqued my interest.

Overview of the book

The first two chapters does a quick primer on Ruby and R respectively, and does a sufficient job to get you up and running with both Ruby and R.

The remaining six chapters each tries to “explore” a question. The main approach to “exploring” is a two-step process: 1) Use Ruby to extract data (typically stored as a CSV file) and 2) analyse this data with R.

The first chapter explores the amount of toilets required for a certain number of people. Ruby is used to simulate this population of people, the toilets and the queues forming outside the restroom.

The second chapter builds a basic model of a laissez-faire economy, and analyses the effects of price and demand.

The third chapter tries to glean insights from your email usage patterns, and uses a public collection of Enron emails to illustrate the points.

The fourth chapter lets you record your heartbeat and your pulse, and then extracts the information from the raw media files to visualise your heartbeat and heart rate.

The fifth chapter looks at the way birds and fish tend to flock together, and builds a Boids simulation to explore emergent behaviour.

The final chapter extends the previous model, but introduces several more elements into the simulation, including food, reproduction and evolution.

The good
  • I think this is an excellent book for those who are curious, and wants to get a taste of doing some hands-on “exploration” of “everyday things”.
  • It gives you a collection of easy-to-understand and fun toy problems which you can explore on your own.
  • It’s a short and easy read.
The bad
  • Unfortunately the book is quite sparse on the why behind the analysis (the emphasis is really on exploring rather than analysing). Don’t expect to learn anything about statistical inference or probability theory. This is to be expected to some degree, however, since the book aims to be a layman’s introduction to using regular tools (Ruby and R) to explore regular stuff (building planning, the economy, flocking behaviour), and this it does really well. It’s the perfect appetiser, but it won’t satisfy you.
  • The code provided in the book is full of errors. To get any value out of these, you’ll have to clone the GitHub repository and work with that code.

I would give this book 4 out of 5. It’s a quick, fun whirlwind tour of using Ruby and R to prod at a variety of problems. Just don’t expect to scratch more than the tip of the iceberg.