I have been actively hiring people for my new gig at Bitzer Mobile. We are trying to rope smart engineers to join our Bangalore office with expertise in C/C++, Java, PHP, Android, iOS with varied years of experience. Here are some observations as experienced in the last 30 days.

1. Imperfect job boards. I wrote about this last year. Job boards are broken, monopolistic and owned by recruiters and mass e-mailers. They are good for bean counting your overall candidate flow with most of them a wrong match.
2. No separate board for freelancers and short-term opportunities. Unlike US-based Dice, there are none in India in the forefront. This is partly because of our Indian mindset of job security. However, Hasgeek’s job board has an opportunity.
3. Compensation disparity. The compensation range swings ultra-wide. For a PHP developer with 3 years experience it could range from INR 3L – 9L
4. Recruiters hold the fort. A good number of candidates swirl around recruiters. The main reason is the failure of the boards to land them a gig directly.
5. Expected compensation is also mind-boggling. Candidates look for anywhere between 35% – 80% jump from their current compensation.
6. Immature technology. The matching of requirements and resume is pure art. Even after 20 years there are few tools which integrate well with boards, do application tracking, give a relevance score of matching, etc. There are some high-end tools but they are prohibitively priced. I use recruiterbox for applicant tracking and I love it. But it does not integrate with LinkedIn, google calendar, skype, etc.
7. Filtering candidates. I have been using interviewstreet for giving MCQ and programming questions to candidates. A few “good” candidates have indicated that they are not interested in taking the online tests. Knowing that resumes are always “dressed up”, it’s impossible to call and do a 45-minute verbal test and hear the answers. I would love to pay someone to administer these tests by calling the candidates and asking multiple choice and general non-programming questions to do a filter. Latent applicants would never take the test.
8. Almost all entrepreneurs are good candidates. This is a dichotomy in my mind. Thanks to my previous life as an investor with The Morpheus and a developed empathy for entrepreneurs. Realized this recently when I called up 2 such candidates immediately after seeing their application and their LinkedIn profile. I bypassed the usual process of screen-resumes / online-test / phone-call / face-to-face. Entrepreneurs are good problem solvers, but they may not be a good fit. This is highly debatable and my recent sample set is only 2.
9. Logistics. It’s impossible to get a candidate for a face-to-face during the weekday. Multiple candidates have cited varied reasons ranging from ‘far-away’ to ‘can’t get-away-from-my-desk-as-my-TL-is-watching’.
10. There is no craigslist-like board for startups. Nor there are any mailing lists, nor there are any startup hiring mixers. I would suggest that Open Coffee Club/Headstart should kick-start a joint mailing list for startups to post jobs. Reminds me how successful KIT-list was during the post-dot-com era.

And yeah, we’re hiring.

–

The picture is of a candidate from a lathi-charge scene at an event for police hiring for multiple openings. The jobs are almost never advertised and given to cronies. Depicts the irony of India’s roaring growth and the depth of imperfection in India’s job market.

In an effort to rationalize, tweeted the title of this post and bang came some great replies:

@brij said:

@1ndus you are on the crease. playing. that’s usually enough. Take a proper stance and cover your assets with a nice AD guard!

Another one by @zenx:

@1ndus Test match hai dude. Think sessions, not overs, even as you capitalize on the loose deliveries!

Finally, @riteshagar suggested:

@1ndus Simple think. Do as @sachin_rt does. Care only for the next ball; not for overs, innings or sessions !

There is a shift happening, although the day dreams of creating an 800-pound gorilla still persist, but the execution has become very pragmatic. This recent Techcrunch post by @petersims further nails it:

Don’t Bet Big. Little Bets Are The Ones That Turn Into Billion-Dollar Ideas

RIP, Sixer in every over. Welcome, six runs on six well-played balls.

In a high-technology startup, an entrepreneur looks at a series of trends or observable phenomena, as scientists calls it. The trends give you a certain set of assumptions. Based on the assumptions you run multiple controlled experiments.

Something similar happened to me in just around summer last year. I developed this belief, “If there are 300m youngsters on facebook, then they would look for jobs within the boundaries of facebook.” A hypothesis was born.

How do I prove it? Not easy, without having a full blown product with a good user-interface. A step in proving the hypothesis is figuring out the variables in the controlled experiment, that first variable for me was validation from a small group. Facebook Dev Garage, Bangalore chapter happened in October and I presented at the event (Thx, Vijay). A scrappy prototype cooked with 2-3 days of effort over Facebook API and Amazon S3 was well received in a crowd of 140+.

