jsync | Java Staffing Specialist

Big vs. Small Companies in the Post Dot Com Era - Which Is Best for You? (and how open source levels the field)

02/05/2007

by Dave Fecak

If you’ve been in the professional software world for more than ten years, chances are you have had the opportunity to work for at least two or three companies. The trend during the ‘dot com boom’ was a mass movement of technologists from larger and more established companies to small start-up firms which often provided higher salaries and stock options. We all know what happened next.

Now that we are several years removed from the boom/bust, and start-up is no longer a dirty word, it is probably a good time to revisit the different opportunities presented by big and small companies, with an emphasis on differences for our audience of software professionals. A lot has changed in the past few years, and the job search criteria that you currently use to evaluate new positions may be vastly different than those you used just a few years ago.

We will first go over the general conceptions of what people tend to think when referring to ‘big’ and ‘small’ companies, and then draw some conclusions and uncover some myths.

The Big Company

Traditionally, the ‘big company’ has been characterized by better pay and increased stability, stronger benefits packages, and a wider variety of resources available to employees. Specifically to software professionals, big companies generally were perceived to offer more advanced (i.e. expensive) technical development tools and products, the ability to rub elbows with highly specialized (i.e. expensive) technical consultants, and access to trainings and conferences to enhance skills.

From a technical career perspective, a big company often is organized so that each individual on a development team will have a well defined role – developers will develop, architects will design, testers will test, sys/database admins will admin, etc. Sometimes a big company will also have a well defined development methodology, a technical roadmap, and several processes in place that need to be strictly adhered to during the software lifecycle.

The Small Company

The ‘small company’ was historically characterized by lower pay in exchange for a potential future upside (stock options), lower stability and high risk, weaker benefits packages, and a smaller pool of resources for employees (i.e. ‘Do we have a stapler?’). One big positive often associated with small companies is management flexibility regarding attendance. Relative to big companies, small companies were perceived to have less advanced (i.e. cheap) development tools and products, limited access to career development resources such as technical training, books, and less exposure to consultant knowledge.

Technical teams at small companies often consist of fewer members, so roles are not clearly defined. Sys/database admin and testing duties will often be taken on by team members also involved in design and development. A well defined methodology at a small company may be ‘Just code!’, and standards regarding which products can and can not be used for development often do not exist.

Reality Check

In reviewing the perceptions of big and small companies, the first myth we come across is ‘job stability’. Perhaps ‘myth’ is not an accurate term, since there was a time where job stability was in fact real – job stability was a species that walked the earth but is now extinct, at least in most industries where software development is involved. ‘At will’ employment generally eliminates job stability for companies large and small, so that is no longer a real advantage for big companies. That being said, some companies are obviously riskier than others, but you should base risk on company performance and potential for future earnings rather than just size or number of employees.

Generally, the benefits and resources available to larger companies still can be viewed as an advantage for big firms, but the gap seems to be closing. Many large companies require significant contribution for medical coverage, as many small companies are making larger contributions to compete with their big company counterparts. Small companies are also getting more creative to offer perks that many employees will find appealing. The salary gap between large and small firms is also decreasing – small companies realize that any perceived higher risk can often be alleviated through higher salary (formerly done with stock options in lieu of salary), and large firms tend to subscribe to the idea that the large corporate setting they provide entitles them to grant lower salaries in return for the thought of job security.

The biggest change in the past five years is probably on the topic of technical products available to large and small companies. As open source products have emerged and perhaps surpassed (in market share, value, or performance) their costly alternatives from traditional vendors, the disparity between software development tools at large and small companies has virtually disappeared. Furthermore, an argument can be made that small firms even have an advantage in regards to development tools. Large companies are much more likely to have roadmaps and governance that limit the products that a developer/architect can use, and often these limitations and rules are purely based on a corporate-wide loyalty to a specific vendor – think of all the big WebSphere/DB2 shops that might rather use a different combination, or how difficult it might be to use Linux as opposed to Windows on a machine provided by a large employer. Smaller companies that have no real loyalty to one major vendor can build a best of breed combination of tools without limitations – an obvious potential advantage.

The role you play in a small company may be an essential part of the small team, but it is hard to expect that you will keep that level of influence in going to a large company. A role in a small company may often translate to a position slightly lower in a large company – Chief Architect at a start-up may amount to Architect at a big firm, Tech Lead may become Senior Developer, etc. It’s the ‘big fish in a small pond’ cliché that holds true as much in technology as it does everywhere else. If influence is of utmost importance to you, smaller is usually better.

Lastly, when considering big vs. small companies based on career development and your marketability in the future, we need to think about which environment may help build your skill set the most. As mentioned earlier, in a big company most job responsibilities are more focused where in a small firm technologists are often asked to wear a variety of hats. The big company can often limit your ability to learn new technologies, as they are usually less able to implement cutting-edge products without a large amount of research and proof-of-concept studies. Most small companies will give software professionals the opportunity to work on a wider range of technologies and to serve in roles (admin, QA) that are specialized in larger firms.

The Verdict

Unfortunately, there is no ‘one size fits all’ for most people, and there are advantages to big and small companies depending on your career goals and personal situation (family, finances). Just keep in mind that the software world has changed quite a bit and the negative perception some have about small companies is probably a bit of the dot com hangover. Keep an open mind when evaluating companies, regardless of their size.

Newer >

< Older