- Process is not the enemy, inefficient process is the enemy
- Project Management makes a huge difference
- Technical people make for bad managers
- Communication is critical, ego only creates conflict, learn to pick your battles, don't sweat the small stuff: how to deal with your work and other human beings
- Perks are the last thing you should worry about
- When nobody cares, everything turns to shit
- Not centralizing/simplifying management of resources makes everything take a lot longer to get done
- Salaries are arbitrary and 2 weeks of vacation is total bullshit
- Health insurance for non-corporate people is expensive
- Unless you want to fix the same problem twice, do it better the first time
I think the "technical people make for bad managers" idea derives from:
Companies which have limited advancement opportunities within the technical realm force technical folks with no desire for management into management positions that they're unfit for, leading to the conclusion that technical people are bad managers.
The company I works for has a great solution to that, it allows people that want/deserve to move into management paybands (they leave the union), but stay in their technical roles. The become managers without direct reports. Career / Pay advance, without having to take on managerial responsibilities.
Are you a Software Engineer in the United States? I've never heard of unionized programmers (at least within the Bay Area, which I shouldn't presume you're in.)
No I'm in a western province in Canada. Most government or publicly traded companies here have massive unions that represent the majority of the work force, including programmers.
In my experience, technical skills and management skills are orthogonal. Many technical people, however, are pushed into management because there's no comparable career path strictly in technology. Organizations then pay twice: the opportunity cost of losing a good technician; and the much, much more damaging cost of a bad manager.
Yeah like the article states, you get to look at the complete picture and can make your own - multitude of conclusions can be narrowed to a certain subset when running a company and have a decision to make.
Often you end up burdened with expensive corporate-friendly technology as well as "official internal tools" which are in every way vastly inferior to open source stuff but you have to use them because that's what the company has chosen to use.
A great example in this vein is sharepoint. Other examples might be, say, team foundation as source control versus git, or IIS vs nginx, etc.
What's a better, free open source alternative to SharePoint? I don't disagree with the point but I would be surprised (and interested) if there was a open source alternative that compared to SharePoint.
My experience is limited, but the source control aspect of TFS seems really crude compared to git. Branching is about as hard as an old-school Perforce or CVS repository, but without the flexibility in managing your local changes that those systems allow. It only lets you keep one changeset active at a time, which can be hacked around using shelvesets, but not without occasional hiccups (TF Power Tools are often the only way to recover your work after particular kinds of operations).
I've found that every workflow I can come up with is "wrong" in some way, but none of the documentation tells me what the "right" way is. Git may have been in a similar place when it was first released, but nowadays there are plenty of good tutorials that walk you through the way to think about it.
The GUI is clunky and requires lots of clicks to perform routine tasks. For example, to view a file's history, you need to open each changeset individually and diff the file in each one. The command line is no better, and makes heavy use of the "observe something to initialize it" anti-pattern.
The main draw seems to be its integration with issue tracking, unit tests, code reviews and project management. It's trying to be a one-stop shop for everything, but the problem is that each feature has a better stand-alone equivalent. So you either lose the synergy of having one tool for everything, or you sacrifice the features that you really want from your favorite source repository, code review tool, diff utility and bug trackers.
This has become quite a rant, but I'd really like to hear a good explanation for some of these things, or at least somebody to tell me what I'm doing wrong. The worst is when somebody knowingly says "come on, it's not that bad" without actually offering a more functional workflow.
Realistically I'd have to consider myself pretty close to an expert in TFS, although I'm sure there's a ton I don't know about it.
Overall, TFS, as a source control system, is pretty decent, definitely in the top few of the best source control systems out there. However, it has a lot of downsides. It's a serious pain to administrate, and an even bigger pain to initially set up. It has a huge number of "quirks" that are really just misfeatures or defects for most users. For example, binary files are exclusive checkout by default (meaning only one workspace can have a specific binary file editable at any given time) which seems like a good idea naively but tends to bite you in the ass almost always in any real-world example. And most TF admins aren't smart enough to know how to change the setting for it, as far as I've seen anyway. Also, access control is like pulling teeth, you'd think it should be easy-peasy given that it's all GUI based and what-not but it's crazy. Similarly, things like triggers can work in completely non-intuitive ways that are really easy for, say, a moderately trained dev who's trying to be a part-time admin to screw up in ways that impact a huge amount of people very quickly (which I've seen happen routinely).
There are some nifty features, like shelvesets, and it supports a reasonable branching model with a reasonably decent merging system, though if you use it long enough you'll probably eventually run into one or another nightmare scenario that takes a long time to figure out.
For most projects I wouldn't recommend it over, say, git + github/gitlab or other free source control options. The one advantage that TFS has is that it's far more capable of handling extremely large code bases (e.g. hundreds of gigabytes of data, millions of files) as long as it's configured well, whereas git will pretty much just choke.
Also, the Visual Studio integration of TFS is pretty good, so if you use that as your primary IDE TFS will have a moderate advantage in ease of use. Of course all of this scales to how skilled you are with using source control at a low level anyway. If you're a dev who has zero interest in learning anything more than "checkout/checkin" and you hope that merges and branching and whatnot are handled by people who are not you then TFS is pretty much right at your level, it's definitely super easy to use for those common cases.
> "Salaries are arbitrary and 2 weeks of vacation is total bullshit"
Could you expand more on what you mean by the vacation stuff? Do you mean like it's total bullshit that you only get 2 weeks? I was not sure how literal to take that.
I suspect that's what he meant. In a small company two weeks is often all you'll ever get, if that much. In a large company you'll start there and pretty quickly get to three weeks, and if you stay long enough you'll get to 4-5 weeks.
This is in the US, of course. In a humane country you start with 3-4 weeks, and I think after a couple of years in some European countries you get around six months of vacation per year ;-)
I work for a University, and albeit having a slightly lower starting income than some private industry, my starting vacation time is incredible. I accrue just about 2 days per month paid vacation time. Besides regular holidays, I also get school holidays off too. 10 work days for Christmas paid. 5 work days for Spring Break paid. And I get 1 full day of sick leave per month that gets accrued too. It's fairly gravy.
I make iOS apps, and contribute to fairly large state-wide systems. Besides rote governmental/enterprise work, I also get to fool around and make interesting things because my role is also technically a "research" position. Did I mention I see/talk with my supervisor about 4 times a month, and he trusts me totally?
All that's awesome and everything, but there are downsides too. I am considered Junior, and will be for the next year (been there a year already). I make less than some of my coworkers despite being able to code circles around them (and architect systems better). Others are really, really damn good, so that's not always the case either Part of the problem is my degree - I have a Bachelor's in Art (of Arts too, but you see my point). This means that I'm fixed for at least the next year below my actual value, which sucks. My direct coworkers on the Mobile team are awesome, my age, share liked interests and we share a camaraderie that is probably absent at a lot of big companies and startups alike. Tradeoffs abound, but personal happiness and autonomous professional development are what I'm taking for the time being.
Don't sleep on BigCo or unusual positions just because it isn't sexy startup land in SV. There's a whole wide world out there too.
I didn't write that, but my guess is that it was literal.
I've seen and personally worked at a company where 2 weeks was not only your vacation time, but also your sick time as well. A government contractor I had worked for gave out 4 weeks (which was also sick time). Currently, I'm at 3 weeks.
Most places use vacation as an incentive - stay with us x number of years and we'll give you another week of vacation. I personally haven't stayed at a place long enough to realize that benefit.
This always seemed weird to me. Like, you can be a senior software developer with 15 years of experience, and if you get hired at a new company they'll only give you 2 weeks of vacation to start? Really?
It takes about a week to prepare for a vacation and about a week to recover. Trying to fit "okay, everybody: three, two, one, FORCED FUN TIME" into short time periods is more annoying than entire trips are worth.
Companies strip away between 1/3 and 3/4ths of your personhood (depending on the person) and autonomy in the world.
Speaking from a non-IT standpoint (mech engineer, rail industry), BigCo offers a number of cool benefits that I'd not get working for SmallCo (that may or may not hold analogous to the IT sector in some cases):
- Economies of scale #1: when you're purchasing 10,000 instances of something, people listen and new techniques of doing things become available.
- Economies of scale #2: Design changes when milking an extra $100 out of the design or manufacturing process means saving $1m at 10,000 instances. You get exposure to new design/manufacturing techniques as a result.
- Project diversity: I could find 20 projects in this office of 150 engineers, all significantly different. They range across design, asset management, PM work, maintenance/reliability, acquisition, etc. Each applies to a number of different targets - fixed plant, mobile assets, facilities, etc. If I grow bored of something I can reasonably rotate to something new and different within 6 months. More long-term, there's opportunities in multiple countries if I so wish to pursue them.
- Institutional knowledge: I can walk in to our drawing room and still find drawings dated from 1870. Some of the greybeards here seem almost as old, and come with a huge amount of knowledge (both specific and simply general 'tricks of the trade') that isn't recorded anywhere.
There's also downsides:
- Work sometimes feels like it's a game of thrones. The fiefdoms can grow tiring.
- Stuff happens slowly. BigCos carry inertia that can be cumbersome. Counterpoint: inertia can produce some amazing results if you get everyone paddling in the same direction
- Career advancement usually requires jumping ship to different companies. Said greybeards are in it for the long haul and unless a new position opens up, you're generally stuck below the glass ceiling.
One reason why one goes to college is to learn how to learn social acclimation around people wealthier than you are, because this is a useful skill in convincing them to give you things that you want. A company, and the decisionmakers thereof, is almost by definition richer than you are, and broadly representative of an entire class of entities whose behaviors are totally opaque to you if you've never worked in one (+). That would be unfortunate, because those entities have budgets and are willing to spend them on you if you know how to work with them.
+ People who have never worked in a megacorp often think that their literal internal decisionmaking model is "MAXIMIZE THE EVIL.", which is both wrong and will not allow you to successfully predict their behavior.
Are there one or two things you would recommend to help bridge that communication gap between a solo person and a megacorp? One thing I've observed (possibly incorrectly!) is that megacorps seem to "like" to do business with other megacorps.
Rule #1: all megacorps are, like Soylent Green, made out of people. If you want to sell something to Microsoft, you aren't selling it to Microsoft, you're selling it to one or a few identifiable people within Microsoft. The entity we think is Microsoft is the sum of the emergent behaviors of lots of little Microsoftite particles which are bouncing around in Brownian motion.
After you understand that, it's VASTLY easier to get Microsoft to give you money, and you might find that Microsoft (or whatever BigCo) you're dealing with considers More Money Than I've Ever Dreamed Of (TM) to be a fairly routine decision, in the same manner that you might decide to purchase a new keyboard.
In terms of communication style: learn to talk to business people. ROI and TCO over TDD and DRY, PowerPoint decks over README.md in your Github projects, wearing a suit when appropriate instead of making fun of people who own one, etc etc. It's really not hard to learn how to talk like someone if you listen attentively. You've done this your entire life in other contexts and other communities. Decisionmakers at BigCo are not intrinsically a more hostile audience than, e.g., your local freestyle rap club meetup thing, the rhymes are just different, yo. [1]
[1] I should stick to WoW metaphors, but you get the general idea.
I'm in the process to write a book about this. Are people (young people especially) interested in understanding how to position technology into the enterprise?
"One reason why one goes to college is to learn how to learn social acclimation around people wealthier than you are, because this is a useful skill in convincing them to give you things that you want."
This is probably one of the hardest (and most valuable) lessons I have learned in college. If you don't take the time to develop your social skills, life is going to kick you in the teeth. Repeatedly.
Say what one will about Microsoft, I probably learned more there than anywhere else. Source control and how to branch/merge at scale. How to work cross-team relationships. How to work with people much smarter than I'll ever be. How to do a little political wrangling when necessary, and a bunch of other things I've probably forgotten.
Having worked at several small companies since, it's disappointing how often I get to watch teams find out the hard way why things are done this way, or not that way. Sure, I will point out the potential folly along the way, but few care to hear it, and instead wish to invent their very own wheel because their case requires a special kind of roundness.
It sounds like our experiences at Microsoft could hardly have been more different. Virtually everything I learned at Microsoft could be filed under "whatever you do, no matter how desperate you are, never do it this way". The systems were unreliable, inefficient when they worked, and the number of person-hours routinely wasted on tool management was staggering. The culture was unhealthy, competitive and individualistic, sometimes to the point of hostility. You saw cross-team communication, I saw at least a quarter of every working day wasted in routine status meetings, in which two or three of the ten or twelve people present spent an hour making a couple of decisions while the rest of us tried not to look too bored...
Of course Microsoft is a big place and different divisions work differently. I'll never take the risk of landing in such a mess again, though.
> I saw at least a quarter of every working day wasted in routine status meetings, in which two or three of the ten or twelve people present spent an hour making a couple of decisions while the rest of us tried not to look too bored..
That sounds horrible. Did you mention your concerns to the people who owned those meetings, in a way that made it clear you were trying to help improve them?
I've had success several times with this in BigCo, with various satisfactory outcomes:
1. "You're right, this meeting is BS! But it has to happen for various reasons X Y Z -- since you don't care about this area you don't need to come, we'll grab you if we need you."
2. "You're right, and other people feel tuned out as well, so let's try cutting it to 10 minutes / mailing out an agenda beforehand / starting exactly on time."
3. "You're right, this is an inefficient way to gather state so we're going to just swing by each person 1-on-1."
4. "You're right, this team is too big so we're splitting in 2/3 smaller groups"
No, I never did. It just seemed to be an accepted part of the institutional culture, and I felt like fighting against it would have only made me look like a complainer. Maybe someone with more status could have tried it, but I was just a newbie and nobody seemed to care what I thought.
I think the project I worked on was worse than average because it was the sort of cross-cutting change that affected a lot of different teams - six different products, I think? There were a lot of PMs involved.
I'd just like to add that pointing out seemingly mundane things like these are what allowed me to move from engineering into the consulting team at my company (which is what I wanted).
It's worth testing the waters a few times. You'll know pretty quickly if they value your input, and if not you can decide if you want to continue working for them.
Gah. Sorry, No. My experience has been the opposite.
In particular:
"You see lots of very good ideas (like proper source control)" - you mean the group that still uses VSS 4.0 on a network share b/c they're terrified of moving their repo to Git (or even SVN)?
"You get to work with lots of clever people" - no, you get to work with people who work there for no reason other than they live close to the office and have spent the last 14 years building an impenetrable fortress around themselves.
"They have lots of perks" - Yes, that one day a year I got to donate $5 to cancer research so I could wear bluejeans (collared shirt still, of course) makes it all worth it. I'll take my catered breakfasts, lunches, impromptu beer runs, work-from-anywhere policy and unlimited vacation days, thank you.
"You are not going to be sent on that week-long training course on using Oracle or have your part-time MBA fully-funded while at that boot-strapping startup." - Ok, starting to think this is a case of Poe's law in action...
Yeah startups (and small companies) come with their share of headaches, but I'll take it any day over the soul-crushing, creativity-stifling cubicle hell that is a big company.
"You see lots of very good ideas (like proper source control)" - you mean the group that still uses VSS 4.0 on a network share b/c they're terrified of moving their repo to Git (or even SVN)?
Unsurprisingly, companies that have millions of lines of code have to take extra precautions.
"You get to work with lots of clever people" - no, you get to work with people who work there for no reason other than they live close to the office and have spent the last 14 years building an impenetrable fortress around themselves.
This is a lazy dismissal.
In reality -- lots of smart people work at big companies and small companies. That being said, big companies will invariably have more people dedicated to research than startups. Microsoft Research alone has over a hundred people just doing brilliant things.
"They have lots of perks" - Yes, that one day a year I got to donate $5 to cancer research so I could wear bluejeans (collared shirt still, of course) makes it all worth it. I'll take my catered breakfasts, lunches, impromptu beer runs, work-from-anywhere policy and unlimited vacation days, thank you.
Again, this is lazy and untrue -- unless you want to say that Facebook and Google's perk packages are about wearing bluejeans -- but I think playing the perks game is silly anyway. Distilling things down to money (with some exceptions, like WFH) is always the smarter way to go.
---
Personally, I think the biggest difference working at a big company vs. a small one is that of depth vs. breadth. At a startup, its not beyond the realm of possibility to understand the majority of the code base: you'll be wearing lots of different hats, doing lots of things at once. At a big company, the organization is usually such that you'll spend your entire employment working on one little niche -- this has its advantages (you become an expert at that one thing) and disadvantages (you're only an expert at that one thing, after all).
Personally, I can't imagine why someone wouldn't want to just spend time at both types of companies and see which one they like more.
You've answered what you describe as a "lazy dismissal" with what appears to be one of your own.
The big difference is that most "large companies" people will work at are not Google and Facebook. Name any other enterprise who's motto is "move fast and break things". That is a rare culture. Even Google, who's engineers report that they're catching a bit of the dread corporate-itis is still different from your average enterprise.
More commonly, enterprise is known for being a place where fast moving is discouraged, individuality is stifled, pointless bureaucracy is the order of the day, mediocrity is indirectly rewarded, and productivity and common sense take a back seat to political demands.
Fair enough. Of course, I am only drawing on my own anecdotal experience. However, the big companies you mentioned above, Facebook, Google, and Microsoft - I would propose that they are truly exceptional in "big company" culture. Like one-in-a-million exceptional.
Perhaps my experience in each world was exceptional, but I have a feeling they were rather typical.
Which is why they drive to work in a Model T and rely on an IBM 7090 for their backroom stuff, correct?
This is a goofy analogy. Whining that BigCo, Inc. won't shift their embedded "way of doing things" is like whining when it's not easy to up and move the Empire State Building... there's a ton of architectural complexities and in the end the building is still making money and housing people.
Not that I'm advocating the status quo just "because", but the reality is that big companies work via risk models that determine it's often better to stay with the SQ than move "forward".
In comparison, hopping around with tech in a startup is like packing up the RV and shuffling somewhere else... it's lightweight and easy to do so.
Yeah startups (and small companies) come with their share of headaches, but I'll take it any day over the soul-crushing, creativity-stifling cubicle hell that is a big company.
You'll take the startup experience you have had over the big company experience you have had. Crucial difference, there.
A lot of large organisations are quite aware of the world around them, and are entirely capable of taking the better parts of startup culture and absorbing them. I work for a big company, but on a small team (there is five of us) that is largely trusted to know what we are doing. There is no dress code, and I can work from anywhere if I so require.
On the flip side, I have many friends still in Startupland who are in working misery. Just because a company takes on the label "startup" doesn't magically make it a fantastic place to work- in some ways you could argue they're likely to be worse as there is considerably less oversight.
> I'll take my catered breakfasts, lunches, impromptu beer runs, work-from-anywhere policy and unlimited vacation days, thank you.
I have all of those perks at my 200 person company now, but with a fraction of the start-up risk. (Which may be a plus or a negative, depending on who you are.)
What it comes down to is every company is different, regardless of size; there are pros and cons to work environments of all sizes.
The main difference between working for a big company vs. a small company is that the roles tend to be explicitly defined and specialized at a big company. You don't need/get to wear as many hats as you will at a small company or a startup. Basically, instead of being a jack-of-all-trades / "full stack" developer, you might become an expert on one layer of a huge technology stack. This can be good, or bad, or mixed. There is more formal training and you can get deeper knowledge, but it's harder to get broad knowledge. It can be hard to change roles or try new things. Generally, I think learning "full stack" is preferable when you're young, and specializing might be better as you get a little older.
I worked for a fairly big company (100+ employees pre-acquisition) and I was able to develop a very broad role. I started as just a web UI developer, but soon helped design the deployment architecture of our entire runtime system and throughout my tenure I designed and implemented many of the services within that architecture. That included everything from DB schemas, custom XML databases, authentication servers, several mid-tier servers/services, as well as always being the lead owner of the UI.
What helped, I think, is that I was part of a small team in that big company. At peak we probably had about two dozen programmers, with 8-10 on my team. That's not much bigger than the team I'm on now in a tiny company where I also get to work end-to-end.
I disagree with specializing as you get older: there's going to be a tendency to do that, but it's the last thing you want to do. Never stop learning, never stop broadening your skillset. Sooner or later you're going to be a 40+ year old developer looking for work, and if you're a specialist you're going to be looking for a long time. As an experienced developer with a proven track record of adaptability you'll be able to justify the salary that you're going to want/need.
IMHO 100 people isn't a big company at all... two dozen programmers can still comfortably fit in a room and know eachother. My current company has 200k employees, we spend a large amount of time just looking for whoever is responsible for something...
When we got acquired we became much, much bigger. Depending on how you counted divisions you could come up with anywhere between 50 to hundreds of developers. A few of our projects involved developers coordinating across those divisions, but when I left they were still fairly independent most of the time.
I think the article misses on all the biggest benefits I had working at a BigCo:
1) You can actually get to work with a lot of companies. We acquired a ton of companies over the years, and I'd often go work in those companies post acquisition while it was still being run as a separate company. So these were smaller companies that were generally successful - you got to see a lot of different practices.
2) Once you are done learning a new job/role (or new company as above), you can easily get the opportunity to move to around to different departments or jobs. I personally did consulting, product management, engineering, architecture, sales operations and strategy (sometimes for the mothership, sometimes for the acquired companies).
3) It's not about smart people I wouldn't say - its about mentors. At a small company, there are just less senior people around, and they are often more focused on delivering. At a big company, more senior execs are really willing and able to mentor the superstars in their teams that make them look good. You combine that with moving about companies or departments, and you get a mix of different mentors with different styles and strengths.
4) It won't apply to everyone, but I personally must have evaluated 50 - 100 companies for M&A or partnerships. I know exactly how to analyze a business, where to look for skeletons, what works well/what doesn't, what a big company will look for (and what are red flags) in an acquisition, when you can/can't get a partnership and what you can use to your advantage in negotiations, etc. Will all be extremely useful skills when you're on the other side of the table.
Between the above things, you can learn so much. Stuff like the food/work environmental is so irrelevant compared to this.
Don't get me wrong - I have no intentions of ever going back to a big company again. But these were the big benefits for me.
I worked at startups before joining megacorp. I always thought I wouldn't like working at a big company but everything the author said resonated with me. At some point I can see myself going back to a smaller outfit but for now it's great.
What the author doesn't mention and what I perceive as a great plus are the tools and infrastructure I get to enjoy. We've got a lot test equipment, machine shops and technicians a smaller shop couldn't afford.
On the other hand, I keep hearing managers say "we have to be nimble, like a startup". I think that's exactly the wrong approach, big companies should approach big problems that startups can't tackle.
The biggest big company problem is the lack of focus slows everything down. The ability to execute is there, but the focus is not. Start ups will attempt to manage 20 products and services at once, and that feels like too much, where big companies attempt to launch 200 new products, 80 new services, 40 special partnerships, 750 pet projects, 380 special events, 30 broad initiatives, plus the CEO mandate of the week ... all while maintaining support for 3100 legacy products and acquisitions ... the result is everyone is very busy yet unfocused. Too much context switching at all levels, too many works in progress get blocked on waiting for other teams to contribute their part.
Second challenge of big companies: trying to keep up with all of the latest project code names which change on a weekly basis.
I guess it depends on your definition of "large." I worked at a large company (20k+ employees), and each department was like its own dysfunctional 50 person company: nothing got done, the technology was stale, and the perks were minimal.
I work at a medium-sided company now (~200 employees according to Wikipedia), and I love it. We have a great mix of technology and perks, and are all treated really well. I worked at a handful of start-ups during the first tech boom (and during the crash), and some were exceptional and some were meh.
I wouldn't rule out working at another start-up sometime in the future; it would just be one of the many factors I consider.
Normally I'd just let a post like this go, but that word "need" really rubs me the wrong way. No, I don't need to work for a big company, ever. I haven't yet, and don't ever plan to do so. Go away.
I learn an awful lot? Because I can't learn things otherwise? Come on.
I get to work with lots of clever people? No problem doing that now.
Large community? Ditto.
Perks? Uh... how does that translate to "need"?
You learn the art of politics. Great! What you're saying is, I need to work for a big company so I can learn something that's only useful when working for a big company. What?
You have time to reflect? Why assume that all small companies are balls-to-the-wall, 100-hour-week, venture-funded, Valley startups? Oh right, because this post comes from a fantasy world where the only two kinds of companies are gigantic Googles and tiny places filled to the brim with foosball tables, not actually the Earth where I live.
You haven't worked in a big company so not sure if you are even qualified to comment on this post in such language. If you previously had the experience in working for a bigger company and then mentioned these things - your comment would have been a lot more credible.
You don't know know what you are missing till the time you experience it. Dharmesh Shah is one of the more acclaimed entrepreneurs in the industry and I do believe his words more than someone who doesn't even know what it feels like working in an environment he is commenting on.
It would be nice if you could tell me what I got wrong instead of just saying I'm not "qualified" to comment. Maybe we just have different ideas of what the word "need" means. I've managed to go three decades and change without this, and don't see any obstacles to continuing. To me, that means I don't "need" it. I don't need to work for a big company to see that.
I have no idea who Mr. Shah is and don't really care. I am criticizing the article, not the author.
Probably "need" could be better replaced with "can and likely will gain loads of experience that is hard to get outside of big companies, that can illuminate and improve you work life (and sometimes personal life) for your benefit"
So, if your only gripe is the word "need," I agree. Your tone I think is a little reactionary though. There are legitimately valuable things to learn in an "enterprisey" environment (even if many of them are around what _NOT_ to do - you still learn something best by experience, not reading blog posts or books or chatting with friends or whatnot), and there are some surprising benefits, depending on your personality type (stability, sometimes pay, etc).
I agree there are probably interesting and good bits about working at a big company, and I'd love to talk about them. This article, however, does not, and it doesn't even get the conversation started.
Don't be naive. There are plenty of real benefits too, and it's all about weighing them. Hopefully if you get an opportunity at BigCo, you can remain open-minded and actually explore the opportunity before dismissing it immediately.
Do you ever plan on being involved in the business side of a transaction for a b2b business? If so, yes you NEED to... if not you can probably get away not doing it.
I worked for a time in banking IT & development at two large UK banks - both as a full timer and as a hired gun from a consultancy. I never wanted to but it happened out of necessity/luck. It was pretty dull work. That said I got a valuable insight into how these huge organisations operate, what makes them tick and how to communicate with them.
I now work for a small web hoster that focuses on hosting for businesses (SME and corp) and have done for a few years.
The eighteen or so months on the banking gigs (despite being dreary times) taught me a lot of non-technical skills that allow me in my current day job to deal with and onboard some customers that are fairly large organisations.
Unless you know how to communicate with large organisations, and often on their terms and with their sorts of business protocols, then the chances of your startup or small company landing a nice steady earner/gravy train from BigCorp are minimal. The only way to do this is to go and spend ~18 months on corp gigs - either as a full time employee or contractor. I wish I'd done it earlier in my career.
We seem to once again be visiting a weird alternate universe, where the only way to succeed is to either work for a big company directly, or work for a small company that works for a big company.
The biggest reason to work at a big company is that you can have an opportunity to work on "stuff that matters" fairly quickly and you get introduced to ways of dealing with processes around working with important things, which can give you skills and confidence you might not otherwise attain.
You're not going to acquire the experience of knowing what it's like to jump headfirst into fixing a build break during the runup to release on a billion dollar product unless you're working at a company that has a billion dollar product, of course.
Every CxO at every large company looks at startups as the model to emulate - lean, focused, full of feedback.
The benefits listed, every single one, are examples of overlooked, hidden or inefficient practises by the large company - practises they try hard to eliminate.
Do you think the CEO of Megacorp thinks that weeks "training" in Amsterdam was a good use of his money? Do you think he realises there are good passionate people trying to do good on no budget. If he found out he would either give them a budget or fire their arses for working in the wrong things.
As for your time for reflection ... screw that, reflect at home.
No - big companies are trying very hard to stop being a source of "informal" VC money, rest stops for the tired and weary or uncontrolled cash spenders.
I'm not sure when you last surveyed every CxO at every large company but I think some of them have moved on since then. After scores of aborted "internal startups" some of the more mature CxOs have realized that emulating startups is the worst thing a big company can do.
The dangers of informal VC money is another factor that drives experienced managers away from that strategy.
Put simply, large companies are inefficient at almost anything not utterly core. Look at Microsofts famous "the start menu took a year".
I would guess that projects of all stripes need some sort of escape velocity to fly by themselves. Things like initial enthusiasm, number of people who might be affected, likelihood of them complaining or ability to veto, degree of risk, reversibility - all of which means gravity at a large company is much higher.
As a current Lean Black Belt and 6Sigma Green Belt working in QI... I cannot agree with you more.
Still, some people just can't look at a rubric to help you organize your thoughts/analysis without dropping to their knees and worshiping it as the second coming of Christ.
Lean, 6S, TQM, CQI, not a single one of them has conclusively been shown to actually work long-term (post-6 months). But, on the bright side, it's a fantastic job for getting to see every last corner of operations in an organization. I'm using the position to learn the pain points of my preferred field, before going into start-up land to address their needs.
A large company (revenue > 100m) generating per employee profits in the million plus range?
A large company that is efficient, fast to react to threats and opportunities, can monitor and measure each and every part of its own behaviour in real time, and have that feedback passed to all employees
Just a company that is large acting like a well run small outfit
Over the years I have worked for both, much of what the author said is true, there are many things that are great about working for a start up,I would be preaching to the choir to mention them here. The one thing that got left out is the access to resources. Some of the projects I have worked on, just due to the scale, would have been impossible to do at a start up level, they just do not have access to that kind of capital usually. There are some things that are just too big to do that way.
You also learn what kinds of unmet needs there are in the marketplace. You learn how decisions are made, who the gatekeepers are, how budgets are allocated, and what frustrations exist with the current roster of vendors - not to mention building your network and credibility in the industry. Want to develop a product/service to sell to the ______ industry? Go work there for a year or two first.
The author's point isn't that big companies are better, just that it's a good experience to have. I worked for a public company post acquisition and it was a great learning experience (some good lessons, some "don't do it this way" lessons, but overall good). I wouldn't want to make a career working for big companies, but I think you're better off as a business person if you end up in one from time to time.
Now if you want some definitive advice on where not to work. Don't work for a husband and wife operated company, ever. There you will encounter the worst aspects of a lifestyle business combined with nepotism (especially the unfireable but totally incompetent spouse).
Otherwise spend some time in a combination of startups and big companies. Both have their strong points, and remember 90% of startups fail, so its not as if startupland is nirvana.
The biggest difference that appears to me is the lifetime and size of applications. I work on applications that have existed for a decade (and that's short, among our various application teams). Many of our applications are hodge-podged mixes of legacy and more modern technology.
Whenever we "rewrite" an application that has outlived any possibility of keeping it alive, we can't start from scratch: we have to continue meeting all existing customer needs. So even from day one designs are often bloated and frustrating. There is no "MVP".
Meanwhile at a startup you can "move fast and break things", and when an application starts to get stale either it can go away, or you can switch to another startup and begin fresh.
Had my own startup. Brought my lessons into a large company. Worked wonders as a result and proud to work with them. To this day, still learning a lot.
It's a valuable experience, but can be a very frustrating one to go through, especially if the company has internal power battles and little appreciation for the importance of technology.
> "And you will get a range of ages - let's face it, most startups reckon you are past it if you are over 23."
What? Not to disparage people my own age but that seems like hyperbole. Is this the image most people have of startups? Fresh out of college at 23 (a few months ago) I couldn't even find a decent startup (that I wanted to work at*) that was offering positions to new grads.
The thing to remember about "big companies" is that they don't just spontaneously come into existence at that size; with x-thousand employees, y-percentage of market share, and z-millions of revenue. They are grown, over years or decades, because they've done something right.
Worth keeping in our minds when discussing such topics, before passing them off as competitive or cultural failures.
Politics is one of the most valuable lessons learned at a big company. Although I work in a small startup, all the management is from big companies. Like any other startup, what's valued the most is getting stuff done. But I learned that shouting at the top of your lungs or bottling your emotions while being passive aggressive are the worst strategies in leading discussions.
I had to quickly learn how to present my argument in a non-confrontational way, get individual buy-in (and perspective) from all stakeholders before any meeting, and balance being transparent and forthright versus protecting your interests (it really helps that your interests aligns with company goals!).
To sum it up, "politics" IMO has made me a more effective leader.
I sincerely recommend working at a large University as an alternative to this. Instead of one large company it is a constellation of large companies. They are almost always desperate for more good talent, and in many cases the innovations you can bring to the table can benefit the entire community, not just shareholders and customers. Otherwise, all of these points hold true.
There are things to be learned at big companies, but it is very bad to say X is right for everyone.
Big companies have been good for:
- Providing training
- Formalizing feedback
- Introducing me to a lot of people
But they also:
- Stifle career progression ("We have you doing X, so we are sorry that you can't help on Y")
- Are not nearly as safe as their size would suggest
- Tolerate mediocrity
You'll probably make more money at a large company than at a startup unless you get in with single digit or better equity and you get lucky.
Other than that, I prefer the creative chaos of startups to the process and tools over interactions and individuals of large companies (even the ones that pretend they're agile)...
I really grok this article. One thing that I found was that after learning to navigate office politics I really didn't like it. I made it a point in subsequent jobs to get a feel for what politics are like and if they seemed to be too toxic to avoid the company.
The point of the article is to say everyone should have experience working at a large company to get perspective. The same thing can be said for small startups. The debate over which is better is endless and childish.
You get to work with smart people? How is that unique to bigger companies? In fact, I'd say it's more unique to smaller companies, that have to be more selective with their hiring process.
- Process is not the enemy, inefficient process is the enemy
- Project Management makes a huge difference
- Technical people make for bad managers
- Communication is critical, ego only creates conflict, learn to pick your battles, don't sweat the small stuff: how to deal with your work and other human beings
- Perks are the last thing you should worry about
- When nobody cares, everything turns to shit
- Not centralizing/simplifying management of resources makes everything take a lot longer to get done
- Salaries are arbitrary and 2 weeks of vacation is total bullshit
- Health insurance for non-corporate people is expensive
- Unless you want to fix the same problem twice, do it better the first time