From programming to business: Lesson 0

When you ask people for tips in their area of expertise, they often gloss over the most basic things they do because, you know, it's obvious. They live and breathe this stuff, so it doesn't occur to them to call it out.

I've been a programmer since I was six, and some of these basics were the hardest to learn when I made the transition to being an entrepreneur.

Here are six of the most basic things I've learned to do differently in five years of entrepreneurship and two years of working on my business full-time.

1) Causality is a bitch

As engineers, the one thing we're used to is clear cause and effect relationships. We know that given enough time and effort, you can figure out exactly why a certain bug occurred or a piece of code does what it does.

In business, it is very rare that you can figure out the exact sequence of events that led to a lead being generated, or a customer buying a licence. You'll have a general idea, but that's about it.

Usually, the best you can hope for is statistical correlation between two events. This pre-supposes that you have a statistically significant volume of information to figure this out in the first place, which is not always true.

This blog post is an excellent example of my having made peace with fuzzy cause-effect relationships. Do I think this specific blog post will bring in more consulting work for C42, or significantly increase traffic to our products RubyMonk and Bevy? Probably not. But I do know from experience that blogging regularly has a net positive effect on lead generation, with occasional spikes that convert to game changing engagements for us.

You'll need to:

• Accept that the real world doesn't aggressively manage complexity through abstraction. The real world is much harder to debug than a codebase.
• Gather information when available and analyse it for correlations.
• Accept that in the absence of hard data, you'll be heavily dependent on your intuition to make decisions.

2) Business is about people

Businesses exist to create value for someone. That someone is your customer.

However, we tend to focus on the customer to the exclusion of everyone else that contributes to the value creation process. Remember that guy you interviewed five years ago at your previous company? He enjoyed the experience and follows you on twitter. Last month, he sent a prospective customer your way.

There's no way you could have predicted this particular sequence of events up front.

Businesses often succeed because of a serendipitous series of connections between people. The acquaintance at a meetup that suggests a feature, the interviewee that thought you were unusually nice that recommended you to a VC, the colleague that actually wrote the code that makes your product go... all of these people contribute to your success in unpredictable ways. Not all of them have formal business relationships with you -  in fact most won't.

In other words - business networking, marketing and sales are very important. If, like me, you're an introvert and don't like meeting strangers, buckle down and get over it. If you're lucky, you'll eventually be able to hire someone to do some of it for you.

Incidentally, it's easy to go overboard with the whole networking thing. You'll learn to improve your assessment of people over time, and then start avoiding the leeches. No quick solution here, though.

You'll need to:

• Be nice.
• Meet more people.
• Pay more attention to how happy your colleagues are working at your company.
• Accept that a tiny percentage of the people you interact with today are going to help you achieve very important things in the future in ways you can't predict.
• Understand reciprocity - the more value you create for people around you (including your colleagues), the more likely you are to have them create value for you in return.

3) Don't ignore sales and marketing

Sales and marketing aren't just customer facing activities. Every interaction you have with anyone that is business related is either a sales opportunity or a marketing opportunity. 

You're always working on creating a brand for your company, your products and yourself. Understand exactly what you're selling, to whom and pay attention to how they find out about your products and services. We did something similar for C42's consulting arm by figuring out how we would look for outsourced Rails consultants. We then used that information to figure out how to make ourselves more accessible to prospective clients.

You'll need to:

• Study the basics of both subjects. Understand sales channels, market segmentation, cross-selling and up-selling.
• Recognise that many seemingly internal activities like interviews are actually sales (you're selling the idea of working at your company to the candidate and everyone they speak to).
• Understand that promoting your company is an ongoing activity that every employee is a part of.

4) Make yourself accountable

When you go from being a student or employee to a business owner, it's very easy to let it go to your head. This is especially true for solo founders and businesses that aren't at a point where they have a board to hold the founders accountable for performance.

Ensure that you're making yourself accountable to someone - having co-founders is a good way to do this. Maintaining a system of checks and balances is very important.

