Hacker News Reader

> Implicit in my previous comment is that, because it's harder making things move in Big Corp one tends to learn more, both as an engineer and as a human. Finding the right technical path through a heavily used, critical system is an interesting challenge, and evolving legacy systems, or spawning new work in a large org requires lots of communication, as well.

Unfortunately the peril one often encounters in such ecosystems is that "the right technical path" for working with BigCo's system is totally un-translateable to general working knowledge. By that I mean it often means having to work around specific constraints that have evolved and are specific to that BigCo and not to other BigCo's, let alone to smaller startups. It also pushes you to generally work with technology which may be a bit older, which can often mean having to accept that current best practices simply aren't at play.

I do agree with the second part of your thesis, which is that the social challenges of working in a big company are significant and can make one very well suited generally for management and leadership in a way that's not the case at a smaller company.

> the peril one often encounters in such ecosystems is that "the right technical path" for working with BigCo's system is totally un-translateable to general working knowledge

Having also seen many start-ups fail because they prioritized the right technical path over product-market fit, there's a balance that's generally unappreciated by both pure managerial and pure technical types.

What you learn is not the path, but how to find a path. And that - finding a path in an environment with lots of constraints - is an invaluable skill.

It could also pay off to be a specialist instead of a generalist though. Depends on what you want to do. Say if you become an expert in large scale distributed systems or some cutting edge AI techniques which require tons of data, which only big companies can afford to have, you'd still be very highly valued and probably better paid than the millions of generalists who can set up a normal software system. You'll become indispensable. On the other hand if you want to start a company yourself later, then being a specialist wouldn't help.

Larger company that is trying to keep startup mojo is special kind of hell - mostly due to ugly politics that emerges. You cant manage small group of people the same way as big one and vice versa.

> The restrictiveness of big company jobs is particularly hard on programmers, because the essence of programming is to build new things.

I dont think we should devalue maintenance and maintenance programmers. I know it is popular, especially among those who want to convince programmers to go to startups, but that is exactly what it is.

omg, yes and yes! Large companies should assume the fact that they're large and maintenance engineers are my heroes.

These folks are in the hardest spot in large orgs because they perform hidden feats of heroics all the time, yet they're typically only noticed when things go wrong.

For anyone interested in the importance of maintenance I highly recommend the article “Hail the maintainers (Innovation is overvalued)” and the Freakonokics podcast episode that builds on the article. I gained a new appreciation for maintenance from them.

[1]https://aeon.co/essays/innovation-is-overvalued-maintenance-...

[2]http://freakonomics.com/podcast/in-praise-of-maintenance/

"Larger company that is trying to keep startup mojo is special kind of hell - mostly due to ugly politics that emerges. You cant manage small group of people the same way as big one and vice versa."

My company is on that path. It's merging the bad parts of startups like overambitious deadlines and lack of organization with the bad parts of big companies like bureaucracy and lack of flexibility. Management seems happy but from a worker's point of view we have relentless pressure to deliver mixed with a huge layer of politics. It has become really unpleasant over the last few years.

"lack of organization" and "bureaucracy" ... You work for Vogons.

We have a lot of people who can say "no" but much less people who say "yes" and help to achieve things.

Just because you're working on a system that is already in place doesn't mean that you can't do new things. The refactoring is "new work"

> Finding the right technical path

Often it is more about the right political path. Getting something approved like you want it to can mean months of back-channel work to make it become other people's idea.

I don't think it's just "new things", in my experience corporates go out of their way to stop you building anything. Compared to working for yourself it's like wading through treacle trying to get anything done. The only time I found it easier was when I was consulting but even then it was hard.

You certainly will learn more about the politics in a large company but from an engineering perspective you tend to get pigeon holed. You will learn a lot about a very narrow area. Working in a small company gives you a much broader experience, both of the technology and business. I remember a famous poster from this community describing a purchase order as an exotic method of payment. Nobody who has worked for a scrappy startup would think that.

Ultimately though it comes down to horses for courses. You clearly thrive in a big company environment, I definitely don't.

> You will learn a lot about a very narrow area. Working in a small company gives you a much broader experience, both of the technology and business.

