Comment by GloriousKoji | Hacker News Reader

Comment by GloriousKoji | Hacker News Reader

Parent Full thread

I also worked for Apple and I had a very similar experience. Management was brutal and abusive from my immediate manager to all the way up to and including the VP level. For example even though vacation hours were accrued I never got to use them unless I wanted to endure the verbal backlash of abandoning the team and my responsibilities. When the holidays came around the director would email everyone reminding us there's a stipend for working through the holidays but in reality it pays less than our normal salary and was a means to justify not taking time off. A variant of Stockholm syndrome made me appreciate the clever design of having a convenient cash out vacation days button.

In the end the team was meet with a hostile takeover; everyone was merged into another team working on something similar with new management. Meet the new boss same as the old boss. A good number of people ended up leaving the company shortly after that.

One more thing, you can also include me as another data point for getting pay doubled after leaving Apple.

Wow reading all these stories about Apple really is eye-opening, as I've only usually heard these types of things about Amazon before.

I say that because I work for Amazon, and my work environment is pretty bad by my standards (my team cuts a lot of corners, we are given unrealistic deadlines by upper management, our on-call is paged at least 10 times a week, we have a huge backlog of tickets and bugs that we can never prioritize, and it is overall a very stressful environment.) I guess it can always be worse...

> everyone was merged into another team working on something similar with new management. Meet the new boss same as the old boss

I worked for Apple before Jobs died. He'd frequently have several teams working on the exact same thing, in secret, and then pick the team that met his goals the best. Sometimes the "losers" would be merged into the "winning" team, but never treated well by the winners.

Gosh - I hope that isn’t a prerequisite to greatness?

How does someone even get the human and financial capital to run projects like this? I guess your first attempt with the first founding team has to ‘hit.’

Otherwise, how can you afford to triple headcount, management, etc?

I suspect that abusive behavior is an optimal strategy if you're working for abusive people. Organizations tend to be set up such that people like the people in power succeed.

Jobs was a notorious jerk [1] [2] [3], so it's not surprising that similar behavior is what gets promoted.

[1] https://www.ibtimes.co.uk/steve-wozniak-cried-jobs-kept-atar...

[2] https://www.yahoo.com/news/memoir-steve-jobs-apos-daughter-1...

[3] https://www.businessinsider.com/steve-jobs-jerk-2011-10

Steve Jobs died from being a jerk, to himself, because he refused to take his doctor's advice about his diet and pancreatic cancer. A reality distortion field only works so long.

What was his diet?

The exact diet doesn't matter, what mattered is that he believed changing his diet would cure his cancer. In the end of course it didn't.

The exact diet matters a metric shitton, because Jobs' hubris cost him his life, if instead he had realized he did not, in fact, know everything, he might still be alive.

Pancreatic cancer eats sugar for-fucking-breakfast. [1] He was eating nothing but fruit, and even though fructose release is regulated in its binding with fiber, its still sugar.

If Jobs had eaten nothing but bacon, steak, and eggs, we might still have him around. I forgot what folder my bookmarks are in, but there's scant - but compelling - evidence to support that a sugarless diet high in protein and fat quite literally starves pancreatic cancer.

[1] https://jeccr.biomedcentral.com/articles/10.1186/s13046-019-....

In fact, ketogenic diets have been shown to slow tumor growth in a number of cancers. See https://www.mdanderson.org/cancerwise/the-keto-diet-and-canc....

> If Jobs had eaten nothing but bacon, steak, and eggs, we might still have him around.

Maybe he didn’t want to be around..

https://en.wikipedia.org/wiki/Warburg_effect_(oncology)

Nothing but fruit.

For most larger companies an engineer salary, or any human labour for that matter, is very cheap. FAANG could pay 10x more if they had to, but they don't have to because no one else pays more.

I'm not so sure. If engineer's were cheap, you wouldn't have Steve Jobs colluding with other companies to suppress salaries: https://www.latimes.com/business/technology/la-fi-tn-tech-jo...

That he'd prefer to pay less doesn't mean he couldn't afford to pay more.

I think this is due to the exponential payoff in a success scenario. Especially in high tech where certain initiatives can have a “winner take all” effect. I find it completely unsurprising that internally the tech giants function like a cluster of startups competing against each other.

Capitalism is based on the idea of transplanting the survival of the fittest paradigm into the economy and that’s exactly how I’d expect it to look in practice. Especially as progress accelerates and massive wins become both scarcer and more impactful at the same time.

Internal competition on the same project shows a lack of confidence from management... it literally shows they don't know what to do, and are just throwing spaghetti at the wall, or aren't confident in their skills to get something deployed with what they choose. It's not solid leadership, it's dissonant.

It also sets people against each other, creates better-than-you mental heirarchies between equal workers where non are necessary, and is essentially friendly fire in the workplace. I've never seen this end well.

Capitalism isn't just economic natural selection either, it favors those with capital, and especially the most of it, and is easily exploitable by them to tip the playing field in their favor against their competition and those below them. Your analogy is bad in both cases; natural selection means one side dies, which is not what's being described here, and is not good for one side anyway, and capitalism is not as good as cooperation anyway. The latter is far more efficient.

I disagree that (internal) competition unequivocally leads to better-than-you mindset. If done properly, in an open and sharing mindset – one might call it scientific, with expectations and criteria defined up front and with the projects objectively compared against the criteria, then it will work. I have also this work. It takes effort to come up with criteria and metrics beforehand but that is what makes it different from throwing spaghetti at the wall .

> If done properly

Any guidelines? What to think about

First and foremost, a safe (team) environment. This has to be created over time and there are few shortcuts.