You'll need to:

• Identify mature, experienced people who can give you candid feedback. It's even better if they're your colleagues. Favour a diverse group with people who have different priorities.
• Keep evaluating your own performance. Constantly ask yourself if you'd hire someone who performed like you to replace yourself. You may be surprised at how often the answer is "No."

5) Get a To-do list

The thing with writing code is that you're most productive when you're in the zone. You go in for several hours, churn out code and then come out of it. Every interruption is to be avoided.

Here's the thing with a business: Your day is one long series of interruptions. Get used to it. Your colleagues and customers have a right to your time, so make sure you give it to them.

Your best friend in this situation is a ToDo list. Figure out what tools work best for you, but remember that if you don't track what you need to get done, it won't.

FWIW, I use a combination of email (basically 0 inbox), Trello and iCal (integrated with Google Calendar) to keep track of things.

You'll need to:

• Get organized, set up some kind of system. Use tools to facilitate the system.
• Set up your calendar, maintain it and share it with your colleagues.

6) You can't be good at everything

You've already spent 10,000 hours learning to be a good engineer. Now you have to spend another 10,000 hours learning to be good at business. What's more, business consists of many interrelated areas that you need to be aware of, and you can't be an expert on all of them.

You'll need to:

• Start studying. Dip into subjects like accounting, economics, marketing, sales and finance.
• Accept that you're not going to be an expert on any of these. You don't have the time.
• Learn to hire the right people to handle areas of expertise that you need for your business. Then support them while do their job. Remember, they know it better than you do, so you need to trust them to get things done.

---

Similar posts

• Everyone is running a business, including you.
• No virtuous circle, or how India's Silicon Valley is... different
• C42 Engineering, Year One
• On building companies, open spaces and with a little pairing on the side

---

If you liked this post, you could

subscribe to the feed

Follow @ponnappa

upvote it on Hacker News

or simply comment on this post

No virtuous circle, or how India's Silicon Valley is... different

I've lived in Bangalore since I was three - we moved here in 1987 after my father retired from the public sector that year. Bangalore, then, was known as a retirement city, famed for its pleasant weather and abundant greenery. The Indian economy was still closed, most of the jobs were in the public sector and salaries were low. Top executives in the public sector earned less than Rs. 60,000 a year - my father retired as the General Manager of United India Insurance, giving me a reference point. At an exchange rate of about fourteen rupees to the dollar, this amounted to around 4200 US dollars a year, give or take. Somewhere around this time was when Bangalore started to be called the "Silicon Valley of India" by the local media.

1997

Ten years on and six years into the post-liberalisation economy, Bangalore was already starting to become a software hub. I remember my cousin doing a course in Java and joining Wipro, making him one of the lucky few to have a well paying job at a respected firm. At this point, Texas Instruments had been in Bangalore for twelve years and Infosys for fourteen. Wipro had diversified from vegetable oil into IT a full seventeen years earlier. Younger upstarts like MphasiS hadn't been founded yet. The average software engineer earned about Rs. 100,000 a year right out of college which at 1997 exchange rates was around 2800 dollars a year. Senior executives in the private sector were taking home heady sums like fifteen lakhs (1 lakh == 100,000) a year if memory serves.

2007

