Sushrut Bidwai

Few times I have observed that people tend to barge into decision making process where there are not supposed to. One of such important domain in technology budget.

Agreed that startups will have tight budgets and have to optimize the budget. But that does not mean Mr CEO that you should decide who will call shots related to it. Just give your budget to CTO/VP Engineering and let him make calls. That is HIS job not yours.

There are numerous other reasons why such decision making powers should be given and later respected. One of the more important reason is that - Only a tech person will understand the continuous importance of having good programmers/developers in the team.

When a non-tech person starts making decisions which are related to technology like hiring of programmer, partnership with outsourcing vendor, then such decisions are more likely to go wrong. This person may not have understanding on cost of losing out relationship with a good programmer, development partner. As it is not his direct responsibility to deliver next release.

So all such decisions, communication should be always and always handled by a person who’s direct responsibilities and ability to deliver can be compromised.

Sure you are CEO of the company but that does not mean you are in charge or even capable of doing everything your company requires. So focus on things you are truly good at and let others take decisions and manage relationships in there focus areas.

Process, Startup CTO, decision making, Startup

I came across a post today and found it very useful from a lead developers stand point. One of the reasons why IT has come to become what it is today is - lot of “managers” or “decision-makers” still think of product development as classical engineering. IT is different. Growth of IT is dependent of productivity of people and not productivity of machines. Most of the other engineering disciplines are centered around making sure that machines are kept busy as much as possible so that manufacturing lines are optimally utilized. This does not hold true for IT.

Productivity of software development is directly proportional to productivity of people developing it under given process and technology environment. I am not saying Lisp, Haskell, Clojure, Python etc are the only way you can make people productive. Nope. But there should be balance between product you are developing, technologies used for them and processes designed for the same. But most important thing is - understand the people you have and structure your processes based on that. Or think about the processes you want to follow and hire people who fit into them. Technology may not be the silver bullet here. How you leverage people and processes might be, in my opinion.

Process Engineering, IT, Process

In last few months or so, I have had debates, diplomatic way to say I had fights, with fellow geeks about how to choose technology for a product. These parameters are not necessarily for startups, but in general. In the next post, I am going to write about how these parameters gives clear advantage to Java and GWT when it comes to Web applications.

Feature Set - 

   Most of the technologies, or the eco system around them, provide enough features to build any application. True, this wont be the case if you are developing an embedded application or application for space craft etc. But most of the enterprise, web application can be built using any of the technologies. Python, Ruby, Perl, Smalltalk, .Net, PHP, Java and Flex provide everything that is required to build an application. From language point of view, these technologies will differ significantly. Features they offer to developers and geeks are not considered. A true geek develops kick ass application, which creates wealth for the stake holders. I never believed that geeks who say “I wont work on a Windows machine”, are essentially good for the company and its success.  But bottom line is feature set is pretty much common in all the important technologies and no single technology is at advantage here.

Performance -

  Very selective call. If you are building a next SSN (Stupid Social Network ) then you will have to consider serving million users. If you are building a banking system, you will have to consider serving million transactions. If you are an Ajax heavy application, you will have to think of Javascript caching and issues it presents. Performance of the complex business algorithms is essential to the over all performance of the system. Can technology take advantage of multi-core CPUs? Does it support good distributed session management? Does it have strong security features? Can it scale? How big is the footprint of application? CPU Vs Database Vs Memory Vs Bandwidth tradeoffs. One of the most important thing in performance evaluation is, you cant generalize it. In my experience, the only theory which has hold true, is the last statement when it comes to performance evaluation.

   But again, Java obvisouly holds and edge over all other technology. Java deployed on a Linux machine with Sun RISC servers to back up, makes up the highest performance you can get. Although other technologies may not be that far behind. So for a reasonably high throughput requirement system, most of the technologies will provide you support to tune them and make sure you achieve your numbers. If you use Java, then you have to worry a little less about such tweaks that are available. One of the reason is, sheer number of high performing Java apps around and availability of quality Java performance consultation.

Maintainability -

  This is point I consider the most while choosing a technology. All other points does not give clear advantage to any particular technology. But maintainability of any particular technology is so inherent to the technology itself that this becomes a very important criteria for selecting it. A product has to be supported, enhanced, maintained for a long long period of time. Successful products tend to out live the creators. Technologies will change very fast. Product will have to adapt as per changes. Code written by you will need to be maintained by some other, may be less talented person. The code will under go lot of changes as time goes by. Does technologies you are choosing help you in keeping code maintainable? Does it provide clear constructs and architectural/design patterns which are self explanatory? Can you look at your own code written in that technology one year down the line, and explain it to some one else? Is data flow and control flow clearly depicted by the technology? 

