Why you should work for a startup at least once(techcrunch.com)
techcrunch.com
Why you should work for a startup at least once
http://techcrunch.com/2014/09/20/5-reasons-you-should-work-for-a-startup-at-least-once
5 comments
I think it is better to work for a established company at least once
I get overwhelmed by people who never really had any respectful work experiences and started to call themselves Director/CEO/Founder
And surely they failed
I get overwhelmed by people who never really had any respectful work experiences and started to call themselves Director/CEO/Founder
And surely they failed
The advice in this article would make a lot more sense if the title were "Why You Should Found a Startup at Least Once", because working for a startup as an employee, even a fairly early employee, really isn't all that different from working for a larger company. There are more changes in direction, that's all. But you're not the one calling the shots on the changes, so whatever.
(I've worked as a junior employee for two startups, one about a year in with ~10 employees and the other about five years in with ~100 employees.)
(I've worked as a junior employee for two startups, one about a year in with ~10 employees and the other about five years in with ~100 employees.)
> because working for a startup as an employee, even a fairly early employee, really isn't all that different from working for a larger company
How so? Typically with a large company an engineer is exposed to a variety of stakeholders, such as other engineers, designers, DBAs, product managers, project managers, program managers, engineering managers with more or less clearly defined roles.
At a startup a bunch of those roles are usually conflated, and without prior experience during the growth phase it's pretty hard to make a statement like "we need to hire a project manager, we're spending too much time on ad hoc project management" or "it's time to add a product manager into the team, product is becoming too big to be managed via email/chat".
Without exposure to such clarity of roles, most of the teams just go with the flow, passively-aggressively protesting the amount of busywork that's suddenly their responsibility.
How so? Typically with a large company an engineer is exposed to a variety of stakeholders, such as other engineers, designers, DBAs, product managers, project managers, program managers, engineering managers with more or less clearly defined roles.
At a startup a bunch of those roles are usually conflated, and without prior experience during the growth phase it's pretty hard to make a statement like "we need to hire a project manager, we're spending too much time on ad hoc project management" or "it's time to add a product manager into the team, product is becoming too big to be managed via email/chat".
Without exposure to such clarity of roles, most of the teams just go with the flow, passively-aggressively protesting the amount of busywork that's suddenly their responsibility.
In the smaller startup I worked in, there was already a formal hierarchy. We had a VP of Engineering, two lead engineers, and what amounted to a QA lead and a data architect. And all engineers worked mostly in their own areas of responsibility and expertise.
The difference was that most of these senior people did quite a bit of grunt work that in a larger organization would have been delegated. The VP did a lot of program manager work and the leads did a lot of design and development, since they only had a couple of subordinates each.
But because the roles and hierarchies were established, it was usually clear whose responsibility it was to make any particular decision. We had on paper a formal organization suitable for a much larger team. We could have telescoped out to three times the number of engineers without adding any more senior people; the leads and VP would just have spent more time on leadership duties and less on direct implementation. I suspect the presence of the formal hierarchy was why the organization felt very mature.
Are things different in other companies of the same size?
The difference was that most of these senior people did quite a bit of grunt work that in a larger organization would have been delegated. The VP did a lot of program manager work and the leads did a lot of design and development, since they only had a couple of subordinates each.
But because the roles and hierarchies were established, it was usually clear whose responsibility it was to make any particular decision. We had on paper a formal organization suitable for a much larger team. We could have telescoped out to three times the number of engineers without adding any more senior people; the leads and VP would just have spent more time on leadership duties and less on direct implementation. I suspect the presence of the formal hierarchy was why the organization felt very mature.
Are things different in other companies of the same size?
So true. I fell into the trap of believing that working at a startup would be extremely beneficial to me as a fresher. That was the worst career decision I made, consequences of which I need to bear even till today. Meanwhile, I see multiple acquaintances who started working for large companies, gained some reputation and network and are doing well as startup founders or as leaders in startups (well paid, lot of authority) now.
I don't agree that all of these are exclusive to startups. In my experience, smaller, more laid back companies generally hit most if not all of these points. The company I'm currently with certainly does, except maybe #5, and it's been around for a couple decades.
To me this reads more along the lines of "5 reasons to work at a small company", and #5 is the only one that's more startup-specific, though there are companies out there that provide that too, and are not startups.
To me this reads more along the lines of "5 reasons to work at a small company", and #5 is the only one that's more startup-specific, though there are companies out there that provide that too, and are not startups.
It's not even that. I've worked at a large company, but which ensured that small -teams- were given responsibilities and empowered to get things done, and these all applied. In fact, transitioning from that, to a startup, was a rather depressing experience, all the good in a startup I had seen in an enterprise environment, but much of the good in an enterprise environment (such as domain experts, full time IT, HR, etc, to handle issues you don't want to have to get sidetracked on) was lacking.
Just be wary when learning so much, so quickly - quantity vs. quality is a very serious concern in this arena.
I agree, but that's something you really want to learn about anyway. To quote from a job ad I once came across: You'll "know when to hack and then to engineer". I guess knowing this is one of the most valuable things as a programmer, as I constantly see people (including myself) failing on that.
The fact is, if you choose to start your career working for a startup, you will likely work for a failing one. That can be a more valuable lesson than working for a successful one.
Established companies have largely weeded out inefficiencies, problems with product-market fit, and so on. If you work for a startup, you will learn very quickly why you don't see the "startup culture" in mature companies--at least not all the bells and whistles associated with a startup--because it doesn't work. Letting employees work from anywhere when the company has no sense of direction doesn't work. Paying for meals 3x a day for the whole staff when there's no bottom line revenue because the CEO would rather be photographed with a celebrity than make a sale doesn't work. Giving entry-level employees right out of college the power and responsibility to distract the company from its core mission doesn't work.