Twenty years on, it's 2007. This was the year Flipkart.com was founded by a couple of ex-Amazon engineers. I'm twenty three years old and working at ThoughtWorks while also (with my employer's permission) moonlighting at my first start-up, InActiv Labs, where we're frantically trying to raise money. Our first offering, a SMS based personal accounting service had tanked the previous year, but our group messaging service, Activ Mobs, had gone viral. Serving the 60,000 users we accumulated in the two months after launch was costing us about three thousand rupees with spikes to six thousand rupees - every day. We were basically spending 60% of our combined founders incomes from our day jobs just paying for text messages and the numbers were rising rapidly. Raising funding was absolutely critical. Several of the bigger VCs were already in India back then, and we pitched to all of them, but for better or worse, failed to raise money. A year passed in this manner, with the service limping along. By mid-2008, we'd decided that we were going to pour our combined life savings of about five lakhs (INR 500,000) into the business in a last ditch attempt to save it.

One month later, my mother was diagnosed with a leiomyosarcoma. After that, there was no question of spending my savings - every paisa had to be saved against the possibility of our life insurance cover running out. For twelve months I hoarded money and liquidated all my investments against a rainy day. Then, through sheer good fortune, my father's forty year career in public sector insurance paid off - a new government scheme was approved which allowed retired senior executives and their families nearly infinite health cover. We could finally afford to have my mother stay in a bigger, better hospital room when she went in for her chemo. Our personal financial situation no longer impacted her treatment. My relief was immense, but it would be another six months before I even thought about starting up again.

I tell this story only to illustrate out what is perhaps obvious: That life is uncertain and when things go wrong, entrepreneurs running bootstrapped businesses are often forced to choose between loved ones and their venture, mostly for financial reasons.

2012

So on to the present, twenty five years after I moved to Bangalore. The top Indian outsourced services firms have all exceeded 100,000 employees. The total number of truly successful Indian internet startups is under ten, and every single one of them replicates a validated business model imported from the first world. Funding is easier to come by, but Bangalore is still an arid desert when compared with the Valley. Basically, the Indian tech startup ecosystem is still a tiny tiny thing in much need of nurturing.

From an economic perspective, salaries are rising at 15% annually, with most college grads starting at one of the big services companies with around 3 lakh rupees a year (or 6000 dollars at the current exchange rate). Most mechanical engineering, civil engineering, industrial engineering and chemical engineering graduates wind up at one of the large services firms where they learn to how to write software. Their engineering degrees are largely wasted; the more driven among them embrace this reality and do an MBA in a year or two and stop writing code in favour of a career in management.

CS grads that are above average start work at about five lakhs a year, and the really good ones can start with ten lakhs or more, though there are just a handful of openings at this salary level. Salaries for roles that require serious programming skills are going through the roof, but it's still incredibly hard sifting through the chaff to find people qualified for the role. Amazon, Zynga and other product companies that have development arms in Bangalore still find talent inexpensive relative to the six figure salaries they pay in the US and are happy to pay very very well, especially in contrast with the large services firms. Most capable programmers now naturally gravitate toward established product firms, where it's not unusual for someone with five years of experience to earn twenty lakhs a year (40,000 dollars at current conversion rates). You'll notice that while the India-US PPP ratio is 1:5, software salaries are actually at about 1:3.

No virtuous circle

This now brings me back to the title of this post, the "virtuous circle." In the valley, failing at a startup for the right reasons earns respect and makes people take you more seriously. It also makes it more likely that you'll raise funding in the future. Failure benefits you in visible ways, creating a positive feedback loop that works to increase your opportunities. In the valley, you're surrounded by people that made serious money by founding or working at startups. It's obviously a viable way to earn a living; sure, starting a Facebook or a Google is like winning the lottery, but even without you can earn a very respectable income from your salary and stock options. Startup meet-ups happen every other week, with a hundred people or more in attendance at every one.

In contrast, I don't know anybody in my personal network in Bangalore that's made significant money from a tech startup. I know of a handful of people, but have never met them. Start up meetings are rare, with a handful of people showing up. Most of the time in the meeting is spent bike-shedding. If you're lucky, you'll meet one person running their own business at such a meeting - the rest are all aspiring entrepreneurs.

Negative feedback loops

In India, failing at a startup means you go back to a regular day job for a couple of years to refill your bank account. Your failures create no additional value, because the learning from them aren't useful to the current ecosystem. You'll certainly get a regular job based off past experience, but don't expect the fact that you started a company to count for much. We don't have two generations of successful technology entrepreneurs ready to give a leg up to the current crop by mentoring them. We don't have the early stage investment ecosystem to infuse money into promising businesses. Most fundamentally, we don't have a society that values risk takers, because in an economy like India's, risk takers crash and burn and may well take their families with them. Everyone, from your parents to your siblings to your in-laws will call you crazy for giving up that cushy job at a top product firm. And you know what? They're likely right.

Here, doing a product startup only makes financial sense if you're in your early twenties, intend to remain single or have a substantial inheritance. As you get older, you absolutely need a steady, significant income because unlike the first world, you're paying for your kids education from the age of three and up. You're likely to also be supporting your parents by the time you're is your early forties. Education and healthcare are, as I'm sure you know, expensive.

This means that you have a narrow window early on to successfully do a product start up. Missing that window means the realities of life will force you into a regular job. Even if you tenaciously hang on, you're doing so knowing that you're forcing your family to compromise on their lifestyle to allow you to pursue your dreams.

Added to this is social pressure from older generations, many of whom lived through the Licence Raj and struggled to find any job, leave alone start something of their own. As a friend of mine pointed out so succinctly, unless you're fabulously, visibly successful, you're always the chap running that "computer angadi" ("computer shop" in Kannada). To most of our grandparents and parents, quitting a steady job is tantamount to social and financial suicide.

Quitting a steady job at a big-brand firm to join a smaller company is not as bad, because, you know, you're still an employee (which is a good thing), but they'll still call you stupid for giving up the brand. "Your son didn't get job in Infosys-aa?" was a question my mother had to field from all quarters when I joined first started working.

Doing it right means playing safe

In India, the deck is both socially and economically stacked against the entrepreneur. The question, then, is how do we change the odds and make life a little easier for ourselves?

Let me start by outlining the constraints that we need to satisfy:
1) You need market-equivalent income to support those who depend on you.
2) Your business needs to be stable so you're better able to hire.
3) Your business needs to be very profitable so you can pay well, because you're looking to hire top talent, you're competing with Amazon and Zynga, not Infosys.