Talent Acquisition -

   A product typically wont require more than few dozen people to develop. But as the product becomes successful, you are going to need 100s of developers to maintain it, support it, enhance it and keep it improving and delivering value to your customers. Can you acquire such talent which is required to maintain product you have developed using the technology you have chosen? I know a team of 4-5 python programmers who developed a product (not so good product) and when they wanted to expand their team to add few more programmers, it took them 8-9 months to find 2 programmers who fit the bill. If the product was developed using Java/.Net it would have taken less than 1 month, if the product would have been developed using Smalltalk, they never would have found those programmers. 

   But that does not mean you cant use other technologies at all. But you will have to know that, you cant rely on the outside to get you talent. In India, no recruiting agency will even understand how to shortlist Python or Smalltalk programmers! So you will have to come up with a contigency plan to cope up with situation. You will have to hire talent which is good in some other similar technology and train them. You will have to hire ahead of the curve and spend money on training. If you can do that, then you can choose such technologies, else not.

Distributed team work -

  Now lot of experienced folks are going to be pissed off with this, but these are my views from my experience. No matter which product you are building, how big or small it is, at some point in time you will be working in a distributed environment. Some programmers working from home, some from other continent and other timezone. So can technology be so efficient to make sure you can support such distributed team structures. Can multiple programmers work on same module/file without having to spend a lot of time on resolving check-in conflicts? Does technology provide good patterns to support separation of concern, so that you can work in horizontal or vertical team structures with out creating lot of issues? Does the technology at least comes up with a really good Diff tool? .

Eco-system -

  Your product is going to live long long time if it is successful. True, having a successful product means you can spend money on porting it to whole different technology if required. But such porting rarely happens. We are still bridging with applications which run on mainframes. Businsess will very rarely do such porting. Its risky, expensive. Also are you going to fire all programmers who worked with you in making the product successful? No! So re-training costs. 

  So what you need to consider is, how good is the eco-system around my technologies. Will the eco-system evolve as per changes in other tangential technologies? Are the technologies supported by a community which is strong, vibrant and evoling? Is this community lead by a company which makes heaps of money from the technology? Can I find a consultant in particular area, like performance management or memory management,  quickly? Are their enough companies out there who make support product for this technology? Are developer tools and environment available off the shelf? Are there any outsourcing vendors available who are competent in these technologies?

Time to market - 

   People say in todays world time to market is reducing very fast and we need technologies which accelarate the same. I say, time to market was always an essential factor in considering technologies. Today we have large choices of technologies to choose from which provide very different time-to-market and hence the big discussion.

   Again lot of people will say its so easier to build application in a particular technology, that time to market is 50% lesser than other technologies. I say, okay, may be that is possible. But what is time to market? From product concept to first public release of the product is time to market. This includes time for team building too. If it is going to take me 6 months to find good programmers I can work with for a particular technology then how is that going to reduce my time to market? But I will discuss few more things on this issue in the next post, where I talk exclusively about Java+GWT combo and how we are reducing time to market using it.

Why?

  Last but not the least parameter. Why I am choosing this particular technology? Is it a status quo to work in these technologies? Am I a true if only I work on products which are written in this language? Are my customers well versed with this technology? Is the cost of building a product much lesser than other available technologies? There can be numerous such Whys, but you need to be clear about this.

Implementing Concepts, Process, Startup .Net, java, Perl, PHP, product, python, ruby, Smalltalk, Technology

There are always 2 way to build a great product for any startups.

1. Assemble team of genius engineers. Give them freedom, trust their instincts and skills. Only thing is difficult to find genius engineers
2. Work on your development plan. Find out function points. Break down things into smaller things. Implement quality assurance processes. Problem is it takes away coolness in the startup environment.

Both ways have proven to yield results.  It’s your choice whether you want to keep looking for genius or you want to start building with what is available at your disposal.

Process, Startup entrepreneurship, implementing concepts, Process, startup advice

We are trying out this new method of conducting interviews of experienced technical/non-technical resources. This method is only used for 2+ years of experienced candidates.

What we do is we have a pre-interview with people who have applied (15 minutes) with out much technical questions after a careful screening of resume and reference checking. After this pre-interview we divide short-listed candidates in group of 3-4 people. Now the second round of interview these candidates conduct there own interview in sort of debate/group discussion. So each candidate will ask question to others in the group and they will write down answers to it on paper. 

Candidates try to bounce each other of with the cool thing they know about technology which they think others may not. We just moderate the interview after conducting 10 mins of introduction and rules section. This debate (?) is typically for 1.5 hours. Note that we do not give grades to answers, just that we moderate closely and through observation decide who is better.

There are generally 2-4 groups that we form and we select 1-2 guys from each group. This is not a rule, if we like all we will select all! Then winners of groups go through third round of interview again in same way but for 3 hours! We downgrade a person who does not ask questions, but just gives answers. We also downgrade people who are too agresive and want to show off with by asking questions which even they cant answer satisfactorily. There is bunch of observation that we do in this process. And we note down these observations not by pen, notepad or any other thing but using twitter!!!!

Why we came up with this model? Well people can answer questions just fine. There is limit to how much research I can do before going into an interview. There are only so many type of questions that I can come up with. I dont have time to categorize these questions or decide how hard they are etc etc. So I delegate by job on the person who has applied for the job itself .  

We are just trying this model till we see it works or not and then if it does then we will implement it for all senior positions. Do comment if you think there are some things we can try out or if you find any broken piece with this model.