I think this is a reasonable generalization, though organizations can fight this tendency. I tend to think we do, though we have very specific initiatives to tackle this very problem.

> You clearly thrive in a big company environment, I definitely don't.

So “thrive” is a bit of a strong characterization, but I can say I’ve pretty well adapted to my current environment.

Please also don’t let me lead anyone to believe that everything is perfect in Big Corp land (here or anywhere I suppose). As you hint at, it’s all about the trade offs you’re willing to make at any given point in your career.

I guess that’s what I was mostly trying to point out in my original comment.

Good post. But I’ve definitely learned more as an engineer from architecting greenfield systems from scratch vs working at a big corp where I had no say and often no need to know about large parts of the architecture I was dealing with, since I was just tinkering on small cogs in a huge system. (Very impactful tinkering, mind you.)

Thanks! And in rereading with your comment in mind I should probably have moderated my "learns more," to something more like, "learns different things, but not necessarily less."

I have the reverse experience : I did tons of technically challenging greenfield projects that were pretty much using my IQ, and didn't start building skills and work habits (the stuff employers actually pay for) until after I was made to also maintain one of the greenfield projects.

I haven't and will never be what people tend to call a purely maintenance programmer, but the parts of my job that interact with existing systems are more challenging, more important, and teach me more (from looking at the patterns in existing code) than the greenfield parts.

Where the misconceptions come from is it's easier to be "good enough" when you do maintenance, so a lot of people don't try to understand the existing context, don't interact with non-technical people, and don't stretch themselves to understand the business, because they mistakenly think their job is writing code.

When you build products with a shelf-life of 6 months, you can go crazy, cut corners, don't write tests, etc.

When you build products with a shelf-life of 6 years, you care deeply about reliability, and maintainability.

When you have low scale, problems are small. When you have large scale, code gets complex because you can't afford to be inefficient

Most products with a shelf-life of 6 years, started as one expected to have a 6 months shelf-life...

The conversation usually goes "just deploy it now and we'll fix the bugs later".

> I've managed from 2 (and was therefore an IC) to ~40 people.

~40? I'm assuming you're counting your skips. If so, a better word to convey what you meant would have been to say that you were directing them, to indicate you had skips and were actually managing a half-dozen or so managers. If not, how does one manage to keep track of ~40 relationships (plus other colleagues) in a 4\b80h week?

At one point I had a boss with (roughly) 50 direct reports. To paraphrase him describing how he did it: "badly".

The company later was able to hire more managers and take the load off of him (and in fact he went back to being an IC eventually). But these things happen in periods of rapid growth, despite everyone knowing they're a bad idea.

I’ve never ever heard a manager describe the people they’re managing without counting the full tree below them.

> In a large company I think the major stress is knowing whether you still have a voice that carries any weight.

And whether your voice will do any good in general, even if people listen to it. The organisational mass of a big corp is ridiculous. You can spent your entire day pushing and only manage to shift the course a few meters.

> probably going to learn more doing the startup

This jumped out at me, too. Learn more about what is my immediate though. Working in a large company you will learn a lot about project management and navigating through existing systems, structures and so on. Less glamorous than what you might learn at a startup but IMO no less useful.

Having done both i wouldn't categorize the work you do at a startup as glamorous. A lot of the jobs and tasks you'd never be asked to do at bigco become the responsibility of everyone at a startup out of necessity, not efficiency or choice. Things like covering a support phone, or training users or marathon sales trips.

I'm going to cowardly agree with you both, simultaneously: the potential to learn in a startup vs big business is great, but you will learn radically different things.

I feel like it is a horses for courses situation where some people will thrive in one environment and flounder in the other.

Different kinds of burnout in both environments, too.

What do you do if you think your voice does not carry any weight while working at a growing startup?

Is it regarding product or code? Perhaps try changing how you deliver the message. Ultimately if its an issue of your peers not respecting you and therefore tuning out your message well that is almost impossible to overcome.

> the author

You're on HN and you don't know who Paul Graham is?

I do know who he is. I just chose to refer to him as the author ;).

That's a very good attitude. It's never a good sign when someone judges arguments based on who voiced them.

Using the term "the author" is better because the article was 9 years ago, Paul Graham doesn't necessarily hold the same beliefs now.