Then things took back seat and the hypothesis was semi-forgotten; The Morpheus Batch 5, broken laptop, sickness, family chores, visitation from extended family, yada-yada. Then the year-end downtime happened, I wrote a blog post and restarted the experiment and whipped the code out from woodwork. After several weeks of intermittent coding, last week, I quietly released the consumer facing version to check the reception of the antenna. Then I got a resume. One experiment was over.

Tonight, I incrementally rolled out an alpha version and started another experiment. It is still very brittle, has a simple user-interface, but is set out to run that experiment to prove the larger hypothesis.

The Pinta & The Nina were the two ships (out of three) used by Christopher Columbus in it’s first voyage across the Atlantic Ocean in 1492. The replicas are shown in the pic above. Picture courtesy Christopher Columbus foundation.

• Market opportunity – a million dollars isn’t a lot in the grand scheme of things, but it certainly is a lot if the market opportunity is not large enough. Even if you put Bill Gates and Steve Jobs as founders in a new venture with a total market size of 10 million, there is no way they could become too wealthy without completely changing the business
• Inequality of information – find a place where you know something that many undervalue. Having this inequality of information can give you, your first piece of leverage
• Leverage skills you know- You can go into new fields such as say Finance, but make sure you’re leveraging something you already know such as technology and/or product.
• Look in obscure places- We’re often fascinated with the shiny things in the internet industry. Many overlook the obscure and unsexy. Don’t make that mistake. If your goal has primarily monetary motivations, look at the unsexy.
• Surround yourself with smart people- smart people whom are successful usually got there by doing the same and have an innate desire to help those do the same.
• Charge for something- Building a consumer property dependent upon advertising has easily made many millionaires, but it isn’t the surest path. Build something that you can charge for.
• Go with your gut and do not care about fameballing- Go with what your gut says, regardless of how it might look to the rest of the world.
• Be an unrelenting machine- Brick walls are there to show you how bad you want something. Commit to your goals and do not waver from them a one bit regardless of what else is there. I took this approach to losing weight and fitness. I have not missed a single 5k run in over a year. It did not matter if I had not slept for two days, traveling across the country, or whatever else. If your goals is to become a millionaire, you need to be an unrelenting machine that does not let emotions make you give up / stop. You either get it done with 100% commitment or you don’t. Be a machine.
• If it’s a “trend”, it’s too late
• Be a master of information- Many think it might be wasteful that I spent so much time on newsyc or read so many tech information sites. It’s not, it’s what gives me an edge. I feel engulfed.
• Get out and be social- Even if you’re an introvert, being around people will give you energy.

When I first saw the cover (probably in my 8th grade) of Jimi Hendrix’s album ‘Axis: Bold as love’, I was like WTF, how can he do it to the deities? Hendrix is depicted as two Vedic deities, with the multiple hands of Durga and as avatars of Vishnu.

As a startup entrepreneur one has to embody multiple incarnations in one single lifeycle and that pic above is very relevant. What the commenter mentioned above is a lot of things to be done in a short span, but yeah, not every startup gets there, unless you have multiple hands and heads.

Only in last few years, Indian Small & Medium Business (SMB or MSME), have started doing a few of the following:

• Going online & and maybe having a website
• Accepting card-based transactions
• Implementing a cross-office/cross-vendor supply chain or some other rudimentary automation for sales/marketing or customer service
• Using collaboration tools for inter-company, intra-office communication & data sharing

These are the businesses who have been using a desktop/PC for the last so many years and may have been using 1 or many windows-based applications for accounting, billing, point-of-sale automation, connecting to branch-office over private network, etc.

There is a impending run up in the growth numbers of the SMB sector in India. In the concluded budget speech, the Finance Minister doled out sops for the fledgling sector including the government’s plan to purchase Rs. 1,60,000 crore worth goods from SMBs in 2010-11, which is 400% up from the last year’s paltry Rs. 40,000 crore. Comparing this to the developed nations the number is less than 10% of all the purchases and the balance lies in the favor of large enterprises. Due to the growth in this sector, the SMBs share in the India’s GDP is pegged at 10% in the closed financial year.