You'll notice that there's a conflict inherent in (2) and (3). Stable business models grow slowly and usually aren't very profitable. Since you clearly can't do both, you need to pick one. Most entrepreneurs in Silicon valley shoot for (3) and trust in their ability to raise money and bring in senior advisors to introduce some stability. We don't have that luxury, so we need to shoot for (2) first, and then figure out (3).

Satisfying these three constraints led us to the business model that C42 Engineering currently follows. Here's our reasoning:
1) We solved the market equivalent income problem by starting out as a boutique Ruby consultancy. We get good rates, which means we can pay fairly well.
2) A services business run right is very stable and predictable. It is also an excellent source of challenging engineering projects, making it even more attractive to programmers which in turn makes it easier to hire.
3) Channel 100% of services profits into a product arm with multiple products if possible. Iterate. Fail fast. Ship. Rinse. Repeat.

C42 Labs, our product arm that was responsible for RubyMonk, has an annual budget of 60,000 dollars, a sum we're likely to double in the coming year. This is about 4.5 times my annual salary when I quit to start C42 Engineering two years ago, so it's clearly an improvement over my ability to fund such a project back then. It may not be much when compared to the millions that startups in the Valley routinely raise, but it's a solid, dependable sum produced in a sustainable manner. We're also creating a brilliant team of engineers in the process of growing the consulting business and are getting to work on some amazing projects for  interesting, successful companies in the process.

We have big dreams for RubyMonk and the learning space. The ultimate goal of the Young Lady's Illustrated Primer beckons. But the best ideas sometimes fail, and if, to our ill fortune RubyMonk is one of them, we'll still be back at work on the next business plan in our pipeline the very next day. No downtime, no salary cuts, no layoffs, no bad mojo.

Conclusion