I wonder how one would structure a big company to keep it more agile. Some thoughts:

- Salaries would be lower, so that people coming for the money wouldn't. There's be more variable pay. This will eliminate the "who cares if the product fails? I get a big paycheque anyway" attitude I've seen in a big company.

- When a product fails, each individual on that team will have something to lose: skin in the game. Maybe he won't get a bonus. Or will get paid less next year. Or gets demoted one level. Or something.

- Each VP would have the flexibility to pay his team the way he wants. The only thing he'll be held accountable for is the results. No salary band for each level, etc.

- He'll also be able to hire people he thinks are better. Maybe people who've been a founder or early employee of a startup more than people who've worked at other big bureaucratic companies.

- Engineering practices won't be centrally enforced, as they're in some big companies. If a team believes that unit testing every class, or code reviews that drag on for weeks, or <insert other practice here> have a low ROI, they'll be able to choose different practices. Maybe each (S)VP would get to define his team's practices.

These are just ideas. Maybe you can come up with better ones.

What would you to do to make a big company more like a startup?

- Seriously, having lower salary does not make people care more. There are plenty of lazy people who don't care who are not paid maximum possible.

- You will have people unwilling to work on risky projects. Good engineers assigned to troubled projects will be resentful more then normally and leave faster.

What if employees were offered a substantial degree of choice in which projects they're assigned to. At that point, risky projects would need to have commensurate rewards attached. Does this solve the problem?

Valve, for example, seems to take this sort of approach, and while it's not without criticism, it seems to work okay for some people.

That will attract gamblers and repulse systematic workers who care more about craft itself and less about estimating, choosing and negotiating projects.

> Seriously, having lower salary does not make people care more.

It does, when coupled with variable pay they could lose if their project doesn't work out.

> There are plenty of lazy people who don't care who are not paid maximum possible.

And those lazy people will then find jobs at other big companies, where they don't have to work hard and still make more, more appealing.

If you’re working for below market rate, you might be passionate, but you’re still making a poor decision. Don’t let emotions sabotage your financial well-being.

Do you realise that you've argued that nobody should choose to work at an early-stage startup?

Your salary is below market rate, but not when you include variable pay, in startups, and in my proposal.

Yes. Nobody except founders should work at an early stage startup. Anyone else is likely throwing their time away at below market rate. Remember, most startups fail. You're advocating for treating the job as a lottery ticket. Might as well make market rate and invest in companies where you have better information.

That's your opinion. There are people who'll accept lower salary and higher variable pay, and for them, my suggested option is no worse than working at an early stage company in terms of risk. Actually slightly less risky, since they don't have to worry about the company going bankrupt, they'll have a comfortable office space, a prestigious name on their resume, their relatives will be impressed by it, etc.

That honestly sounds like a horrendous place to work. Paying people below market rate is exploitation, and making people work with a Sword of Damocles over their heads is a good way to increase the suicide rate.

Do you realise that you've described early-stage startups?

...and those are companies I have no desire to ever work for.

I tried it once. The company was an abusive hellhole, and I'm glad I got out.

Edit: Also, if you're working at an early-stage startup and making below market rate, you better be a founder or your employer is screwing you over.

That's your opinion. There are people who're willing to earn less salary and more variable pay, and those people would be fine with early-stage startups and with my proposal.

If you're going to do that, why bother having the big company at all? You've just described a startup - why not just go start a startup where you get all those conditions yourself, and also cut through a lot of bureaucratic & legal red tape and get to enjoy the full fruits of your labor.

If you're worried about risk and spreading your bets, why not start a venture fund that invests small amounts in lots of little startups and takes a percentage of the success, the way YCombinator does it?

You're going to have big companies, anyway, so why not make them more productive? My proposal includes variable pay, so you can enjoy the fruits of your labor more than you can in today's big companies like Microsoft and Google.

This is kind of like asking what would you do to make a donkey more like a zebra?

You can paint some stripes on it but it's still a donkey. They are fundamentally different creatures.

You can instill some startup practices at a bigco, just like a start up can benefit from some organization and structure, but they are not variations of the same beast

You're lost in your own analogy. Big companies are going to exist, anyway, so can we make them more productive?