Ideas, Implementing Concepts, Process HR, implementing concepts, innovation, interview, Process, Startup, startup advice, training

Probably the most important responsibility of any entrepreneur is to hire good people. But how do you do that? Be it product company, services, media or any other company, you need good people to sustain growth. Most companies despite having great product or great service offerings fail in this aspect.

What I do with StartupForStartups.com is, I have created an organizational chart. Now since we are a service collaborator company this chart is extensible. But we identified all the roles/responsibilities that will be required in team members once we start maturing. I have it prepared for next 5 years in detail and next 10 years high level view.

What this chart contains is, different skill sets that are required from a particular resource who is playing a particular role in the company. For example, right now I am HR head, Operations Head and Business Development head apart from taking up few key technical responsibilities. Now I know exactly when I will be giving up operations responsibility and what skill set I am going to look for in a person when I want to hire him as a operations head. Along with that, these skills are broken down into multiple charcteristics like mandatory, preferable etc. One of the category is if a person can acquire a particular skill and if can then how. Is there any training program being offered which will help, or some in-house training we can design. So once I know all these things I put up cost against each skill-set and approximate value of the resource to recruit. And then begins optimization of cost and skills.

Second important use of such oraganizational chart is, in a startup you can not hire all the people from outside playing limited role. Few roles have to be taken up by existing team members. Also you have to show growth path to your initial hires. So when you have hired few people. Identify what they are good at what they can learn in 1-2 years. Now cross check this with kind of skill sets you are will be looking for for a particular role. So not only you provide growth path to your team members but you create long term relationship with them. One example for such growth pattern is can a technical team member grow up to become an business development manager? or delivery manager? There are many possibilities open when you know what you are looking for and when you will need that.

Process, Startup entrepreneurship, Process, Recruitment, startup advice, startups

In my recent visit to Pune/Mumbai had lively discussion with few people who are planning to get into enterprise applications space. Problem is they dont know what the pain points are! I was just amazed to see how a person can devise a solution sitting at his home for a business he has never had any experience in. Logic presented to me was, we have the technology and problem solving skills so we are going to visit “many” different kinds of SMEs in manufacturing sectors, especially in smaller towns like Nasik/Aurangabad/Kolhapur etc etc and then after doing field research for a month or so we can start prototyping the product. Please dont expect reply from SFS is this is going to be your way of building products.

I have been following startup scene in Indian and comparing it to global startup scene. The measure difference in I have observed is globally (read US) people stumble upon a problem and then try to see if technology can help solve the problem. Here many entrepreneurs (at least 50%) build the technology and then try and search for the problem , where to apply it.

Even in e-governance project. I visited Maharashtra Warehouse Corporation couple of times for consultation and what I saw there was simply stupid way of product engineering. Customer (who is going to use the product) is not even involved in analysing requirements!

Advice is : go to few customers. Work there (moonlighting) in various departments, understand the process problems. See how it is problem for yourself and then come up with strategy to solve it. Its like learning mathematics, when you need do well you need practice. You need stummble upon problems on your own and solve them.

Process, Startup enterprise applications, problem solving, product engineering, requirement analysis, startups

I have always been thinking about how I am going to train a freshly graduated student coming just out of college and joining my company. Not having a good training program in place is one of the major mistake any startup makes. I have been with a startup where we had same problem. So what we did was devise a sound training program.

Most important thing you have to understand is writing quality code is art, there is no other away to put it across. Have you ever learnt a musical instrument? Painting? Singing? How do you learn it. First you have see a maestro at work, live. Performing just for you. So you know the body language, know the small movements, listen to breathing as he/she performs. We do the same in our training program. We start with one week of class room training focused on software solutions and not technology. (We hire people who have some knowledge of technologies we use) After this one week, we give new trainees a project to execute, typically a small project like implement a blog tool, bug management tool etc. We work with the trainees in all phases of project execution.

We do requirement analysis together and play roles of customer as well as facilitator. We do design with them. But most importantly when the architecture of the project is decided, we implement a use-case for each new person in pair programming. All the trainee has to do is sit with one of the more experienced developer and watch him implement the use-case.

Advantages:

1. When a person see how a pro writes code, how he uses various tools including time-sheets, IDEs, debuggers , he gets window into how as a professional he should work.
2. Experienced person normally walks trainee through various things, classes as he is writing them. This gives insight into how a high level design is transformed into low level classes and data structures.
3. We normally don’t have time to do entire low level design, attribute design. So we rely upon experience and re-factoring to some extent.  Pair training gives trainee hands on re-factoring.
4. Get to know various tools, shortcuts, first cut what proficiency trainee should have once he/she has experience.
5. Time management. How much can be accomplished in how much time.

Disadvantages:

1. Sometimes there is chance that trainee will pick exact bad habit trainer has. Though we try to monitor our training processes closely, but there is still a chance. To reduce it we do pair training with multiple trainers.
2. Time consuming. Hence we do it on a Sunday. Yes we work on Sunday! We want to grow and build a great company.

Implementing Concepts, Process, Startup pair programming, Recruitment, startup advice, training