If you've been involved in the Bangalore start up scene, you know that services start-ups are often looked down upon as being "impure." When I was a working on Activ Mobs, I too was of this opinion and strongly felt I'd never like to do a services business. This harsh perception is driven by the fact that many product startups start doing a little consulting on the side to ease cashflow and before you know it, they've become full fledged services firms. The comfort that a steady stream of revenue offers is extremely attractive after you've scrimped and compromised for a couple of years. There's a second, more valid reason for such critical view of services - every new business you add will dilute your focus. When you have both consulting and product, you focus is halved. This is a risk any diversified business faces, and frankly, there's no good answer to this besides "be more disciplined."

What I do have to say is this: Deal with the risk. Define it. Work it into your business model. The solution to a paucity of early stage funding and expensive talent isn't hoping that things will get better, and that your business will survive until then. Figure out how to make a small amount of money early, and in a reliable manner. Then re-invest and diversify. You'll grow more slowly and take longer to become massively successful, but you're now much more likely to make it to the end of the road.

Don't worry about local "wisdom" -  just do the sensible thing. This could mean you start with consulting like us, or simply bootstrapping in you spare time like my friend Akshat's doing until you get to sustainable revenue, then quit to run the business full time.

But whatever happens, don't let the naysayers stop you from starting up. Just remember that you must be pragmatic about how you go about it, because even though we wish it were more similar, Bangalore isn't quite Silicon Valley yet.

---

If you liked this post, you could

subscribe to the feed

Follow @ponnappa

join the conversation on HackerStreet

or simply comment on this post

On building companies, open spaces and with a little pairing on the side

Here are two longish emails that I should have converted into blog posts. I'm lazy, though.

Whatever. Here they are.

Switching from a solo contractor to being a development company (full thread)

Luke,

> I like doing a range of stuff, for example managing client
So is it fair to say you enjoy managing entire projects, and that this
is what is motivating you to consider starting a company?

If yes, then here are a few thoughts off the top of my head.

Why start a company:
* You should figure out goals for your business; remember, a business
is best run based on a set of principles rather than on implementation
details. The implementations (and consequently the role you play as a
founder) change based on market situations, but principles will remain
broadly constant. What you've outlined in your response is what *you*
want to do; as someone already pointed out on this thread, as a
business owner, you'll find yourself having little to do with the
execution of projects once you grow even a little bit. Pre-sales,
sales, strategy, recruting, client satisfaction and employee
satisfaction will take up *all* your time. Hacking open source is
something I now do over weekends as a hobby. That's just how it is.

* Define success criteria. "I know my company is successful when foo
happens in a regular and measurable manner." If you don't define
success criteria, you won't know if your business is stagnating.

* You didn't mention making more money than you are now as a goal.
Even if your business isn't about increasing your income, it still
needs to be sustainable. This means that you *have* to set revenue and
profitability targets for the business, or you will stagnate quickly.
Stagnant businesses find it very hard to survive in poor economic
conditions.

* Try to play the devil's advocate; question your every motive and
decision, and come up with alternatives that provide the same outcome
without starting a business. Evaluate each of those alternatives very
honestly, because, maybe they're actually a better fit - starting a
business is a risky proposition. And if they don't, they'll help you
understand your own motivations better, which in turn will help you
understand the principles around which you want to build your company.

Sales:
* Start small, use sources that build trust like odesk and elance -
treat them as your marketing arm. The 6% to 10% you pay them is your
marketing budget.

* Your next objective should be to get *off* these sites as quickly as
possible. That way, you force yourself to do branding, positioning and
marketing, channeling that same budget toward these activities.

* How you do your marketing is a function of whom you're selling to.
How big are your clients? How much revenue do they make? Whom do you
speak to in their hierarchy - the founder/CEO, middle management, or
engineering? All of these questions will help you determine how you
present yourself and your company to them. To some prospective
clients, you'll be the experienced engineer who happens to run a
company. To others, maybe you need to be the CEO of a consultancy.
However it plays out, market segmentation is absolutely critical.

* Identify sales channels. IRC, mailing lists, meetup groups,
conferences, hoardings, TV ads - it all depends on what your budget is
and which market segment you're targetting.

