Saturday, February 5, 2011

Who is interested in having a StartUpWeekend locally?

Yesterday I posted the following to two local user groups (Bellingham DotNet and Whatcom tech List)

 

In Bellingham that is,

There is a good chance of getting folks from both Vancouver and Seattle attending... but we should have a reasonable local involvement.... Read through the site and broadcast your interest!

There was actually more interest than I expected, see thread at:

As a result, I created a linked in group for such activities to occur in the Seattle-Bellingham-Vancouver corridor to help this come into reality.

 

Where do you fit in as a developer?

This morning I woke up and realized that it may be helpful to discuss classes of developers that I’ve seen (asbestos overcoat on – since I suspect I may ‘insult’ a few people with candidate remarks) in general and how these may impact startups. This is part of my series on startups.

Newbie Developer – Up through the ranks

This is often the person who got into web-site development directly from high school or college. Often they have few formal courses (training or academic), are self-taught and often ilk out a living (20-35K /yr is often seen).  For a startup that decides on using the technology stack that they know, they are cheap effective cannon-folder.  They can also be a major team destroyer because they often have worked solo or near-solo; take instruction poorly (i.e. not willing to accept how little they know); and rarely are capable of presenting reasoned arguments based on objective literature or analysis.

Newbie Developer – Recent Graduate

We actually have three grades: Associate (2 yrs at a college), Bachelor (4 yrs at Univeristy), Master or higher (6-10 yr at University).  As the year of formal education grow, their ability to do good discussion of software issues grow significantly, I would say exponentially.

Formal Education Discussion Depth
0-1 (Up through ranks) 0 or –1
AA 4
B.S. 16
M.S, PhD 30

They tend to be weak on making independent decisions (“Confined in Educational Institute syndrome”); they can become cocky unless the manager/lead earn their respect; their ability to make good trade-off decisions is poor – often they will work obsessively on something of low value. Their initial value is below their salary (30-80K/yr), but often this reverses within a year.

Junior Developer

I define a junior developer with less than 4 yrs in the industry. With current technology stacks, it usually takes 2-4 years to gain sufficient experience to program adequately. If the person is in a good shop (actual code review, senior mentors, development methodology, standards, etc) then 2 yrs is sufficient. If not, … well I have seen folks that have never been in a good environment and still write lousy code after earning a living for 15 years…

 

Shop Types

The type of shop that they have been experienced in have a great impact on their productivity and suitability. Again, general observations and not prescriptive.

Internal IT Departments

I started there back in the 1970’s and occasionally get consulting gigs that re-exposes me. Often these developers are expecting 9-5 jobs, slow (if any) promotion, being sent on courses…  in short, it’s a job (and not a career). They will often be technically very good but may reject the idea of sleeping on the floor under your desk for a few days when a push is called for. Creativity and novelty (new ideas – brain storming) are their weak point. They will often tend to non-agile or RAD approaches. They like keeping their backside covered.

 

They are a good fit for doing maintenance and code-review for a startup. Whipping out an application in a weekend is unlikely. They are excellent infantry – often a startup need commandos, rangers and airborne to land and take a bridge head.

Service Bureau

I have worked for several, BEST, Accenture, Satyam etc. A good SB developer does as they are told, do not cause waves (or even ripples!!) with management. Often they are low on experience and hoping to gain experience to get an employee job; or, there are some form of problem (personality etc) that have prevented them keeping an employee job. Rolling on and off of assignments keep an income and minimize lost of job due to their problems.

 

For a startup, their obedience is a major problem. Standard operating practices is NOT to raise issues when they see a bug or unhandled issues; rather keep quiet because they will get more work fixing it later! Proactively fixing things is not in their financial model or thinking.  The second item is why they are doing SB work – lack of experience or ‘humanware problems’.

Consultancy

I currently run a consultancy. The reason is simple, my yearly gross can run 2-4x more than I would earn as an employee. Consultants that have survived for 4+ years tend to be the opposite of a SB person because they are trading on two things:

  • Experience that seasoned folks are willing to pay for
    • Often their creativity and fresh ideas are their hiring point!
  • Ability to be good as humanware

The main problem with these folks is often talking them into becoming involved… the “a bird in the hand versus two in the bush” dilemma.  Why spend N hours on a startup when I can find work paying $100-$200/hr.   A StartupWeekend represents a potential lost revenue of 54 x $200 –-> $10,800. For those that have only day jobs, there is little lost revenue opportunity. On the plus side, they will cut though issues past and focus the work.

 

Often you need to be happy to get them “part-time” while giving them a full-time share of the startup… unfair – yes, but also pragmatic to their reality.

Web Site and Mobile Application Shops

These folks are often very skilled in turning out pro-forma work. Literally assembly line workers. They have great depth in one area, but often little breath. Often they will grind out a website a week or a month. The question is usually whether their strengths are a match for the startup needs.

One problem they can sometime present is a high man hour count when something has to be customized, or a tendency to a kludge solution that will often bite later. For a 54hr Startup weekend, they will rarely do any harm and a lot of good solid delivery. For a successfully launched startup, they value may decrease quickly and go negative within a year.

 

Heavy Duty Web Sites and Shrink Wrapped Products

These folks may grind out a product or a website a year, or even two years. They are accustomed to heavy quality assurance,  code reviews and all of the stuff for a successful launch and low support costs. Support costs?  Depending on what a startup is, this can be a major issue – for example, I have read open letters from people cancelling paid linked-in accounts because there is no telephone # for support and a commitment to reply to an email in a week only.

 

These folks are often who you want to ease in once a revenue stream is created. The term “Technology Debt” is often cited with startups – this is the cost of doing things with kludges in order to get things to market. It is referred to as a debt because it results in man hours being consumed to keep the kludge alive as well as being an obstacle for timely enhancements (“You can’t get there from here in less than 9 months” while two johnny-come-lately-competitors has just delivered that feature….).

 

Many of these folks are constantly looking for potential problems and opportunities with the product they are working on. They know that the key is to stay ahead of the competitors and that means some R&D time. R&D time is not what most startup can afford to pay for – but if R&D does not happen once a positive cash flow starts – they are closing their future sales book.

 

Summary

A startup goes through phrases just like a romance or a marriage. Often the ideal developer on day 1 turns out to the girl-friend from Hades a year later. Getting a bunch of random developers is like starting a racing kennel with a bunch of strays from the pound. There may be some gems, but there may be also a lot of pain. If you can find a seasoned development manager to help select the developers and write-up a report on each strengths and weaknesses would be a wise decision. Each developer is different. It is not whether they know the technology (i.e. can fire a gun) but their skill levels and attitudes (is this developer an excellent gully but a lousy shot? Is he alert and observant and thus an excellent body guard? Can he track a deer for 18 hrs a day or will he get winded after 15 minutes? Can he haul a deer across country on his back?).

No comments:

Post a Comment