Category: Start-ups
Enterprisey Developers, Acronyms, and Discrimination
Over the past few years my clientele shifted from a mix of mostly mid-market companies and a few startups to almost entirely startups, and that shift has resulted in a wider palette of languages requested by clients. Where my business was about 95% Java for the first 10+ years of my career, today it is closer to 25%. As I’ve written before, my business veered naturally from a pure Java focus when a considerable amount of the Java talent I have represented in years past started to migrate and show interest in diverse languages and ecosystems.
Unlike the boom periods for startups in the past, it appears that today’s startup is much less likely to choose Java as the primary development platform. Many developers who did Java work for startups in the mid 2000’s sought higher ground in the late part of the decade when small shops took a hit, and found themselves working for large companies and more corporate environments.
Flash forward to the past few years and the resurgence of startups. Many of those engineers who took shelter in the larger firms are now interested in establishing themselves once again as a major contributor on a small team in a startup, and when I have represented some of these highly qualified developers to startups now, I’ve been met with the feedback ‘The candidate’s résumé appears too enterprisey‘. As an aside, I don’t get that response nearly as often for Java engineers that stayed with small companies.
The enterprisey label, in my experience, seems to be used in two situations that can often (but not always) go hand-in-hand. First, enterprisey is often used to describe candidates that come from large development shops regardless of the languages used (although Java and .Net platforms are the norm), where the bias is that the development culture and the broader company culture make that candidate less likely to succeed in the startup. This is the result of preconceptions surrounding development methodology, possible unnecessary complexity in applications, a slower release schedule, or the impression that developers in these larger environments are sheltered from tasks related to data, devops, sysadmin, and QA that are frequently handled by developers at startups. The label may be applied liberally to virtually any candidate coming from a company larger than the hiring firm.
The second common enterprisey tag is used on any developer using Java or .Net regardless of the employer size, due to the predominant viewpoint that other language communities have developed regarding Java/.Net being wrought with and plagued by dozens of frameworks and bloated stacks. As someone who sees thousands of résumés a year, it is clear that résumés of Java and .Net developers are often significantly longer than those of developers in other languages, but there could be several factors at play there beyond just the number of potential bloat items (insert Java = verbose joke here). At a distance, the résumés of Java developers can resemble an eye chart, with acronyms outnumbering actual words. One hiring manager of a Scala shop provided this gem:
“The laundry list of legacy enterprise technologies (JMS, JMX, etc.) doesn’t do anything for me.”
The word ‘legacy’ seems particularly cruel there.
Sadly, many of those making hiring decisions in these startups are quick to dismiss a highly-skilled talent simply because of their experience working for a larger company or their primary language being in the Java or .Net worlds. Whereas an interest in, say, functional languages is now often used by startups as an indicator of ability, the prolonged use of Java or .Net at a large firm can be a detriment when applying for work in any other language or polyglot environments.
So how can engineers labeled ‘enterprisey’ escape that bias and be accepted by smaller shops with different languages?
Résumé and bio de-enterprisification – That’s not a word (yet), but the concept would be to go back and make sure your résumé/bio/LinkedIn profile/etc. doesn’t read like a corporate Buzzword Bingo card. Eliminate or modify anything that may appear steeped in bureaucratic process and procedure, and be wary of any items that can be perceived as indicative of a glacial development pace. References to project length and time between releases should typically be avoided. Emphasize new development over maintenance tasks, and accomplishments over process. Listing too many tools, frameworks, and specifications will often work against you and may be considered an indicator of your dependence upon them. Shortening the résumé is almost always the way to go here, and three + page résumés generally smell of enterpriseyness.
Develop other language credibility – Any code that you can point to that does not run the risk of being labeled enterprisey is better than nothing. As stated before, some startups perceive functional programming interest as a marker for ability, so even an implementation of a typical interview exercise in a functional language (or one different from your primary) has value. Provide links to this code on your résumé and reference any personal projects that are applicable.
Stop calling yourself ‘LANGUAGE Developer’ – I do it too (all the time), but you should not. Use whatever you feel is appropriate – Software Engineer, Programmer, Developer, Geek – but stop inserting a language when describing yourself on paper or verbally. And perhaps more importantly, stop thinking of yourself as a LANGUAGE Developer. Sometimes you may need to dumb it down so the clueless recruiter will find you, but try to minimize those instances the best you can (and do you really want that recruiter to find you anyway?).
Express your outside interests – Just because you get paid by some insurance company to write Java/.Net apps all day doesn’t mean that is who you are. If you are exploring other languages through books, conferences, and self-study, make that known in whatever way may be discovered during your job search (résumé, blog, social media, etc.). Hobbies like robotics, Raspberry Pi, and Arduino are probably unrelated to your job but not necessarily unrelated to your career. Any technical interests beyond the primary function of your job demonstrate at least some level of versatility and the ability to adapt outside of your enterprisey 9 to 5.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search very helpful. You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.
Tips To Overcome Ageism In Hiring As a Software Professional
As a recruiter who is about to celebrate (as if recruiters celebrate such a thing) mark fifteen years in the technology industry, I am starting to see that many of the contacts I made back in the late 90’s are now having some concerns about ageism during a job search. Any failed interview for older software professionals may cause a raised gray eyebrow and a thought that age and not their skill was a factor in the decision. Companies that freely apply catchall terms such as “overqualified“ or “not a cultural fit” in a rejection only serve to cloud the engineer’s mind and cause him/her to wonder if these are just the politically correct or legal code words to signify “You’re too old for us”.
Much has been written about older professionals being dogged by myths surrounding work effort, production, energy, and whether employees with families are more likely to work less. Start-ups are often portrayed as testosterone-and/or-alcohol-fueled code marathons only welcome to young males, which hurts the many start-ups that are not. But even hiring managers who have read studies and evidence that debunks these myths may still be guilty of judging candidates based on perception, so another blog post about why all companies (start-up or mature) should consider hiring older workers may not be helpful. The goal of this post is to help these more experienced candidates maximize their chances of being considered for jobs, and to make sure they are evaluated based on their skills alone during interviews.
Just as you would find at a nightclub, ageism starts with the person at the door. During a job search, the doorman is the person screening resumes. Therefore, the resume is the first item of consideration when trying to combat the problem. Let’s look at some common resume mistakes that expose candidates to ageism.
Resume Tips
Mistake #1 – Your resume does not need to include every position you have had in your life, and it doesn’t even need to list every position you have held in your field. This is by far the most common way that candidates expose themselves to possible ageism. If you have been in the industry for over twenty years, the work you did at the beginning of your career is hopefully quite different than what you are doing now. Trim down your resume to a manageable size by eliminating jobs that are the most dated and least relevant. Although there is nothing wrong with removing outdated experience, add the phrase ‘Additional experience provided upon request‘ if you feel it necessary.
Mistake #2 – The ‘Education’ section of a resume does not need to include graduation dates. The graduation date is arguably the easiest and most accurate way to put an age number on a candidate, using the formula
Age = (current year - graduation year) + 22
By including the date of graduation you are simply making it easier for them to discriminate. When hiring managers or recruiters see dates that seem like the distant past, they will do the math in their head subconsciously and label you with a number. “This guy graduated in ’81? That makes him, what…54?” Don’t put the date on the resume if you feel that your age could be used against you. This isn’t dishonesty (putting an incorrect year would be dishonest). There are several details about you that are not listed on your resume, and graduation date should not be required.
Without a graduation date, the formula for quickly approximating age generally becomes
Age = (current year - year of hire at earliest job listed) + 22
If you consider the point listed in Mistake #1 and you decide not to list early and irrelevant job(s) right out of school, and you also do not list your graduation date, you can potentially take years off of your perceived age.
Mistake #3 – Your resume does not need to include every technology that you have ever used. A resume of a very senior engineer could potentially contain an impressive and lengthy list of technologies in the skills section if he/she were to offer a comprehensive inventory of the various hardware, tools, languages, operating systems, databases, protocols, etc. that have been used during the span of their career.
Keep in mind that certain technologies or buzzwords are likely to trigger a visceral reaction based either on the age of the technology itself or how that technology is generally viewed by the industry. Languages that are out of favor in today’s programming culture are probably the most common issue. To have experience over a long period of time and with several tools is undoubtedly valuable, but unless a technology has significant relevance to the jobs being sought the risk of including these details may outweigh the benefits.
Interviews
If you followed the advice above regarding your resume, the next step will be interviews. In interviews, you want to make sure not to play into any of the myths or the fears that are commonly associated with the hiring of older workers. Below is a list containing many of the most stereotypical generalizations or assumptions common to ageism and how to best avoid them.
Older hires will not be able to put in hours. The availability issue is more closely associated with start-ups that may require more office time, and this perception is amplified when a start-up is staffed primarily with young, childless, and single employees. Being honest about your desire for work/life balance is best for all parties involved, but don’t let the interviewers assume that because of your age or family situation that you are only able to work 40 hours if you are indeed open to more. Clarify the amount of time you are willing to commit to working in or out of the office to prevent false assumptions.
Older hires will retire soon. Answering the “Where do you see yourself in five years?” with “Retired in Florida” is probably not the best answer, but honesty about your expectations is always best. Don’t let the employer assume that you are planning to retire soon if that is not the case. If you can not afford to retire in the near future, it may be helpful to let a hiring manager know that fact in order to allay this potential fear. The amount of time technology professionals of any age spend at any one company is lower than it used to be, so having an older employee on board for three to five years could have value to the company that is not much different than the average tenure of a young hire.
Older hires have low energy or are less productive. Older candidates should be more aware of their perceived energy level and body language during interviews. It’s good advice to job seekers of all ages to try to schedule interviews during the hours of the day that you feel you perform best and are most alert. Be sure you are well rested, fed, and look alive.
Older hires have dated or irrelevant experience. Eliminating some of the older experience on the resume helps showcase current skills while avoiding the appearance of stagnation. When giving anecdotal answers, try to focus your material first on what is most relevant and most recent. Referring to projects that ended thirty years ago is not advised unless the lesson learned was incredibly valuable.
Older engineers only want to manage. If you have been in leadership roles but are looking for something more hands-on, you must make that very clear during interviews and in initial correspondence when applying for a job. The assumption will always be that employees expect more responsibility as their career progresses, but many software engineers simply want to stay in the code and are not interested in managing. Don’t let your interviewer assume that you want to manage if you do not. A willingness to mentor employees while also being hands-on will add to your potential value.
Older engineers are less teachable and may have strongly reinforced bad habits. This line of thinking is amplified if the candidate has been in the same professional environment for many years, and the suspicion is that engineers become overly accustomed to a single way of working and won’t easily adapt to new ways. If you have had the same employer for a long time, try to emphasize any major changes that took place during your tenure and how you were forced to learn new things or leave your comfort zone. If you were an agent for change, be sure to bring that fact up during conversation.
Older hires will not be a culture fit. Culture fit is something older engineers probably didn’t hear much about in the beginning of their career, and ‘not a fit’ can be used as a blanket term for rejecting candidates without having to give a specific reason (which potentially exposes a company to discrimination lawsuits). Try to learn about company culture before the interview so you can at least be aware of their values and the image they want to convey, even if that image is not really who they are.
Career advice
Stay relevant. Keep up to speed on what technologies are popular with the cool kids, even if you do not use them on the job. If you have time to spend a few hours and tinker, that experience may pay off in your next job search. Knowing what others in the industry are doing is as simple as reading articles every few weeks.
Never stagnate. Older engineers that overstay their welcome at a company will have an incredibly difficult time finding work if a job search becomes necessary. When senior engineers are the victim of layoffs after being employed for 15 or more years, a long and difficult job search is often the result. Being stuck in the same role with the same technologies at the same company for a long stretch could become comfortable, but it will not be an asset when changing employers. Your first loyalty should be to yourself and your career, and not to your company. In my experience, older professionals that have not stayed at any job for a long stretch (>10 years) have the most prospects.
Keep a positive attitude. Many engineers are quick to actually dismiss themselves as candidates due to age, and they don’t even bother applying to companies they feel will reject them based on ageism. Other candidates have self-defeating attitudes about their plight or their perceived inability to improve their situation. Do not fear rejection, and learn from mistakes made during job searches.
Share your knowledge. Engineers that have a reputation as teachers, advisers, and mentors will always have an easier time finding work. Whether you write technical blog posts, present to user groups, or do informal talks during lunch, you will develop a reputation as someone who uses your experience to make your teammates better. Think of your experience as a positive asset for a new employer, and be known as someone who is always willing to guide younger technologists.
Be open to non-traditional employment options. Job trends and careers have changed drastically over the past 30 years, and the traditional ‘graduate college → get job → retire with pension‘ progression isn’t realistic today. If you haven’t already, give consideration to contract/consulting work, contract-to-hire or alternative employment options. Older professionals may find that ageism is less common in temporary hire situations.
How Hackers Choose Tools (thoughts on Paul Graham’s Java’s Cover)
Recently, a 2001 blog post with the title Java’s Cover written by Paul Graham (of Y Combinator fame) spread across Twitter and was linked by all the other usual tech site suspects. The piece was about what Graham called ‘hacker’s radar‘, which he describes as the ability of hackers to ‘develop a nose for good (and bad) technology‘. For his description of hacker’s radar, he decided to cite Java as an example of a technology that smelled bad at the time. Java’s popularity in 2001 made it a pretty big target for critique. The title Java’s Cover is a reference to judging a book by the cover, and Graham argued that Java’s cover was a stinker.
Graham admits in the article that he had never written Java and his main exposure was when he ‘glanced over reference books‘, though Graham does have substantial tech credibility as a hacker. He lists 12 reasons why he didn’t like the look of Java, and mentions that he had a hunch that Java would not be a very ‘successful language‘ (but he ‘may turn out to be mistaken‘).
The commentary on the aforementioned usual suspect sites seems, predictably and unfortunately, to be centered on the accuracy (‘is Java truly successful?’) or inaccuracy (Java is everywhere) of the prediction itself. I feel it is a much more interesting exercise to take the opportunity to go into the author’s opinions as representative of an advanced technologist, and to see what factors would lead a like-minded and influential technologist to potentially have the same negative reaction to a new tool/language based on relatively non-technical factors. Every day we read articles that are highly critical of languages, frameworks, design patterns, and anything else you can imagine, and it can be difficult to tell how much experience the author may actually have (or even need) to make such assertions. When an industry voice writes an opinion on a topic based on the factors listed by Graham, what weight is given to the conclusions by the community? Graham’s article is somewhat unique in that he was willing to list the ‘smell’ reasons for his suspicion.
Looking at each reason Graham gave individually may give us some insight into how technologists yesterday and today may form opinions about a variety of topics, and whether or not we can use these tests to determine future success.
1. It has been so energetically hyped.
While it is certainly true that excessive hype can be a sign of any potential product’s weakness, that certainly isn’t always the case. Graham mentions notes that ‘A real standard tends to be already established by the time most people hear about it’. You will find that almost every technology that is highly criticized has been blessed/cursed with a fair amount of hype, either generated by marketing people with profit motive or evangelists that may have much smaller (or even zero) financial interests. I’m not sure that hype alone should make technologists wary about a new offering, but people who are naturally skeptical will surely be wary of over-the-top hype efforts.
2. It’s aimed low.
This one seems to have some merit. In this case Graham is saying that Java is intentionally dumbed down, and that ‘Java’s designers were consciously designing a product for people not as smart as them. Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.‘
When people create a product/tool for other people to use, they obviously want their audience to be able to learn it, and Graham seems to argue that by ‘aiming low’ and focusing on ease of use you are probably placing unnecessary limitations on the product you are building. If you were creating based solely on the need to solve specific problems, ease of use would not be as great a factor.
3. It has ulterior motives.
In this case Graham is speaking of Sun’s plan to ‘undermine‘ Microsoft. We could certainly apply some tests of ulterior motives to several new developments in tech over the past several years, but I’d imagine it would be a difficult task to find similar motives in the overwhelming majority of new products. This one is probably, in most cases, not applicable.
4. No one loves it.
Ouch! Every language, every tool, is loved by someone. Remember all those people in #1 above that make up the hype machine? Perhaps by saying ‘I’ve never heard anyone say that they loved Java‘, Graham meant that that no one of any influence or importance loves it. If a product is eschewed by the most widely respected folks in industry, that is a warning sign. When some thought leaders begin to endorse tools they become viable for others to adopt (see alternative JVM programming language adoption by big firms today). Some former Java evangelists professing a love for Scala comes to mind.
5. People are forced to use it.
Being told that you have to use a tool does not make it questionable, but in Graham’s brief description he infers that the anecdotal evidence includes smart people that would have used the tool voluntarily if it were good. This is probably better said as ‘Outside forces with potentially differing objectives force technologists to use it against the techie’s own better judgement.’ It’s hard to argue with that.
6. It has too many cooks.
This one is quite interesting, especially with the changes that have occurred in the industry since 2001 and the emergence of open source as a dominant player in the market. Graham went on to write that ‘the best programming languages have been developed by small groups. Java seems to be run by a committee. If it turns out to be a good language, it will be the first time in history that a committee has designed a good language.‘
Issues with the JCP over the years have been written about ad nauseam. But what would Graham make of other open source developments over the years? I imagine the rebuttal would be that only the highest level members of an open source project are truly the ‘cooks’ he refers to, with the rest of the members merely relegated to chopping and slicing. Maybe not. Being suspicious of multiple decision-makers pandering to multiple masters would be natural, and warranted.
7. It’s bureaucratic.
In this case Graham is referring to the language structure itself and not the leadership. This can be perhaps lumped into #2 It’s aimed low although not in every instance. If a language is ‘aimed low’, you might expect that the designers would try and limit the types of mistakes users could make (see #9 as well).
8. It’s pseudo-hip.
Interesting perspective. I’d argue it was hip. Graham continued, ‘Sun now pretends that Java is a grassroots, open-source language effort like Perl or Python. This one just happens to be controlled by a giant company. So the language is likely to have the same drab clunkiness as anything else that comes out of a big company.‘
I couldn’t help but notice the words Graham uses to critique Java in 2001 are very similar to how Democrats paint the modern day Tea Party (an observation on the language, not a political statement). The real meat of this criticism seems to be that the product is controlled by a large organization, which per Graham would by default make it ‘clunky’, but posing as a much more community-friendly and open option. I’m guessing this element of Graham’s opinion would have been amplified dramatically after the Oracle acquisition. Would hackers feel differently if a big company tool wore the corporate badge proudly?
9. It’s designed for large organizations.
Graham specifies that Java was designed to limit large teams of mediocre programmers from causing damage. This seems very much like reasons #2 It’s aimed low and #7 It’s bureaucratic above. This is probably more accurately categorized as ‘designed for mediocre programmers‘. I would assume that any advanced technologist would probably be less interested in a tool that seems to be created for a lesser engineer. Graham wants only languages for big boys and girls, and most advanced and even intermediate hackers would probably agree.
10. The wrong people like it.
Graham lists the wrong people as ‘suits’ tuned into the hype from #1, big company programmers from #9, and college kids looking to get a job. He feels that all three of these groups change their minds regularly. I’d say the college kids of 2012 appear to be interested in newer technologies (Ruby, Python, functional programming, mobile) that are probably not the core of their curriculum (Java), and in 2001 they were also interested in newer technologies (Java) that were also not the focus of their education (C/C++). Does the interest of college grads in Ruby and Python make those tools the wrong tools, or do today’s college grads have a bit more of a sophisticated hacker palate? What do the suits and big company programmers love today? Tools with ample talent supply, maybe?
11. Its daddy is in a pinch.
Java’s OLD daddy was, but Java’s new daddy buys islands! But this isn’t about Java. The financial standing of the steward of a language or product is certainly a valid consideration to make when evaluating the future viability regarding use in developing a product. But who would be deemed the daddy of open source tools? Individual project owners perhaps? The vendor ecosystem that supports them? The landscape has changed enough since 2001 that this criticism might be less of a factor now.
12. The DoD likes it.
Guilt by association, and Graham calls DoD culture the ‘opposite‘ of hacker culture. In some recent discussions about Java and alternative JVM languages, I’ve seen this discrimination used in reverse, where Java supporters claim that the use of the alternative JVM languages by start-ups is a strike against using the alternative options. The argument is that start-ups are all run by kids and cowboys, so any choices they make can’t be grounded in solid technical judgment. Interesting how two groups, who both probably feel they are above-average technologists, can come up with opposite interpretations.
CONCLUSION
If you made it to the very bottom of Graham’s post, there is a link to an article called Trevor Re: Java’s Cover, which refers to comments by Trevor Blackwell (also a YC partner) about the post. Blackwell classifies programmers as either ‘brilliant hackers‘ or ‘corporate drones‘ with most tools being written for the drones, so hackers need to know the smell tests to decipher quickly which tools are meant for the hacker and which were designed for the drones. Of course, very few of the people Blackwell calls drones probably feel they are in that camp, which just complicates the issues even more.
I feel that Graham’s article is interesting as a time capsule to compare how hackers thought about new tools in 2001 and how they may come to conclusions about languages today. As an investor, I’m sure some of the same smell tests Graham listed would apply to how he evaluates start-ups for potential funding. Whether Graham was right or wrong about Java doesn’t matter at all, but getting a glimpse into his thought process then is quite valuable.
How would the current batch of popular and emerging technologies fair today, using Graham’s microscope?
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful. You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.
Stop Crapping on Startups
Michael O. Church recently wrote a thought provoking blog post, “Don’t Waste Your Time in Crappy Startup Jobs“, and the author clearly put a lot of thought into writing the piece. Based on the comments and the retweets, it appears the article hit home for quite a few people. I think the article’s title might sway a reader’s interpretation a bit, or readers may simply see it as ‘Don’t Waste Your Time in a Startup’. I’m sure that wasn’t the intent of the article, but based on some of the comments, that sentiment seems to be the takeaway for many.
The crux of the article is a list of seven misconceptions that the author chooses to dispel one by one. I’d like to take each of them and see if these are truly problems with start-ups, problems with the engineering industry, or even problems with expectations. (Mr. Church’s excerpts are in red, my comments follow)
1. A startup will make you rich. True, for founders, whose equity shares are measured in points. Not true for most employees, who are offered dimes or pennies.”
First, I don’t think most engineers that join startups are expecting to get rich these days, and even founders aren’t all expecting to get rich. If you had written this in 1999, I’d agree this is a common misconception. Most employees in my experience see stock options or equity grants as ‘lottery tickets’, that they realize probably won’t pay off – but they also understand that you simply can’t win if you don’t play.
“Moreover, raises and bonuses are very uncommon in startups. It’s typical for high performers to be making the same salary after 3 years as they earned when they started. (What happens to low performers, and to high performers who fail politically? They get fired, often with no warning or severance.) “
I don’t see bonuses or raises as uncommon in the start-ups I’ve worked with. My current client list includes a handful of startups that all offer bonus, and historically I’ve seen employees getting raises and bonuses from startups that are on par with some of my larger clients. And low performers being fired without warning or severance? Is that a startup problem specifically? Low performers or people who ‘fail politically’ are fired in any sized company, the only difference may be severance. Again, this is not a ‘crappy startup problem’.
2. The “actual” valuation is several times the official one. “In truth, startup employees should value equity and options at about one-fourth the valuation that VCs will give it. If they’re giving up $25,000 per year in salary, they should only do so in exchange for $100,000 per year (at current valuation) in equity.”
I usually advise candidates that they may want to weigh any equity simply as a chance to receive some additional compensation, and I’d generally advise them not to accept any offer that won’t afford them to live a lifestyle that makes them comfortable. If you can’t afford a 25K pay cut, don’t take one.
3. If you join a startup early, you’re a shoe-in for executive positions.
Again, I just don’t think engineers are this naive today to believe this, or at least not the people I know.
“Not so. In fact, one of the best ways not to get a leadership position in a startup is to be there early.”
I’d love to see if any actual scientific evidence exists to back this claim up, but I wouldn’t know where to find it. For every engineer you can name that did not get a leadership spot, I’m sure someone else can name one that did. Again, in my experience I generally see that engineers who join early on are rewarded with leadership roles that they are qualified to do. Being the first or second engineering hire at a startup doesn’t automatically give you the qualifications to be CTO, and if you expect you should be CTO/VP just because you were an early hire you probably need to rethink why you are joining the company.
“Startups often involve, for engineers, very long hours, rapidly changing requirements, and tight deadlines, which means the quality of the code they write is generally very poor in comparison to what they’d be able to produce in saner conditions. It’s not that they’re bad at their jobs, but that it’s almost impossible to produce quality software under those kinds of deadlines.”
True on hours, deadlines, requirements, and perhaps the code could be better in ideal conditions. I hear anecdotes all the time from engineers at large companies telling me how much free time they have with their highly reasonable deadlines and fully developed requirements being written in stone. Wait…no I don’t! Again, not a ‘crappy startup problem’ – it’s the nature of the software game overall, just a bit amplified.
“It may have been a heroic effort to build such a powerful system in so little time, but from an outside perspective, it becomes an embarrassment. It doesn’t make the case for a high-level position.”
From an outside perspective, companies that may hire these engineers down the road will most likely respect the experience those engineers had in building the product under less than ideal conditions. Most hiring managers from outside firms won’t know whether the product was some epic flop anyway.
“Once the company is rich and the social-climbing mentality (of always wanting “better” people) sets in, the programmers will be replaced with more experienced engineers brought in to ‘scale our infrastructure’… The old engineers probably won’t be fired, but they’ll be sidelined, and more and more people will be hired above them.”
Well that was depressing. I’d say, more likely, once the product is built and the company can hire more engineers, the developers that were there in the beginning now have accomplished their goal and will make the choice to move on. The mentality of this type of engineer is to build something, but they may not want to maintain it. Once that excitement is gone for this type of engineer, they will go voluntarily.
“Frankly put, being a J.A.P. (“Just A Programmer”) in a startup is usually a shitty deal. Unless the company makes unusual cultural efforts to respect engineering talent (as Google and Facebook have) it will devolve into the sort of place where people doing hard things (i.e. software engineers) get the blame and the people who are good at marketing themselves advance.”
Is J.A.P. a great deal at other companies? There are plenty of established companies that don’t pay engineers great salaries, and work them long hours. I think the key point is the cultural efforts to respect engineering talent. My clients tend to love and respect their engineers, which is why I disagree with many of these stereotypes.
4. In startups, there’s no boss. This one’s patently absurd, but often repeated. Those who champion startups often say that one who goes and “works for a company” ends up slaving away for “a boss” or “working for The Man”, whereas startups are a path to autonomy and financial freedom.”
No boss? I must admit, in my 15 years of tech recruiting I’ve never heard this one before. Who are these people that you are talking to? I’d say startups are a potential path to financial freedom, whereas working for an established company (with no ‘lottery tickets’) is probably not going to get you to early retirement.
“People who really don’t want to have “a boss” should not be looking into VC-funded startups. There are great, ethical venture capitalists who wouldn’t go within a million miles of the extortive shenanigans I’ve described above. It’s probably true that most are. Even still, the power relationship between a founder and investor is far more lopsided than that between a typical employee and manager. No manager can legally disrupt an employee’s career outside of one firm; but venture capitalists can (and sometimes do) block people from being fundable.”
How did we get from having ‘no boss’ to extortion by VC’s and managers? A manager disrupting an employee’s career outside of one firm??? WTF? Lemme guess...the author had a very bad experience?
5. Engineers at startups will be “changing the world”. With some exceptions, startups are generally not vehicles for world-changing visions. Startups need to think about earning revenue within the existing world, not ‘changing humanity as we know it’.”
This might work on a small subset of 22 year old kids, but I think most people know they aren’t going to change the world.
“…but people should understand that their chances of individually effecting global change, even at a startup, are very small.”
The likelihood of ANYONE effecting global change is incredibly small at a startup, and probably just as small at a large company. Again, this isn’t a ‘crappy startup problem’.
6. If you work at a startup, you can be a founder next time around.
Why not? No, seriously – why not? Working at a startup doesn’t exclude you from being a founder next time, does it?
“What I’ve said so far is that it’s usually a sh*tty deal to be an employee at a startup: you’re taking high risk and low compensation for a job that (probably) won’t make you rich, lead to an executive position, bring great autonomy, or change the world.”
If you assume there is high risk and low compensation for every startup job, I’d agree. Jobs with established companies don’t always pay well, rarely make you rich or lead to an exec position, and almost never allow you to change the world. If that is how you define a crappy job, all jobs are crappy.
7. You’ll learn more in a startup. This last one can be true; I disagree with the contention that it’s always true. Companies tend to regress to the mean as they get bigger, so the outliers on both sides are startups. And there are things that can be learned in the best small companies when they are small that can’t be learned anywhere else. In other words, there are learning opportunities that are very hard to come by outside of a startup.”
So you won’t necessarily learn more in a startup, but there are unique opportunities to learning in a startup. This sounds like a feature, not a bug. Are there unique opportunities in larger companies to learn things that you can’t learn anywhere but in the larger company? Perhaps.
“Startups are generally too busy fighting fires, marketing themselves, and expanding to have time to worry about whether their employees are learning.”
Fighting fires is a great metaphor here. Do you know the best practice for fighting fires? It’s actually fighting fires. Of course, there is danger in that, but engineers learn much more by being in those environments than they do in a completely comfortable setting. It’s not about a company that can afford (both time and money) to send you to a training seminar, it’s about learning on the startup job how to build something under tough conditions.
CONCLUSION
In conclusion, the problem with Mr. Church’s article isn’t that startup jobs are crappy. It’s that the author feels that many people may have certain unrealistic expectations about startup jobs. It assumes that all startups work you to death and pay you nothing, and that simply isn’t the case. It’s a stereotypical assumption, and it’s dangerous one.
If you take any job and expect that you will absolutely:
1 – get rich
2 – become an executive
3 – have no boss
4 – change the world
5 – found a company within x years
6 – learn more than everyone else
then I can assure you that you will be VERY disappointed, no matter the size or age of your new employer. I sense that people have more realistic expectations than Mr. Church gives them credit for, and the people I know in 2012 certainly do. A more appropriate title for his article would have been ‘Don’t Join a Startup with 1998 Expectations’.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful. You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.
Job Tips For Geeks 