Categories
Education Entrepreneurship

Are employment bonds really needed?

Does a company, be it a start-up or not, need to make their employee sign bonds that state that the employee has to serve the company for at least for a period of X years or will be penalized $Y?

I find them to be neither ethical nor legal or even enforceable in a country like India.

At INSORCE we have replaced the stick with a carrot and it is working great for us. So instead of saying you pay us $Y, we say, we pay you $Y as retention bonus. That, in my opinion, is a more positive way to start a relationship. This makes the person feel that the relationship is a business relationship among equals, and not a mai-baap relationship.

What’s your opinion on the same? Whether as a employer or an employee.

Categories
Entrepreneurship Technology

INSORCE Development Platform

INSORCE is built on a combination of technologies that are considered safe by bank’s for their data center, yet cutting edge to deliver performance that is superior to a desktop application.

We are building on Microsoft stack for 2 reasons

  1. Banks find it easy to deploy and manage
  2. Availability of competent professionals

The key parts of INSORCE are:

  • ASP.Net MVC, where the views are mostly returning JSON results.
  • SQL Server, old war horse, banks can easily manage.
  • Knockout, the browser side MVVM framework. This is what makes the app’s performance stand out.
  • Lucene.Net for search
  • SignalR for push notifications

Apart from this, it is a mix of:

Categories
Entrepreneurship Technology

Full Stack CTO Equation

Admin + Vendor Management + Accounts + Sys Admin + Customer Support + HR + Trainer + Product Manager + Project Manager + Architect + Full Stack Developer

= Full Stack CTO

Categories
Entrepreneurship Technology

What is Full Stack CTO?

It’s a log of my experiences being a technical co-founder at INSORCE. Its here that I realized that being a CTO at a start-up is much more than either the traditional role of a CTO or that of a full stack developer or lead programmer.

Therefore I coined the term Full Stack CTO to describe what the role entails.

A traditional CTO will focus on the defining, communicating and managing the execution of the technical strategy of the organisation. Whereas a start-up CTO has to deal with a lot more.

A sample of things I have done being a CTO.

  • Budgeting, building the team, setting up the office, vendor management
  • HR – Evangelizing, hiring, pay negotiations, appraisals, training, motivating the team, providing career growth and firing.
  • Laying out the company’s policies and processes.
  • Technology selection for the office – email, calendar, collaboration and other tools like source control, CI env., bug tracker, expense tracker and procurement
  • Defining the product architecture, selection of technology and coding
  • Working as a product manager
  • Product release and deployment strategy, customer contracts, service level agreements
  • Customer support – external and internal.

So in a start-up the role starts lot before the tech strategy is defined and is not limited to managing the execution, but taking a very hands on role in everything, from resourcing to customer support. Thus a start-up needs a full stack CTO.

The experiences I log here and the discussion made were in the context of my knowledge and INSORCE’s needs*. They may or may not have wide applicability. However I have tried to keep them as generic as possible to help fellow tech founders.

* INSORCE is into selling technology solution to the global financial institutions, whose needs are vastly different from startups in B2C or even a B2B for some other enterprises. The technology and processes selection at INSORCE reflect that.

Categories
Entrepreneurship

The art of achieving perfection

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

– Antoine de Saint-Exupery

The story of Maven is a journey towards perfection.

What started as common sense, slowly evolved into a way of doing things – the Artha Shastra way. The ad-hoc, piece meal approach gave way to a structured and systematic approach to problem-solving. This was step one of removing the cruft and starting on the path to perfection.

However, this methodology that was still so complex that people paid good money and spent valuable time to try and understand it. Here was the next step, to remove the complexity by using machines to do what they are good at and let humans use their intelligence to guide the machines towards the larger goal. Thus began the journey of Maven development.

The third step of simplification was to present non-linear, non-intuitive effects, which arguably mimic the butterfly effect, to appear simple and linear, more like the domino effect. Lots of late nights with the UX experts finally helped us achieve the same.

The fourth step was the development, or rather the lack of it. The discussion of what would remain in the product and what would be left out. It was more than a quest for a minimum viable product; it was to reduce the overall complexity of the product while being useful for a large set of use cases.

And we are currently in the final stages of achieving perfection. How do we communicate the benefits of Maven is a clear and concise manner. We can speak volumes about the goodness of Maven, but as always, perfection lies in taking away until there is nothing left to take away. And we are getting closer with every deleted word and rewritten sentence.

Stay tuned to know more about Maven and how it can help you achieve perfection in your service delivery.

Categories
Entrepreneurship Technology

How to build the unimaginable?

Get started…

Those were my thoughts when I took up the challenge of building Maven (then known as Project Andromeda).

There were so many reasons not to do it, unfinished and continuously evolving specs, unknown complexity, several dependencies, no development team in place, no clear target user, unproven market, extremely aggressive deadlines, fear of running out of money etc. But there was one important reason to do it: it hasn’t been done before.

Having decided that I want to do it, how do I go about it?

Well there is only one way to build software, to start building it. It cannot be done by sitting on the side-lines and waiting for things to fall into place before you begin. It needs a team to be built, need analysis, write specs, design, architect, code, test… and building Maven meant that we were doing all of these at once.

And then we celebrate…

The thrill of seeing the thoughts of several people in bytes and pixels is difficult to articulate. We know that we have just scratched the surface, and there is a ton of work to be done, but we also know that the journey ahead is much more manageable than what we have went through.

Why copy-cats don’t keep me up at night.

It takes a special type of environment to achieve something like this. You need people who are willing to suspend disbelief, embrace chaos, put their careers on the line and work with single minded focus to make it happen. Maven could not be built in an enterprise environment. It would take over 10 person-years to complete, and will be way behind what Maven would be by then. But to ensure that Maven is years ahead of competition, we cannot rest on what has been achieved and continue to innovate and create new benchmarks.