* You can't be good at everything. Understand and accept that the
moment you start a company, you are a manager, and a good manager
knows when he/she needs help. Don't hesitate to hire people to fill
roles that you're no good at yourself (remember the 10k hour rule -
you just don't have the time to become good at everything). So long as
these people increase revenue and profits, you're fine. In my
experience, one or more trusted, competent co-founders who complement
your skills can make a world of difference (and make your life less
stressful).

Miscellaneous:
* Services revenue is a function of hourly rates * no of hours worked.
There are two ways to succeed at this in a financial sense - the
McKinsey model, and the Infosys model. One increases rates, the other
increases the number of hours by hiring large numbers of people. Be
clear about which model you want to apply to your company. If you do
neither, your profits will suffer, even though you may have
significant revenue.

* The McKinsey model will force you to push rates up steadily, and
also to hire increasingly better talent. Branding your business to
increase rates and recruiting top talent are the core problems to be
solved.

* The Infosys model will force you to hire more people. Maintaining
acceptable quality while keeping rates low, and recruiting sufficient
people are the core problems to be solved.

* Build up a cash buffer. Services sales (well, all sales :)) are
cyclic and if you hit a slump, it will hurt. In the beginning, hedge
by hiring contractors until you've got (say) three months salary in
the bank. Then start hiring employees. Remember, you can't do enough
to keep the people who work with you happy. Step one is them knowing
that their salaries are not constantly at risk.

* Study. There are three lines of work that (off the top of my head) I
can think of that require constant study and reflection - medicine,
programming and business. You don't have to get an MBA, but you do
need to have a steady stream of books that you read and people that
you learn from. The bare minimum I would recommend is getting a
subscription to 'The Economist' and reading it religiously every week.
Try to also find semi-formal or formal advisors with industry
experience that you meet with (say) once a month to review your
business.

Phew. Long post. I think that's a fair distillation of what we've
learned building our business over the last couple of years. Feel free
to ask questions if you want me to drill down into anything in greater
detail. I'm happy to also cite practical examples if it would help.

Regards,
Sidu.
http://c42.in
http://rubymonk.com

Some thoughts on open plan areas (full thread)

I've worked in open spaces for about seven years now across several
different physical offices with different layouts, pair programming
the entire time. Based on conversations with my colleagues that shared
the same environments, it's obvious that different people responded
*very* differently to the same setting. Also, I'm going to address
pair programming separately, as workspaces and pairing are orthogonal
and their effects shouldn't be conflated. Finally, these are my
experiences, so YMMV.

1) Large open space containing 120+ people - very hard for me to work
due to background noise, constant distractions, almost never zoned in

2) Large open space containing ~20 people - brilliant, I loved all the
space, and other teams were far enough away that background noise was
negligible, yet they were clearly in line of sight so when I wanted to
ask a question, I could see if they were free and wander over. One of
my best experiences.

3) Large open space containing about 80+ people - this was the same
space as in (1) but with fewer people in it and with our team being
off in a corner; it worked better than in (1) but not as well as (2)

4) Connected open spaces, each containing a team of 2 to 4 people -
this I think worked moderately well; the lack of LOS raised thresholds
to communication, but the background noise problems and constant
interruptions by other colleagues was reduced

Extrapolating from these, I'd say what worked best was a large enough
open space that folks didn't disturb each other, but still had LOS and
easy access. Second best is a set of connected, smaller, open spaces,
one each to a team (assuming of course that your teams are one to
three pairs).

> Indeed, a lot of old research from MS showed that when coders have private
> offices, they are 2X as productive (yeah, %100 increase)
I think we make sweeping generalisations a little too easily. Writing
Windows code is not the same as writing a web app is not the same as
writing COBOL on a mainframe. Also, perhaps if those MS programmers
TDDed their code, they wouldn't have to hold so much of it in their
heads all the time, making intense concentration less necessary and
reducing defects, making them more collaborative, resulting in a
better shared understanding of the codebase and reduced truck-factor,
resulting in better software and happier engineers. Who knows, right?
Software engineering is a complex subject and I'd be wary of any *one*
factor being touted as a productivity silver-bullet. Ultimately, it
depends on the project and the people.