Based on research estimates, the overall IT spend is being pegged at USD $4.5 billion of which IT security spend would be at $450 million (Rs. 1900 crore); 10% of the overall IT budget.  The Indian IT security spend was around Rs. 210 crore in 2006-07 and would surge to a healthy Rs. 1900 crore as stated above. The gut feel is that the spend would be higher than 10% of the overall IT budget due to investments in fundamental infrastructure, consulting, software etc.  for the first time.

From a textile unit in Tirupur, to a manufacturer of automotive accessory in Jamshedpur, to a mini-steel plant in Jharkhand clocking Rs. 5 crore in annual sales; in five years from now, there’ll be easily 20 million businesses that will be using IT as part of their every day life. This all seems to come together.

Sensing the opportunity – IBM, Microsoft, Sun and even desi stalwarts like TCS, Wipro have started focusing on the young but growing segment. IBM predicts that 30% of it’s revenue would be from Indian SMB segment in the next 5 years.

I think the opportunities to innovate & produce products which can be efficiently priced is huge & can be summarized as:

1. Preventive — customer’s data leakage/theft,  end-point protection of desktop/servers, backup of data on desktop/servers, anti-fraud by customers/employees, etc.
2. Curative — threat removal, recovery/restoration, essentially tools used when preventive measures have not been taken or failed
3. Consultative — audit of practices, compliance to regulatory framework related to privacy/card-transactions, risk assessment

It can be argued that a lot of work has been done and the market is mature with products from established companies. However, these products are not suited for small business who is just starting out with it’s IT presence. Apart from the pricing which is ill-suited, the overall total cost of ownership is very high, considering that the businesses aren’t IT savvy. More than that, a lot of them have a feature load due to maturity of their life-cycles.

There are only a handful of startups in Indian segment who are working on products related to IT security, and this is a green field as I see.

A lot of ventures start with a dream, a vision; to solve a problem in a specific way. The dream could be a INR 100 crore product or something as complex as an ERP on the web to a even more complicated, a Hospital Information Systems (.. search engines? they are easier to build these days).

The vision cannot be achieved in 6 months or even 2 years — Takes 5-7 years on an average to build an INR 100 crore company. So you want to start now, and want to start small, chiseling your idea, refining as you go, adding feathers in your cap and changing gears and accelerating as you move.

First, zero in on a handful of customers and a specific problem the customer may have. Do not worry if others mock you for building a feature & not a product. You know your destiny. You know where you want to reach. Validate what you have built. Give the customer something useful so that he can pay for what you have built. Iterate on your product.

There are a lot of examples where the companies started small and began by solving just one small problem and then morphed into gorillas; from companies selling PCs — to cloth merchants now with fully backward integrated perto-products chain.

A large amount of money spoils you, ties you up with your own experiments and forces you to deliver a product which does not have any takers outside your laboratory — You are forced to linger with the experiment because now you have a large amount of an external investor’s money and do not have guts to tell him that it is not working out. There are numerous examples. There are only a few brave entrepreneurs who took $5m only to tell the board in less than a month about change in the business model.

When you are starting out, you are building something and proving your hypothesis. The moment someone starts paying for what you are building, a part of the hypothesis gets proved. You continue to iterate.

Think 6 months, 3 people’s expenses.

Think 6 months, 2 people’s expenses.

Think the amount of first tranche you need to deliver to your first customer.

Think about knowing the sales process yourself before hiring a sales expert.

Think doing zero dollar marketing before doing SEM campaigns.

Think writing the code yourself before hiring a developer.

… start thinking about raising big money after your customer trusts you with his money.

(The thumbnail is of a Ruby-throated hummingbird. These are solitary. Have one of the highest metabolism, and as part of their migration, they fly non-stop across the Gulf of Mexico, a distance of at least 500 miles. Pic courtesy)

Kabirdas-ji says:

तारा मंडल वैसि करि, चंद बड़ाई खाई |

उदए भया जब सूर का, स्यूं तारां छिपि जाई ||

Shall update with the translation sometime later. Why don’t you attempt translating this in the comment section?

Lamp Growth Plan

The visual image conveys the thoughts. The data legends represent a hypothetical configuration using Webservers, Database Master and/or slave or DRBD, Memcached nodes, etc. The size of the circle represents the relative amount of money spent on monthly hardware lease.

How did your web presence grow?

Disclaimer: The above does not include security, disaster recovery, backup and other attachments which are a must.

In my previous stints managing pieces of technology including developers, code base, release cycles, etc. — I was always hunting for tips for better sleep management. Huh, the solution was in managing the technology effectively to get a better sleep.