In addition, for each experiment you need: a defined time window, up front criteria by which to judge the results, optionally form solution ideas together, give all teams the same amount of time and opportunity, after the experiment is finished each team presents their solution in a fact based manner in perspective of the criteria. After this the teams rotate and see what they can improve on their original solution with the remarks and information from the other tracks. After this decide together or with an informed captain which solution to continue. After this there should be no hard feelings, no personal consequences. Each team should be treated equally because they all contributed to the end goal. This is what will give you a fair competition and help create team safety.

This can be done on all kind of levels, between one day for something small and two/four weeks for the bigger challenges. Making it bigger than this will incur a lot of stakes/vested interest.

Thanks!

> After this the teams rotate and see what they can improve on their original solution

Interesting idea

Software projects often operate in high-uncertainty scenarios. Best approach may often only be "obvious" in hindsight. It's not irrational to do it in parallel/ in several teams - in fact, I'm surprised it's not happening more often.

>Internal competition on the same project shows a lack of confidence from management...

I'd disagree, internal competition (like it or not, and yes it doesn't sound fun and often doesn't feel great or fair) can be a very effective motivating strategy. And management is used to using this with sales teams, everyone in sales is always competing with each other. It's never fair, they'll have unequal markets, for example, but the competition is incredibly motivating. When I was in sales long ago, the drive to be the best and regarded as such was even more motivating than just getting more commissions. It's dog eat dog but for better or worse it works.

> survival of the fittest

I often hear that about capitalism, but then the caricatural opposite is the survival of the unfit. It is quite visible when swathes of our economy that are not put on any kind of competitiveness (the DMV) end up dropping standards beyond bottom.

We need a balance in between, and we are living in this balance: We are not on either extreme side of this spectrum, the reality is more mild than all-or-nothing, and the non-fittest can still work for a less performing company and be happy with their life. It is just the temptation of big corporations with big incentives that makes some engineers too eager to work for a bad company.

Because often time to market is more important that R&D costs or tech debt for the success of a company. If you win the market, the profits will compensate for the additional R&D costs, and you can release increments to address the tech debt. Customers actually appreciate this, as they are constantly looking for better, newer versions of the product.

Time to market trumps everything.

If money isn't part of the equation, this may actually be the best approach. During the 2007 financial crisis I worked at a bank that had to develop risk software really fast to comply with regulations and prevent disaster. They had two teams work on the same project and once a winning team emerged, they killed of the other. But the result was used for only a year or two, and replaced by a long term solution which was developed by yet another team in parallel.

As the saying goes, in software development, we can control speed, cost and quality, but only two at the same time.

This is not a bad solution, as long as the teams are on the same side (and know it too). I strongly believe that toxic culture is neither needed nor useful, ever.

How can one create a climate where they're on the same side?

And no one is afraid of "losing" and worried about problems that might cause? (Eg getting fired, even if managers say won't happen)

By having leaders who want this and who know how to achieve it. It is simply a matter of principles and trust (both ways). Granted, I have only seen this in companies up to 100 employees... :shrug:

I know more than one famous scientist who does this. Multiple postdocs working on the same project. Whomever gets there first gets a Cell-Science-Nature paper. The other(s) get nothing.

Probably a very common abusive management style at high levels in many industries.

The personal/political aspect aside, I can think of multiple projects that could have benefited from an approach like this.

I'm often astonished by the inefficiency of project delivery, particularly in large companies.

Teams spending months building sub-systems from scratch, where there is an off the shelf(sometimes open source) tool that will do the same job and better.

Man years of work going into chasing trends like "serverless" or "microservices" for no real reason, when a monolith running on a server, could be delivered in a fraction of the time and probably do a better job than what ended up being built.

I'm convinced that paying two teams to work on the same project would often cost less than paying for the huge teams and cost overruns I've seen.

Interesting theory. If you pay 2 teams A and B to work on the same project, and B finishes in half the time it would have taken A, you really didn't spend anything extra did you?

... until you find they finished first by cutting corners and delivering something that is only capable of passing the scant unit tests.

Then the "zero knowledge" psychopathic management style doesn't seem so smart.

It isn't a zero knowledge style. It is an experimental, or knowledge-acquiring style. To employ that approach most effectively it makes sense to have competing teams with purposefully different styles.

> experimental, or knowledge-acquiring style

No knowledge is going to be acquired that way.

It's a manager who has decided understanding the nature of the work is beneath him, when he can deploy someone else's money to wind up some insects that will run around doing the work for him and watch them struggle against each other. Literally zero knowledge, before, during and after.

When whatever result appears they will not analyze the meaning of what happened beyond punishing some insects and rewarding others.

> until you find they finished first by cutting corners and ...

Or until they accidentally burnt down the office building. You're right, doesn't seem so smart

I disagree, such an approach completely desensitizes the human aspect of work and treats the people working as commodities that are expendable. Engineering is hard, teams might need to go through multiple iterations/generations to get the desired results. A better investment would be to develop the right engineering culture rather than Team A vs Team B duking it out.

Suffering is the commodity engineers are providing.

Why not just find the best people for the job who can understand the needs of the project they're working on and execute correctly?

Running two teams against each other just screams of waste/bad management in my opinion.

It’s fine if everyone knows they’re in a competition

At the same time, can't this make it harder for members of the different teams to become friends with each other -- in a way, they are competitors, not coworkers. And maybe they'd be worried about getting fired if they "lost"? That could cause some of them to start looking for other jobs? Or some could feel bad, get demotivated. And other weird side effects.

What could be ways to avoid such things

How did this work out at Apple? When you were there

The unfortunate thing is that if not for the social/political side, this would be a good approach. I would be happy to be on one of many teams doing parallel implementations if at the end one codebase won but no people lost.

Reply on news.ycombinator.com