Now on to pairing. Writing software alone is a completely different
thing from writing software in a team. If you work in a
self-organizing team, then it is important to realise the impact of
your social relationships on your productivity because team
productivity is everyone's problem, not some manager's. Pair
programming just increases the importance of recognising the social
aspects of software engineering. The objective is to be able to zone
in with your pair, and you do whatever suits (and this is likely going
to change with *every* person you pair with). I know pairs that shared
an iPod, that moved to a meeting room or balcony so they had less
distractions, that were heads down churning out code in the middle of
the floor oblivious to all the noise around them...

Basically, getting pair programming to work has nothing to do with
open spaces and has everything to do with you and your pair
understanding one-another's work style. And yes, it's ok to accept
that there are some people you can never pair with because you just
don't get along. It's also ok to accept that you're extremely
introverted and are only comfortable pair-programming with people
you've been friends with for years. I used to be extremely introverted
(starting two companies changed that) but it's important to remember
that team *productivity* is the goal, not pair programming, open
spaces or whatever else. These are just mechanics that facilitate
productivity, and like anything else are subject to the 80/20 (or
50/50 or 20/40) rule.

Best,
Sidu Ponnappa.
http://c42.in
http://rubymonk.com

C42 Engineering, Year One.

We've come a long way since that evening in December 2009 when a handful of colleagues spent an evening drinking Highland Park and trying to figure out what they should be doing with their lives. Everyone wanted to do a start-up; nobody had any big ideas. We also knew that raising money for a product startup in India is quite hard at the best of times, so we figured we'd do this by the book - start and grow a nice, stable services firm and bounce off it to build a product division. We'd take more time to get there, but we were less likely to crash and burn because we couldn't raise funding.

At that point, only two members of the group were actually in a position to do something about it and they took the first, difficult step of quitting a comfortable job and trying their hands at something they'd never done before - setting up a boutique Ruby consulting firm, offshore.

By early January both Srushti and Niranjan had quit ThoughtWorks and begun actively studying the market. Of the others, most returned to their usual routine; I was the exception. Starting January 1st, I was on unpaid leave to look after my mother who was in the last stages of her battle with soft-tissue sarcoma, a virulent form of cancer. I stayed on as a nominal ThoughtWorker because I was still peripherally involved in organizing the first edition of RubyConf India which was scheduled for late March that year.

Thus began what I later realised were the toughest six months of my life thus far. My mother was in and out of hospital for most of that period, and January was especially trying because my father over-extended himself on a trip and wound up briefly in hospital too. I had a fair idea what Niranjan and Srushti were up to with the company as they were at this point working out of my aunt's house, which is on the floor just below my own. My family'd been using it as a store-room for the ten years since my aunt passed away, and boy was it a mess. I'd make it a point to drop in for a few minutes every day and hang out with them among all the old newspapers, furniture and dust to see what was going on. They'd usually be sitting at the dining table on some truly ancient chairs hacking code, or as likely, playing World of Warcraft. We'd talk for a bit - if it was a Friday or weekend I'd bring my laptop down and we'd all three of us do a raid or three.

By late January they'd managed to sign up a client on a fixed-bid Rails project. Four weeks later when they did the numbers, they realised that their hourly billing rate hovered somewhere between $3 and $5. Lesson learned, they then started bidding only on projects that paid by the hour and soon signed up a client at $15 per hour that would stay with them for the next six months. C42 Engineering had found it's first 'boulder' - a steady, long-term project that the company could depend on.