Here are some of them compiled (some learned after reflecting on mistakes!)

1. Build Now. Scale later. More often than not we worry about whether this piece of code or even this atomic function will scale or not. Once I was writing a small function to convert time into the now famous “10 minutes/days/years ago” format.  I took the whole fraggin’ day on it. Back in my mind I was trying to optimize a small calendar look up which probably optimized the code by 10 ms for every HTTP request. Big deal — but totally stupid.  Essence: Build what you can build. Do not spend more than 10% extra time worrying about scalability & performance. The objective is to get the customer first within acceptable limits of latency. Also, look at your strengths — if you are a developer never worked on high performance computing but know enough chops about writing good code, then just focus on that.
2. Release frequently, but not every day! The release early, release often is a myth which leads to disaster many-a-time in increasing code complexity, release cycles, etc. A good discipline is not more than one (yeah, 1) release every week (ideal is release every 2 weeks). Let the customers breathe, the QA breathe and stop wasting the time doing regression on the code. However, apply the exception to hot-fixes, security fixes and show-stopper bugs.
3. Prevent public bugs. Another myth of release early, release often is a conception that it is okay to have a few bugs on the code. Depends on what kind of bugs. Database connect failures? or weird on the face JS errors. Acceptable public bugs are those which are not seen by more than 10% of your customer base & depends on what stage of maturity your product is in. However, bugs when monetary transactions are taking place are a strict no. Another theory is that the number of public bugs is inversely proportional to the number of users.
4. Secure your web presence. This is getting complicated as the web matures & hacking is done using scripts instead of deep knowledge of software’s workings. In my previous stints managing technology, I thought & claimed to be ahead only to be humbled later with DDOS attacks. In my theory a 10 hour of Googling followed by 10-15 hours of fixing/implementing can take care of a good percentage of publicly known security holes.
5. Code Now. Refactor later. This is a personal anti-thesis which goes against the philosophy of designing beforehand; thinking through of the architecture, etc. Why? Startup resources are extremely limited. The objective is to show/deliver products. As a developer/technology manager you want to put your best efforts in delivering code rather worrying about the best possible way to develop a piece of code. However, it is okay to postpone some design issues (not the security ones) and revisit them after hitting some milestones. You don’t use the “refactor later” mantra to avoid the issue; instead being pragmatic about it. Also the exception should be conveyed to the team, the options available, a path chosen; with the reason that this does not become a habit within the organization.
6. Never outsource, but augment staff. The worst thing a startup could ever do is let someone else develop the technology and that too in someone else’s office! If you can’t hire full-time then hire contractors. Get them to sit with you, together. Have control and visibility.
7. Production release not tested here! Developers will always make an assumption that if it works on their laptop/private environments, it will always work on the production environment. Do not ignore that — Have a discipline of testing the code after deployment.
8. Automate everything, except your customer support. You want to automate/script as much as possible. Deployments directly from SVN, automated testing using various frameworks, log monitoring & alerting, server status, linting, database sizing, load, and every mundane tasks with actions like alerts etc. going to the team. However, you do not want to do an auto-reply to an incoming mail. OK to be slow by few hours but acknowledge/respond to each one of them. Put the startup resources to test.
9. Code all night, but release after noon. Simple. You want to do a production deployment when the hangover from a night of coding is gone. You want to start before the day is ready to end. Never deploy at 5pm or 8pm or early in the morning. Best time to make a release is at least 24 hours after the developers have said “it is ready to go!”
10. Secretly review a developers code. Highly effective. This is the best way to build opinions about a developers’ coding chops and get an edge in managing them. Find bugs in their codes, show it to them but never demean them publicly. All public code review in startups is actively discouraged.

If you can do the above well, then you can definitely sleep more using the 10 foolproof tips for better sleep management

Start with “Mine is a <insert product here like, finance, healthcare, etc> startup.” The only time you are a SaaS startup when you are solving a fundamental SaaS need like billing, metering, security, auditing, etc. It has become a fashion to use the latest technology to pitch your business and has been successful like, “We are <Java/Web2.0/SaaS/cloud/blah startup”.

Don’t move with fads.  India does not need fads.  India needs products.

The average consumer does not understand the technology stack. They need a solution. Whether the product uses cloud, SaaS, Java, Visual Basic — the consumer hardly cares. If it solves a need and must be on the internet then it does not matter whether it’s SaaS or BaaP or cloud.