With the end of March came RubyConf India, and a few days later I quit ThoughtWorks. March was also notable because during RubyConf we met Niranjan's childhood friend Aakash and shortly thereafter he decided to move to Bangalore and join Niranjan and Srushti. Thus, when I joined C42 Engineering at the end of April after serving my notice period, I was the fourth person to sign up.

My first act after joining was to take a leave of absence that was to last two months. I stayed home looking after my mother and C42 Engineering moved on without much involvement on my part and signed up another client for an engagement that lasted three months. At this point we had two projects and had two people billable full time, but we hadn't yet registered a company and weren't even paying salaries yet. Niranjan and Srushti were effectively working as independent contractors, with Aakash shadowing first one, then the other. I saw little of them in this period - both Niranjan and Srushti were working on separate projects, and by the end of May C42 had moved out of my aunt's place and had started working out of a room at Srushti's dad's office in Cooke Town (less dust and better power backup).

My mother passed away on June 11th 2010, just under two years after she was diagnosed with cancer; I started work at C42 full time shortly thereafter.

Things started heating up at around the same time. First off, we registered the company. We then proceeded to execute two key parts of our strategy for that year. First, we started billing in pairs instead of as individuals and second, we moved away from sourcing projects via online brokerages like elance.com and started generating leads and selling projects ourselves. Shortly thereafter we started hiring, and over the next five months had four people join us. We had a second pair become billable, then our third. Ultimately, the last quarter of 2010 generated more revenue than the first three combined, and this despite December having terrible utilization numbers because we were all off in Goa watching Nigel get married.

The other event of note in 2010 was Niranjan's and my talk being accepted for RubyConf X, New Orleans. This was a calculated risk on our part because the cost of the trip was non-trivial for a business as young as ours was, and we weren't sure if there would be any immediate returns we'd have in terms of projects (or even leads). In hindsight, however, I realise that these were relatively unimportant things. What speaking at RubyConf X really brought us was a degree of credibility, something that you otherwise earn the hard way over a period of months; once the video of our talk went online, there was a noticeable change in quality of our leads. Sales didn't necessarily go up, but conversations with prospective clients that had already watched the video had a much more positive tone.

Things have been pretty upbeat since then - we remain sold out more or less all the time, our rates have steadily risen to the current USD40 per hour per developer. Our open source initiatives have seen considerable progress - we added RFC 2616 compliant caching to Wrest, saw a remarkable number of pull-requests on Goldberg, and contributed any_instance support to RSpec.

If I had to highlight a key learning from all that we've learned in the last year, it would be that executing consistently is tough because the way you need to evaluate your priorities changes as your revenue grows. Three guys hacking in a room and eight people working as a part of a business are two fundamentally different kinds of organisations that behave very differently. It seems like this should be obvious and not a 'key learning', but we were blind-sided by how far reaching its impact was on the way we worked and how hard it was for us to start thinking differently. I've read about this kind of stair stepping where a $10k business works differently from a $100k business which in turn is different from a $1000k business and so on, but seeing it happen has been... educational. Tracking time accurately, invoicing your clients correctly and on time, making payroll on time - these things seem simple on paper, but are quite hard to do consistently in practice.

There are plenty of things that we're still struggling with and don't have good answers for. Scaling people up technically is one - we're heavily dependent on pairing for our training, which means we can at any point only hire as many people as we have experienced Ruby developers in the company. Developing skills to the point that we consider acceptable takes months, and then more months until that person is at the point where they can in turn mentor someone else. We're still trying to figure out if there is a way to train people in a shorter duration without compromising on quality, but for now we're cutting back on growth to maintain quality.

In conclusion, I think we've been very lucky in some ways this last year. A boutique, offshore Ruby consultancy would have been much harder to establish if we'd started a little earlier, or if we'd tried to do so without a core team of experienced Rubyists; we've been in the right place at the right time with the right people on board and we've benefitted enormously from this. Now we have to work on the real challenge, which is creating a successful product division while continuing to grow our services arm. I'll try to make it a point to keep posting updates - at this point, I suspect we'd definitely benefit from any advice we can get.