> As soon as Sphero completed the acquisition, bringing Kelsus in as an app developer, two things happened: 1) Sphero told us they needed fully revamped iOS and Android apps six months later with no schedule wiggle room. 2) Sphero spent the first two of those six months organizing a team on their side and hashing out requirements for the new apps.
This exact pattern has preceded every mismanagement disaster I've ever seen:
1) Management gives an unreasonable deadline to developers before defining the deliverables. Clock starts ticking.
2) Management then fails to settle on the requirements for months and/or continuously moves the goalposts while people are trying to work, turning an unreasonable deadline into an impossible deadline
3) Developers start realizing that they're going to receive the blame when impossible deadline isn't achieved, despite not having any control in the matter. They start leaving for new jobs, and the death spiral begins.
It's the universal pattern of a management team that doesn't know how to do anything other than make demands and then apply pressure. Unless you can get someone in charge who has real leadership and planning skills, it's not recoverable.
The death spiral becomes visible, really. The gun had already been fired, the body just hadn’t hit the ground yet.
I must say these failure modes are much worse than the ones I’ve experienced, which maybe I should be grateful for, I’d have to think about this.
Generally I’ve seen a slower burn, where the remaining fiscal year plays out with soothing tones and promises of not changing things, and if money doesn’t magically appear in their accounts, which why would it? Then they don’t give you money for some of the things you usually do and while they technically didn’t tell you not to do them, if there’s no money you don’t get to do them.
I don’t know which business school teaches people to say “ah can you smell that fresh mountain air” while they have their hands wrapped tightly around your neck but that’s some gaslighting BS that I hope nobody experiences, but I know people have. Best I can do is tell them to watch out for it. Some places you’re safe until FY+1, and things don’t go fully absurd until FY+2.
> I don’t know which business school teaches people to say “ah can you smell that fresh mountain air” while they have their hands wrapped tightly around your neck …
It’s all of them and the higher you get into management the more apparent it is. They sell a system of meritocracy where those who work the hardest get the rewards. Then you get into management and working side by side with people whose first job out of college was as a VP, who explain to you how they are forcing the newly hired manager to fire someone at random to “make sure they have a backbone”
Software engineers have been tricked into thinking they are part of the in club because they are paid well enough to have the lifestyle that the middle class had between ww2 and the 80s, but we are being systematically stripped of the value we bring.
If this wasn’t true then we wouldn’t be able to point towards recent events like jobs setting up a hiring cartel to depress our wages
> Software engineers have been tricked into thinking they are part of the in club because they are paid well enough to have the lifestyle that the middle class had between ww2 and the 80s
This, and additionally we've been tricked into feeling guilty about it as well.
Well, question is which part of the world you live in, of course. But I don't need to unionize. If I am not satisfied in my job I can switch. Each consecutive job hop past 15 years got me better pay, better benefits and sometimes a better job (sometimes it was equaly shitty as the prevous one but for better money). This does not happen for unionized workers.
Maybe in the future we will have to unionize. Definitely not now and not in Europe. And this is not a matter of pay, e.g. airline pilots are paid more than programmers here yet they are heavily unionized.
Would this not be the best time to form a union, though? If we start to hit tough times when programmers are treated like shit and the job market is tight, then your colleagues will be less inclined to rock the boat and management will be actively trying to crack down on any attempts to organize. Basically when you need a union it could be too late.
Right now management will be off-guard, not expecting any unionisation push and will be a little bit unprepared as to how to counter it (that is, if they even try). Employees will likely feel comfortable openly discussing unions knowing that they probably won't feel any reprisals (and if they do, well the job market is still pretty good for the moment). The tough part would be convincing someone on $1x0,000/year that they might benefit from a union.
Yep. Hell I'm guilty of the same thing. I'm saying "we" should unionise and it's a good thing to do - while not unionising myself. My defence (excuse!) is that I'm a foreigner, my local language skills suck to the point that I'd struggle to understand local employment law so I'd be a pretty awful person to spearhead this :)
I also don’t need to unionize but I’m pro-union. I think software should have a guild like the actors guild, that enforced minimum standards. when Kickstarter ran its unionizing campaign it turns out one of their demands was no productivity tracking software! I would love to know as a member of such a hypothetical guild I have collective clout to ensure I’ll never have to deal with a bullshit metric tracker again.
> when Kickstarter ran its unionizing campaign it turns out one of their demands was no productivity tracking software!
This is naive. Any ticket tracking system can be used to track productivity. And if you don’t have a ticket tracking system to organize work, that’s a miserable environment to work in.
But it also means at minimum a middle manager can’t use software that does stupid shit like neatly displaying comparable lines of code and stack rank devs based off this. I like this minimum. I don’t need a union to perfectly solve the problem of micromanagement but I can happily pay portions of my salary towards minimum standards of workplace environment.
Yeah 100% as a union you'd have a bit more power to negotiate a range of things with your employer, and many of them are pretty minor and even cheap. Thinking back to some previous jobs I had, the things that hurt us weren't salary related, but things like:
- as you said, productivity tracking through arbitrary means (in our case it was an arbitrary "story points completed per developer per month" measurement used to rank us)
- expectations around overtime (it was common to be asked to work evenings and weekends, you were remunerated at 1.5x or 2x but expected to do so if asked and singled out if you didn't)
- developers being frozen out of the requirements process (senior devs were begging to be allowed to spend time with the analysts, but prevented from doing so by someone in the management hierarchy, I think someone in charge of analysts)
- work-from-home (this was pre-covid, but there was an expectation that you'd be in the office unless you had an extremely good reason to and it was begrudgingly permitted)
Fighting for improvements in these areas individually is near-futile, but when you've organized yourselves management have to decide whether some very minor things are really worth pissing their entire, expensive-to-hire development team for.
If it used ticket-points instead of LoC, would that be OK? If it used “a fault-free oracle who told you a perfect measure of value created”, would that be OK?
I’m trying to figure out if you’re opposed to terrible approximations of productivity or to making performance distinctions among engineers.
I’m opposed to bullshit metrics to measure performance, lol. I don’t see how you can interpret my statement otherwise I’m good faith. I’m merely pointing out that at the very least the Kickstarter union was able to limit the degree of that particular bullshit.
Some of it comes down to having a seat at the table in deciding what metrics can and should be used. Obviously there needs to be some way to evaluate developers (whether it's subjective or objective), but particularly when they're negotiating collectively, it's reasonable for developers to have some say in this. Their interests are also aligned in making sure that the ranking reflects skill rather than something arbitrary.
> But it also means at minimum a middle manager can’t use software that does stupid shit like neatly displaying comparable lines of code and stack rank devs based off this
Lots of developers apparently WANT to do this though, when they belittle all the "soft skills and politics" that they feel are inferior to writing code. The irony is when the machines take over they'll start with executing the carefully defined instructions on all these tickets, while the last humans around will be the ones defining the requirements and hasing out the intent.
I think there are different definitions of what a union even is. German here and I was really quite surprised to understand that unions in the US are apparently per company. I believe in most of the EU, unions are per business sector - so while unions are in a sense stakeholders of the companies (if the company goes bust, it can't provide jobs), it usually doesn't have a specific interest in keeping employees in a particular company.
I've always heard "shop" used in relation to a particular business being union or non union in terms of who they hire (i.e. "they're a union shop" means they'll only hire IATSE or something like that and no non-union people), and "locals" being the actual union you belong to, but that's from the theatre world which might be a bit different.
Ah, that makes sense, then I might have misunderstood.
So does that mean, when the headlines say "Amazon workers (from a particular warehouse) vote to unionize", it's really about bringing that warehouse under the umbrella of an existing union?
Oftentimes, yes. They could form their own union but it's common to join an existing union.
Having universal or near universal union membership for a certain profession is limited to certain jobs, things like warehouse workers or retail employees aren't anywhere near that.
Geniunely asking. As I live in a part of world where we stay in longterm jobs.
Is it not stressful when switching jobs? - from paperwork, interviews, new colleagues, friendships, on-boarding, new place politics - especially for brain.
You get used to it. After a while if you become good at interviewing and going through the motions you are probably more secure than someone who has "job security", no matter how hard it is to fire someone a company can still go bankrupt.
If I got fired tomorrow it would result in a vacation, probably followed by a raise. When you get to that place it isn't scary at all.
I'm guessing you are American and under 35 because there's a whole generation of you that considers an 13-year tech bull run with massive stock appreciation as normal, and the hardest problem is passing leetcode interviews. It's a very different story looking for a job in a real downturn like 2000 or 2008.
If you keep looking for the same job as you get older, yes. I'm well above your age guess and starting a new job soon, but it's definitely not the same role or expectations as 20 years ago. I've found that if you work to differentiate yourself as an individual the substitution cost is very high, so you can find work even in the most challenging environments. I think this would be a much harder strategy in a heavily unionized environment.
Something to consider is pension lock. Your pension is tied to a specific employer, and leaving means losing everything. I hear this all the time from school teachers, but it also happened to my mom: Budget cuts were coming and while she had enough seniority to stay employed, she didn’t have enough juice for choice of location. She was going to have to accept a job that required an additional hour of commute that she couldn’t do for health reasons. So she had to leave 2 years shy of a pension. She got nothing, and she also doesn’t qualify for Social Security.
It is extremely stressful some of the times even. But it's the reality we live in. People don't change. Companies change extremely rarely. If you are smart enough to reverse-engineer software systems -- a necessary skill during onboarding -- then you are smart enough to see nobody will change things to a more positive environment, and hence you should leave.
I hate it with all my heart but if I have to, I'll do it 50 times more. I am never allowing myself be held hostage.
No, but unionization gives you a seat at the table to negotiate the rules of the game with upper management. Collectively you stand a better chance than individually to improve the working conditions.
Unionization can be hijacked by employers, history knows of such occurrences. Plus Amazon and Google have been caught up (in the recent times nonetheless) of hiring paid saboteurs to impede people from unionizing.
My job is not to do underground mafia wars. If the employers want to fight dirty I'll just move to someplace else. Eventually they'll be stuck with the people who are OK with being slaves -- but won't be creative or efficient.
I wish them luck. They are hurting themselves, not me or the other worthy programmers.
Unpopular opinion: unionization is like democracy: people think it works but in reality there are a lot of shady deals under the table and the system hasn't worked as it is supposed to, for a long long time.
Inquiry: does this apply to other well-paying unions, such as the actors guild and professional sport players? I’m genuinely asking, because as far as I know they are still in existence and regularly ensure better working conditions for their membership without limiting their mobility.
My wife had a client that went on to play in the walking dead. In order for my wife to be able to continue to do her client’s hair, she had to join the actor’s guild and be “licensed” by them and pay dues. So, I’d say they (at least the actors guild) def can reduce your mobility, even say which hair stylists you are and aren’t allowed to use.
Well, in order to do her hair for the role. She obviously could style her hair for events in her private life, right? A wedding or whatever?
It seems a stretch to say the union interfered with her 'mobility', any more than you can't do plumbing on a public building without having a license etc.
I am saying that when enough money are in danger [of having to be spent by big companies] that unionization gets under attack with very questionable and shady techniques.
I wasn't aware that I have to remind HN of the recent articles, published right on this forum, of evidence that Amazon sabotaged unionization efforts by hiring people who deliberately derail discourse and pump outrage. But alas, apparently people believe only what they want to believe.
It wouldn’t change anything about the job description. Even unionizing doesn’t mean that developers suddenly get more say in how uselessly their time is spent.
The reality in which we live is one crafted by people, and if you don't have a seat at the table crafting the rules, then you are the one being taken for a ride.
Generally yes and that's the reason I've been reluctant to switch jobs for small gains. I stayed with my previous employer for 6 years (plus 2 calendar months because here you have to file in a letter of resignation 2 months in advance, that's by the law).
But software development can be stressful on its own: you have endless pointless meetings which serve no purpose but you have to attend them, you have mandatory corporate team-building shite which you must attend or you lose the "software engineer SENIOR" job title and you have to show leadership skills to HR people and your managers during pointless "funny" "games" during the team-buildings, you can't be involved in illegal activities (e.g. rage-type murder of your manager is a major no-no which can ruin your career for good). You also have to learn new things constantly in your free time because your employer is reluctant to pay for courses. The list goes on. My previous job was applied research and especially the university professors who did the actual research treated us like a piece of shite. I can't even count the number of times I heard something like "you can't understand anything because you have only Master's".
The stress-level of switching to a new job is generally comparable to normal activities. You need to grow some thick skin.
>Each consecutive job hop past 15 years got me better pay, better benefits and sometimes a better job (sometimes it was equaly shitty as the prevous one but for better money). This does not happen for unionized workers.
As a counter-example to this specific point, the Screen Actors Guild does a tremendous amount of work to raise the pay and conditions of the median earning actors, without preventing the highest performing members from negotiating compensation in line with their ability to contribute to the success of a project. We can have our cake (collective negotiation) and eat it too (million dollar+/yr IC roles).
Other notable examples; State bar associations (lawyers) and the American Medical Association (doctors).
The Bar Associations and the AMA are not quite unions though they certainly advocate and lobby strongly on behalf of their professions.
For the Bar there may be confusion because of the names of licensing agencies. In California, the state agency is the State Bar of California, but that has nothing to do with various bar associations.
VNV is the pilots union of KLM, the Dutch national airline. IIRC they were the very last of the unions to sign up to the 'commitment clause' the Dutch gov required as part of their bail-out during Covid. Not a union without teeth.
If you include quality of life at work, exposure to radiation, not being able to sleep in your own bed and have dinner with your family everyday, and slogging through years of lower paid piloting to have a low probability chance of making it to the higher paying flights, programmers handily beat pilots in the pay to quality of life ratio.
Average is CZK per calendar month gross (which is some 25-30% higher than net).
Pilots 38k - 132k
Programmers 36k - 86k
as employees. If you work as a freelancer programmer (i.e. you have your own trade license) you can easily earn twice as much but if you count-in all the employee benefits granted by the Work law it's usually not worth it if you already have a family (which I have, therefore I switched from freelancing to being an employee).
And of course, Ryanair/EasyJet pilots are not counted in the statistics. The same goes to students - programmers which kludge together a Wordpress site and "sell" it.
Those numbers roughly match what pilots make in USA[0], but 86,000 CZK per month is about 20% (or less) of what an entry-level programmer would make in the USA. The lower bound of 36,000 CZK per month would be only just above USA federal minimum wage.
I think part of the push-back against programmer unions from American programmers is that there's such a wide range of skills, and at the moment the market allocates compensation more-or-less according to capability. In many important ways, a programmer earning $500,000 per year at Google is in a different industry than a programmer earning $50,000 per year at General Motors.
It's pretty disingenuous to equate a RyanAir pilot with a student, which speaks to the misleading nature of comparing these statistics straight up; go look at what it takes in terms of training, experience and seniority to get to one of those higher paid pilot jobs. Now compare it to software development. 36k is less than minimum wage in Canada ( < $2K CAD / month); junior developers are easily making 3x that in their first role.
> It's pretty disingenuous to equate a RyanAir pilot with a student
Ironically, as Ryanair pays pilots significantly more than the range in the GP's comments (at below the low-end and high-end), including them would support their argument.
The only way to make the claim that pilots earn more than developers stick is to ignore all but the high-end of pilot salaries at major airlines and include all developers. A fairer comparison would either be to include all pilots (including the low end piston engine pilots at skydiving DZs and other utility roles) or to only include the top-earning professional developers (maybe MAGMA).
also, for every engineer, there is one who will claim to be able to do the job cheaper. that is why we need unions. that, and to get rid of leetcode. people already went to college and that should be enough.
>> that, on to get rid of leetcode. people already went to college and that should be enough.
I don't like or do LC interviews, but even if (a big IF) college prepared you for programming, a LOT of professionals don't study development or even attend college. How would they get into the industry? Take 2 years off later in life and attend college?
if you did not go through college but picked up programming that’s cool. this should not put requirements like ridiculous leetcode interviews onto those that did go through college.
any good college will require significant programming work, so by the time you graduate 4 years later you not only have CS theory subjects down but are able to write software and can pick up any language in a few days.
What would be your expectation for an union? I was union member as a developer when I lived a Nordic country (union for engineers and other academic technical professions). Main benefit I saw would've been legal help if I got into trouble with an employer. Otherwise the working conditions were anyway in such a good shape that I wasn't really sure what I should want out of it.
Software development is one of a fairly short list of fields where people regularly epouse the virtues of unsustainably long work weeks, and openly state that employees not meeting those requirements will not be successful. I wouldn't describe the working conditions of software development as great in many companies, a lot of snacks doesn't make up for 80 hour work weeks. I could definitely see a guild type arrangement setting minimum standards for hours and working conditions, just like they do in other well-compensated fields.
> Otherwise the working conditions were anyway in such a good shape
Would the stability and general level of working conditions have anything to do with the fact that most are unionized, and have been over a long time so they can do their job responsibly, perchance?
Yes, the working conditions are earned by previous generations through their hard work for unionization and employee rights and is not something that can be taken for granted.
Maybe the parent wants the union to fight for the same conditions as Europeans now have? I wouldn't know. My experience from a Nordic union certainly wouldn't be a good take of what an union membership in Brazil, US or Japan would be like.
If you think thatthe lifestyle of a software developer with a few years of professional experience is only as good as the middle class between the late 40's and 80's you're either vastly revising history or weren't there. And before you trot out home ownership remember that all those tiny post-war bungalows housed families bigger than yours and were not located in the handful of big centers were housing is so expensive.
I think of this when managers come up with different requirements during the project. If the requirements seem to make the product better, I'm all for it. I like to work this way and they pat me on the head for being "agile". But I always end up kicking myself when they ask why the project is taking longer. I fall for it almost every time because I like to tinker.
One of these days when I’m feeling salty I’m going to make a wiki page called “why is it taking so long” and list every feature that drew out the schedule. Hopefully it’ll be seen as helpful, but probably not.
"former Apple CEO Steve Jobs, former Google CEO Eric Schmidt and top executives from [Intuit, Pixar and Lucasfilm] had reached "no-poaching" pacts prohibiting each other from trying to lure away each other's top workers with offers of higher-paying jobs."
These were the ones for whom DoJ had enough "smoking gun" proof, but Jobs and Schmidt had a lot of friends elsewhere (Larry Ellison...), so the cartel was likely much bigger.
Yeah, the ad-run Internet allowed ideas to be capitalized easier, and it also made memetic - not even novelty - value dominate over everything. That resulted in manager-sales role capture entirety of credits. That had been great for some temporarily embarrassed millionaires, I guess, but it sucks for the rest.
Basically the crux of it. As the poster above said "gaslighing BS". If you want to cut make cuts, make cuts, don't waste our time with making postings and doing interviews just to renege on it after.
The story fills in all the reasons why ‘management’ start at #1.
Company A buys company B for a product it believes in. Company A knows that company B was incapable of getting product to finish line, which is why they sold out. No problem though, company A has done this before…
The managers at company A are assigned to ship product, just like they have before. Managers can’t say “its all good, we’ll give them a couple more devs and leave them to it.” they were told to manage, changes will be expected, planning must happen.
The C level of company A just spent a bunch of money on company B. The product needs to hit positive revenue in 9 months, without positive revenue in 12 months the company will be out of cash. So management are told in no uncertain terms that they have to ship in 6 months.
The contracted developers sign on to a 6 month fixed timeframe and know there will be design tweaks by the new management.
At every stage everyone is doing their job. Everyone is trying to do the right thing for success and to not get fired. Everyone has a problem that can only be fixed by someone at a different level compromising on their quality of work or their personal happiness.
I’m not excusing bad management or execs who looking for a rapid cash-out. Trying to illustrate how a good company can hit the same pattern.
> At every stage everyone is doing their job. Everyone is trying to do the right thing for success and to not get fired. Everyone has a problem that can only be fixed by someone at a different level compromising on their quality of work or their personal happiness.
I think this hits the nail on the head.
A bunch of reasonably competent people went in with the best intentions, all in good faith and over time it became clear certain assumptions were either too optimistic or simply wrong.
While there is definitely blame to be apportioned, the frustration felt by all involved leads to a very human reaction of calling it malevolence or incompetence.
So company A gambled that they can turn around company B in 12 months or go bankrupt? Sounds like whoever decided to buy didn't do their due diligence.
Not necessarily bankrupt but at a point where they’d have to cut their losses by losing staff. But company B was going to be fully bankrupt before 6 months without company A stepping in.
Companies make these decisions all the time, particularly in industries whose products are hit driven and then tail off.
Dealing with exactly 1 & 2 right now. #3 doesn't really apply in my case because 80% of the devs are budget staffing agency hires. But on that note, I'd add a 4th point:
Management panics when they realize they won't make the self imposed deadline and start throwing bodies at the problem.
In our case, we went from 2 teams to 8 over night. The very few engineers who actually were capable of shipping features became swamped dealing with the fallout.
To make things worse, they keep scheduling multi-day, 8hr "planning" sessions that all key devs must attend so they can better "understand the remaining work"
That analogy understates it. Starting a big fresh project with an idling “team” is really inefficient because the TL needs to figure out how to keep everyone busy.
The better way is to have a smaller number of people work on requirements and figuring stuff out before a whole team lets rip. Some tasks just don’t parallelise well so a 9 person team isn’t good for everything.
This happens when managers think of themselves as the engineering division and the sole isolated source of value while viewing engineers as cost associated with delivery. The proposal PowerPoint is the product and the actual product is a Proof-of-Work that could retroactively nullify pre-realized values.
> Once they've shown they can do it once it's perfectly reasonable to bet the entire business on them doing it the next month.
That's true. A team of 20 women can easily produce one baby a month.
Nine women can't, but the people who like to say "nine women can't produce a baby in a month" are almost never trying to tell you that you can fix your problem by expanding your team to the appropriate size.
Fred Brooks encountered a similar problem as a project manager at IBM in the early 1960s, working on the software for the System/360. In 1975 he wrote The Mythical Man Month about the experience. He said "adding manpower to a late software project makes it later". The increased communication needed was one reason. About half a century later, most businesses have still not learned these lessons.
I once on a company where a CEO did that 3 times in a row to an engineering team, and mentioned wanting that team to be 4x its current size in two years. In an interview, he mentioned The Mythical Man Month as one of his favourite books.
Everyone perceives things through their perspective. Dopey CEO guy sees himself as the surgeon leading the software “surgical” team described by Brooks.
I find myself quoting the mythical man month to various poeple at least 2-3 times a week. Unfortunately no one is familiar with it (obviously) or seems to understand the point.
The other day I had PM complaining how they were going to keep their team (which has somehow grown to 10 devs!) busy after the highly sequential work was blocked by a dependency on another team...
...and who was it that failed at the outset to factor out that dependency into a clean,well-defined interface ?
That would have allowed modules/components to operate independently ,reved on different schedules, and more, but evidently too much thought at the outset ,so they just didn't even bring it up ,or passed on the opportunity if it was brought up.
They think they can't spend the resources to get it right, but they'll magically have more resources to fix the problems.
I guess I should have been more clear, as I'm not talking about microservices, but an architecture I implemented before that hype.
It was to partition the app into at least the primary segments that did different functions and had different behaviors, system resource load profiles, etc., and then mandate that those all run on separate machines (this was before everything was cloud-based), and that the relationship to entities was not 1:1. Defined clean interfaces up front. The primary goal was to be able to scale very rapidly for any big customer and/or upon discovering a scalability issue by temporarily throwing hardware at the problem, and secondarily to allow teams to rev different portions of the system on different schedules.
Both worked great, and it wasn't long before we were taking major customers away from competitors because they had scalability issues and we didn't. I'm in R&D and manufacturing now, but see no reason that this approach of fundamental modularity should not be relevant. Heck, I find high modularity to be a good approach relevant to designing industrial processes, or just setting up a shop... just keep everybody's fingers in their own pies, make the organization implement the best architecture, not make your architecture implement your org chart.
but why learn anything when you can hire a kanban/PMP/Kanzai/6 sigma/SaF or whatever is the latest BOTD (not forgetting CMMI and ITIL - the masters of vapid BS that goes nowhere)
and to save money they hire some newbies instead of experienced people. I have had it multiple times where the project got looded with people who had no experience or they were in India 12 hours away so onboarding was really hard. the result was always that the added people slowed the project down.
Wait that actually sounds awesome. What we’re your issues with this practice? A 3 day code freeze while everyone works to solidify a “meeting of the minds” followed by 87 days of heads down progress sounds like fucking heaven to me compared to the weekly planning meetings on top of daily stands up I live with now.
pros and cons, will depend on the type of thing a team/company is working on. I've been on the receiving end of this with some negative experiences as well.
Team1: "Hey, we've launched a new initiative a few weeks back. Important for us to be able to add one field to the response of your internal billing API. Can we discuss what that would take?"
Team2: "Hey, probably a few hours of work. But, we just had our quarterly planning last week. In 12 weeks you can submit for Q2, and _maybe_ we will plan it somewhere in May or June."
We had weekly planning and "triage" meetings too. This was on top of the normal stuff. It wasn't all heads down either. If you finished your tickets before the next planning meeting you could relax, edit the wiki, look for stuff to write new tickets for etc.
I worked on one team that had a one week planning period every two weeks. The planning week, for us regular devs, was “do whatever you want” and it was epic. There were basically no bugs because a few of us liked tackling bugs for fun. Other people worked on optimization problems and code hygiene.
For the people doing planning, they were always busy playing ticket shuffle, asking random devs random questions all the time. But those two weeks was cray and anything not done by the end of the sprint had to be done by the end of the planning period, and you better have a good reason.
I worked in a place that died this way, and know of another place that also died this way.
The place where I worked: the owner of the company was Bipolar (in the literal sense), and depending on what phase he was, he wanted different features, so every time he "switched", he changed all features, often going back and forth between two feature sets, after a while he got mad the apps were all late and not finished and fired everything and focused on his other business that was more successful.
Place I had a friend that worked there: Experienced (but small) movie studio decided to make games... My friend after a while started to complain of features changing non-stop, I made aquantance to a lot of other employees for various reasons and gathering up all their stories one thing was very clear: the owner new wife often hanged around in the office, and went around demanding new features, whenever employees resisted, she called her husband (the real owner), that then proceeded to agree to whatever she asked... Until they married the project was going well, as soon they married it tanked.
Word to the wise: start looking for a new job when that clock starts ticking. You may decide to stay but great to have something else to parachute into as an option.
Second thing: you can change jobs as often as you want. I am for loyalty but you can’t know what a job will be like until you work it.
This may be good advise, but I hate it. Personally, I couldn't put my heart into the job hunt, while at the same time giving my best at the current job. In other words: just the step of starting to search for a job is for me synonymous to accepting defeat at the current job.
If you've had projects like this in the past you'll recognise the early warning signs (eg. hard deadline before (even rough draft) requirements are available).
You'll know it's time to start the job hunt early because there's no way it can work unless you work yourself 24/7 into the ground.
It's not about accepting defeat, it's about accepting you are worthy of something better.
That right there. Failing impossible tasks is not a personal failure and nobody should waste their personal life on these tasks out of some sense of 'pride' or 'loyalty'. The failure lies purely with the person who made those plans. They are the ones who failed _you_, not the other way around.
> You'll know it's time to start the job hunt early because there's no way it can work unless you work yourself 24/7 into the ground.
Note that in this case there’s no way it can work period. The product is useless and worthless. The ring that beeps differently depending on the color of objects it hits? How much would you pay for it?
Loyalty is demanded by employers from employees, especially when unpaid overtimes are demanded. However when it's employers turn to reciprocally show loyalty to the employees it usually doesn't work. You aren't getting bonuses for your last year's unpaid overtimes when the company starts getting profit from your job. You need to beg for unpaid time off when you need to do anything at your home despite working many unpaid overtimes. You aren't getting salary rise for your hard work. You are being treated as disloyal replaceable resource. You need to be on a job hunt constantly.
I would look it more like what freelancers have to do. Keep marketing yourself. The process of
job hunting can clue you into trends and keep you current. I worked with someone who modernized our tech stack due to things he learned on a job search where he never left due to that search!
I didn't mean to be judgemental, I was just reflecting on my personal situation and experience. I started off by saying: [theirs] may be good advise. Sorry if that came across differently.
A few years ago lots of companies would have assumed that someone doing too much "job hopping" was unloyal and probably not competent enough to stay for more than a year or so.
Today it's so incredibly common (and hiring processes are extremely strict compared to before), that most companies see having started multiple jobs as "validation" from other companies.
In my experience, it still seems to correlate that candidates with a lot of job hopping also don't make it through the full set of technical interviews.
I’m in mid of one of those exact death spirals. Finalizing a launch date before even knowing full well what the scope is. Yeah there is a general fuzzy idea of what the end goal is but that’s not what requirements are. A well defined requirement takes too much time to arrive on especially if multiple stakeholders involved, that people trivializing it really get to me.
As we all know, the problem is they reverse 1 and 2. They shouldn’t be trying to establish a deadline until the have the requirements locked down. Of course, locking down the requirements is the hard part and business people really are bad at it (in my experience).
Agreed, and while it's become fashionable to trash on "agile", this sort of thing is why I still prefer it to alternatives. Basically "what do you want next?".
Problem is not the agile, but useless sinecure managers trying to rebrand "agile" as something in which projects don't need planning, can be completely chaotic and any requirements can be changed at anytime without affecting the deadline.
"Hey we don't really need to make any decision ever or even know what we are doing. That's the great thing about agile!"
This might be a controversial take but if you have an actual deadline -- "product must cross the threshold of not shippable to shippable" as opposed to a cutoff date "product is at all times shippable but we need a date to say we're done refining" then agile is probably not the way to go.
I've always structured projects like this as waterfall to your MVP then switch to agile. You have to get your PMs to agree to an (externally) unchanging design and feature set until you have something working to talk about and then you can ask what they want next.
Even without a deadline I still try to follow this model but define the "MVP" as a "hello world" app but with functioning prod-ready infrastructure and ci/cd. So then I can go to the design meeting and say, "I have a blank canvas, what do you want on it?"
Yes that's fine if the company can determine what they want before setting dates, or asking for "estimates" (date commitments). Though the OP was talking about worse case of: date set, product/ux/etc continues (or starts) planning, eating well into deadline.
Being willing to throw away work is the single most effective way I've seen at running an engineering org, both in terms of promoting innovation and in being able to quickly adapt to evolving customer needs as they get revealed.
If your morale is harmed by throwing away work, that's something you should work on.
It depends on why you throw the work away. If it's because of issues that should have been apparent with minimal planning, it's disheartening. Obviously, throwing away work is important in general. But consider a project to do taxes that gets thrown away because legal says it's a law taxes be done by hand, that an accountant said used the wrong tax code or that marketing comes back and says it has to be a desktop app.
If that doesn't kill your morale, I don't know what to say.
Meanwhile, by all means discover that no one likes typing numbers on a phone so you have to refocus on taking pictures of receipts and wage stubs and text recognizing them.
Creating the 'typing numbers on a phone' version of the app is relatively trivial, so probably worth doing first. You only want to do the AI version if you're really sure that you need it, or you can afford it and it doesn't delay more important things.
I think you are focusing too much on the example, which was chosen to try to explain my point. Obviously it has to be a simple problem with simple issues to be easily discussed in a public forum.
If you worked on a project for any amount of time that wasn’t put in front of users (who would catch obvious mistakes like what you describe), you aren’t taking your job seriously and have bigger problems than feeling bad about throwing away code.
The point here is that programmers are assigned tasks, do them, and the management (whose job is to put it in front of users) is failing at that leading to wasted efforts.
Although I should point out that 2/3 of the examples would not have been caught by a user, because they are compliance related.
If your team is organized in a way where programmers are assigned tasks to execute, you are not operating on a modern software team, and that is your problem first and foremost.
This is something I've come across in my own experience. If you don't actually have any experience in the problem space, the best thing you can do is make something that just barely works, then scrap it.
Then all the unknown unknowns become known unknowns and you can actually create good solutions to it.
All planning is a waste if you don't even know where the speed humps will lie.
It's basically a variation of Chesterton's fence[1]. There's a lot of hubris in thinking one could write a piece of code better than someone else if one has never attempted to write that piece of code, especially when never even having done anything like it at all.
Yeah, like to do the job properly you need someone who's done the same job before. Become that someone by exploratorily building the thing you want to build before you seriously build it.
It doesn't really. There is plenty of old code at google, he was just saying it to people who were too scared of doing work they might need to throw away.
The promotion process explains way more of what I think you are getting at.
It depends at which level you're at. If you're working at an infrastructure or firmware level, throwaway work can be expensive and time consuming. Re-architecture can also be time consuming. There are some parts you have to spend design cycles on, especially if you're doing a large project. It's not that you can't pivot, but the pivot takes a lot of time. At the very least have a set of System Features and System Guarantees that you will drive towards.
With embedded development it's entirely fine to iterate fast and throw away work, until the product is shipped. And in certain applications it is fine even after it is shipped.
True, but usually in this kind of situations it's either zero planning or way too much planning and often the planning is also "wrong kind of" planning.
Regarding three, one dead accurate indicator is, IMHO, when people that voiced their opinions and were higjly engaged start to become quiet. This absence of "distracting noise" is sometimes even seen as a sign of improvement, in reality it is the beginning of the end. And so hard to catch, since us humans are bad at realizing things aren't there anymore.
The Advanced Automation System began, in concept, in 1981 and ended in 1994, “terminated for convenience” by the government. Billions of dollars were spent on it. It is hard to describe. You can’t learn anything from the name. You know it’s about air traffic control because I told you, or because you read about it in the papers. Maybe part of the problem was the name. It sounds like the system to end all systems.
...At $3.7 billion, the Advanced Automation System was one of the largest civilian computer contracts ever; maybe the largest. It was the largest single contract in IBM’s history. From the moment it was awarded, until near the project’s demise, IBM patted itself on the back. There was something for everyone, beginning with a great ball in Union Station, featuring Chubby Checker and “The Twist”.
...What I saw on the FAA’s Advanced Automation System would have made Sisyphus weep… Whatever commitment and discipline there was… was worn down by a battery of watchfulness that I can only ascribe to fear of failure. In spite of tens of millions of dollars spent on new computers for AAS, the most important piece of equipment on the project was the overhead projector. There were endless meetings attended by dozens of people – as if we were never quite sure about the whole thing. The people in charge simply lacked the confidence and the finesse of the space team: NASA, contractors, and astronaughts.
It has been noted by everyone from the New York Times to the Vice-President of the United States that the main problem on the Advanced Automation System was “changing requirements”. For those involved in large-scale computer systems, that is nothing new. No one can perfectly surmise the shape and feel of a system years in advance. Even replacing some aspect of a system you know by heart is not immune from thinking twice about it. … [But] the requirements churn (it was called) on the Advanced Automation System was not normal. It was the result of our enchantment with the computer-human interface, the CHI. The new controller workstation, fronted by a 20″ by 20″ color display, because it was capable of seemingly endles variety of presentations, mesmerized the population of AAS like the O.J. Simpson trial mesmerized the nation…
The project was handed over to human factor pundits, who then drove the design. Requirements became synonymous with preferences. Thousands of labor-months were spent designing, discussing, and demonstrating the possibilities: colors, fonts, overlays, reversals, serpentine lists, toggling, zooming, opaque windows, the list is huge. It was something to see. (Virtually all of the marketing brochures – produced prematurely and in large numbers – sparkled with some rendition or other of the new controller console.) It just wasn’t usable…
The cost of what turned out to be a 14-year human factors study did not pay off. Shortly before the project was terminated a controller on the CBS evening news said: “It takes me 12 commands to do what I used to do with one.” I believe he spoke for everyone with common sense.
Rummaging through one of the closets at the far end of the hall on the fifth floor one day, looking for some standards document, I found an envelope left by someone who left the company – as many did after so many years advancing against stone, while the wheels of commerce were accelerating on what everyone referred to as “the outside”. It contained “A Brief History Of The Advanced Automation System”. It was printed by hand and left, perhaps inadvertantly, or perhaps with the hope that some anthropologist might some day discover it and make a pronouncement. In every important way, it is the truth:
“A young man, recently hired, devotes years to a specification written to the bit level for programs that will never be coded. Another, to a specification that will be replaced. Programmers marry one another, then divorce and marry someone in another subsystem. Program designs are written to severe formats, then forgotten. The formats endure. A man decides to become a woman and succeeds before system testing starts. As testing approaches, she begins a second career on local television, hosting a show on witchcraft. An architect chases a new technology, then another, then changes his mind and goes into management. A veteran programmer writes the same program a dozen times, then transfers. The price of money increases eight times. Programmers sleep in the halls. Committees convene for years to discuss keystroking. An ambitious training manager builds an encyclopedia of manuals no one will ever use. Decisions are scheduled weeks in advance. Workers sit in the hallways. Notions of computing begin in the epoch of A, edge toward B, then come down hard on A + B. Human factors experts achieve Olympian status. The Berlin Wall collapses. The map of Europe is redrawn. Everything is counted. Quality becomes mixed with quantity. Morale is reduced to a quotient, then counted. Dozens of men and women argue for thousands of hours: What is a requirement? A generation of workers retire. The very mission changes and only a few notice. Programming theories come and go. Managers cling to expectations, like a child to a blanket. Presentations are polished to create an impression, then curbed to cut costs. Then they are studied. The work spikes and spikes again. Offices are changed a dozen times. Management retires and returns. The contractor is sold. Software is blamed. Executives are promoted. The years rip by with no end in sight. A company president gets an idea: make large small. Turn methods over to each programmer. Dress down. Count on the inscrutability of programming. Promote good news. Turn a leaf away from the sun. Maybe start over.”
Trouble is that management seems to be a P != NP type problem. Really easy to tell when done wrong but really difficult to get right - for variety of reasons.
It's a rare employee who doesn't think he can do a better job than the manager. If he does start his own company, he'll discover his employees are sure they can do better than him.
It’s an eye opening experience making the jump from one to the other; you realise that often the technical nitty-gritty is a small fraction of the overall business, and that the obviously technically correct decision can simultaneously be a terrible business decision.
And it is very rare when they actually can, most times they try or are given the chance to it fails. Almost nothing is as easy as it seems from the outside, and giving a critique is a lot easier than executing.
perhaps they are setting themselves for failure to predictably crash the stock so the supposedly acquiree can buy into bigger stacks of the supposedly acquirer's share. what seems like a acquisition may in fact be a pre agreed takeover by the smaller firm...
As soon as someone hands you the check it's no longer "your" company and you should stop thinking of it as such. Only misery lies on that path.
I see this on a smaller scale where ICs leave a company and take a copy of "their" code (ask Sergey Aleynikov [1] if that's a good idea). It's not yours. If you ever use it you could face legal consequences. And there's no code I've ever written that I wasn't convinced I could write better from scratch the next time if it ever came up. Side note: it never has.
Don't be that guy who takes the check and then expects control. Don't be that guy who is convinced the new owners are messing it up and then goes out and does the exact same thing..
Often acquisitions are set up with "earn-outs" so that only with the success of the project do you get the full amount of the buy. Even when that's not the case your reputation may well be tarnished by any failure (whether technical or managerial) of the product.
I agree with your point though, which is to just walk away with the check unless you're willing to take a significant risks with either of those two other outcomes.
I'm not an expert, but I've seen the inside of a couple of deals like this in the $100M range. I saw larger % earnouts than described below (e.g. in the 30-50% range), which were based on milestones (e.g. products going to market on time) and income (e.g. $ customer sales over following several years). It's worth noting that the deals closed in a significant amount of stock so that is also an incentive to keep the buyers price high (but that the earner realistically has limited influence over that).
Yes, you technically no longer own it once sold, but there's a huge amount of blood, sweat and tears that goes into building something from nothing - not to mention a sense of loyalty to your staff - and you genuinely do want to see it go into good hands and become managed well.
I guess a somewhat leaky analogy would be like giving away a dog you raised to another family and finding out later that they're abusing it. Yes, it's no longer your dog, but you're still going to care deeply about its wellbeing.
This isn't unique to running a business. You see it with screenwriters for example. A script is sold to a studio and as soon as the check clears, it no longer belongs to the author. The studio is free to completely change it or just put it in a drawer and forget about it. Some have a problem with that. It's their baby.
(a) if you want the dog to go to good hands, don't sell it. Spend time finding the best hands possible and give them the dog.
(b) as you might see, your analogy is not very good.
(c) if you find you care about the money, sell it to the highest bidder. be happy with the money.
(d) if you find you care about the fate of the company, perhaps not sell it? or if you do, sell it to someone who also does? or if you don't, at least realise it was your failure to find such a buyer.
(e) if you expect an acquirer to care about what they acquired beyond how to make money from it, you are a romantic, a fool, or both... and I want to buy your company for cheap.
Dog breeders and trainers have this issue in spades. The common advice is to separate your job from your feelings as much as you clearly as you can, otherwise it gets bad really fast and not only you can't continue your job, but it breaks into your personal life as well.
Your analogy could be apt: don't sell your company if you can't see it suffer in other people's hand.
A pattern I've seen a few times (can't recall examples right now, sorry) is to sell the business and then when the business fails, or turns bad, start a new business to compete.
Obviously companies try to tie past owners hands to avoid future competition, but it still happens sometimes.
Are you implying your own your child. Because that’s a perfect analogy, once there 18 they are independent. It’s just like expressing regret for a sold company
“Own” is, for obvious reasons, not the word we use about children , but in practice it amounts to the same thing. A parent or guardian has complete control over what their child does and where it goes. Until the child turns 18. But we still call it “their” child.
I’ve seen this twice. First time the PE firm installed their CEO who came in and immediately started talking about cleaning house. A bunch of developers left fearing a layoff. That was bad enough, but what he really meant was sales. He gutted the sales team and brought in his guys. Sales tanked, company growth stopped, hard. Features dwindled and bugs grew. This clown and his cronies were gone after two years and the company still struggles today.
Second time. A $10B company acquired a $4B company. The parent demanded high margins from the company that had been running on low margins and legacy, near end of life applications. Layoffs ensued and the parent was choking on the acquisition. They’d been sold on a bogus modernization effort that ended as soon as the acquisition closed. That acquisition is a drag on their earnings today, six years later.
Getting to see these type of disasters first hand is pretty cool imo.
Reminds me a a company I worked at, I can't say it's name, let's just say it rhymes with Dewlett Dackard.
1) Start with a $55 billion dollar company...
2) Hire a new CEO and cronies that are going to make miracles happen with with a very expensive acquisition of another company.
3) 18 months later the miracles have not happened. CEO and cronies are invited to leave with very generous golden parachutes.
4) Start with a $50 billion dollar company...
I've always suspected that the primary reason so many small businesses shut down during recessions (or large businesses lay off huge amounts of staff) doesn't actually have anything to do with cashflow but instead the fact that management can save face by blaming the economy at large.
I recently purchased a Drinter from them. Wirecutter recommended it. I even signed up for Dewlett Dackard Plus since it sounded like a better deal than buying ink on its own.
> Getting to see these type of disasters first hand is pretty cool imo.
I've literally just got to watch a company get ran into the ground by the new owners. Learnt a bunch and once the legal stuff is over I'll have an amazing blog post to write.
In a few sentences.
Tech Side: A company decides to rewrite an application in 3-months, it takes 18-months and couldn't even invoice all the customers upon release.
Biz Side: The company has a "better" strategy created for it by people who don't understand the industry after all the original business people fleed and then starts having to do all the stuff the original people were doing.
>He gutted the sales team and brought in his guys. Sales tanked, company growth stopped, hard. Features dwindled and bugs grew.
how does a changed sales team cause features to dwindle and bugs?
it's more likely that management attitudes changed when acquisitions happen - and that new attitude doesn't foster an environment in which good code gets written. It wouldn't have mattered if the sales team changed or not imho.
> how does a changed sales team cause features to dwindle and bugs?
I can think of at least two ways:
1. In many companies, sales is an important part of the window to the customer. Sales interprets customer desires and forwards them to product management.
2. If revenue drops, the company may need to cut costs too, and one stupid way to do this is to reduce development spending.
If anyone remembers, Gillette was bought ~ 15 years ago and the decision was to move everyone from Boston to Cincinnati; they lost ~ 80% of the people in Boston with that single requirement.
A bit more than 10 years later, a wise decision to piss on their customers wiped 8 billion from the brand. Now Gillette is just a ghost of what it used to be.
in both cases, the company doing the acquisition was making dumb decisions.
Possibly more common is when the company is bought specifically to shut it down, because the product's success would hurt, or is hurting, sales of their own product.
There used to be a category of software called "electronic design automation". It presented an interactive editor where you could enter the schematic diagram of an integrated circuit, and also enter a chip layout, and it would ensure that they matched. It was big business. But "silicon compilers" that needed only the schematic, and generated the chip layout, threatened that business.
So, in the mid-to-late '80s the biggest EDA company set about buying up early-stage silicon compiler companies and shutting them down. That was doomed, but bought them several years during which silicon compilers were (therefore) not available for people to use. The company is still in business today, but sells very different things.
General Motors bought up more carmakers to, effectively, shut down than probably any other.
Sometimes a company can be bought for less than it would cost to hire as many staff as they have. So, they are bought and shut down, and the employees are put to work on various other projects. Google's hiring system is so Byzantine that buying companies, bypassing it, might be their main recruiting method.
One might even buy a company because its product has a name they want to use for their own product. The momentary importance of domain names in the late '90s caused a fair bit of that.
None of these contradict one another. A company might be bought for any or all reasons at the same time.
So when your company is bought, expecting its product to come out the other side is naïve.
I wonder whether there has ever been an attempt to calculate the loss-in-value caused by acquisition-as-shutdown-mechanism.
They probably frequently lead to competitive benefits (and increased market share / revenue) for the acquirer, but the discontinuation of products presumably leads to lost time, effort, and potentially money as the former customers of the product look for alternatives (in a diminished market).
I'll beat my usual drum and mention that free and open source software can mitigate some of the risks (but not, for example, support availability) for a software-based product, similar to having an agreed source-code escrow provision with a vendor.
> open source software can mitigate some of the risks
Have you seen this work in practice, do you have any examples to share?
It’s hard to take seriously at face value for two reasons: 1- generally speaking it might undermine the acquisition in the first place since acquirers and investors and boards tend to like private potentially patentable IP, or at the very least proprietary code. 2- More importantly using your software after an acquisition-as-shutdown to compete with the acquirer is almost certainly a recipe for legal trouble. This seems unlikely to get that far since the acquiring co probably would have vetted the software and also had the acquiree sign a non-compete. Either way, if the intent was to shutdown the software, and if the acquiree was paid for their business, there isn’t a good way to “mitigate the risks”, the deed is already done. If you want to avoid the risk of shutdown, don’t take the deal. When you do see open source software as having any ability to change that equation?
Sure - ZFS[1] is one example that springs to mind.
Those acquirer-side incentives do seem rational (and to some extent traditional) in a business sense.
The risk-mitigation I mentioned was from the perspective of users, not so much of the acquisition target (although it could reassure their employees to know that the time and effort they invested continues to provide value).
Is that an example of an acquisition-as-shutdown? Or even an acquisition at all? Blender is a good example of an open source model working, and I don’t know the history, but the article implies that neither NeoGeo nor NaN closed due to acquisition, so Blender might not be an example of what we were talking about above, no?
Back then the big EDA outfits were Mentor Graphics, Daisy, and Valid. ECAD became Cadence, embraced silicon compilers, and ate everybody's lunch.
Back then, chips were still laid out by pasting up prepared logic blocks, gates, and occasional custom transistors, and routing metal traces between them, all on what we would today call a low-resolution workstation monitor. A million transistors was a lot. These would be output via a plotter to make photomasks for the various doping, glass, and and metal layers.
The EDA software of the time, besides supporting manual editing editing of layouts and schematics, would simulate whole chips taking into account capacitance of wires and transistor inputs, propagation delay, and drive capability of output transistors. It would also apply geometric checks to make sure the layout conformed to rules of the target process. Where violated, somebody would need to redraw that bit, which might mean moving stuff out of the way.
Somebody would have to make up sequences of values to feed to inputs, and others to check outputs against.
So the period when MG was buying and shuttering silicon compiler startups was '85 to '89.
I think after Cadence won, Mentor Graphics got more involved in supporting embedded system design and firmware integration, leaving chips to others. Daisy merged with Cadnetix and went bust in 1990, and after twists and turns what was left became part of Mentor Graphics in 1999. Valid was folded into Cadence in 1991.
Cadence tried and failed to buy MG in 2008. MG was finally bought by Siemens AG in 2016.
Silicon compilation takes place in three major steps:
Convert a hardware-description language such as Verilog or VHDL into logic (typically in the form of a "netlist").
Place equivalent logic gates on the IC. Silicon compilers typically use standard-cell libraries so that they do not have to worry about the actual integrated-circuit layout and can focus on the placement.
Routing the standard cells together to form the desired logic.
So this is basically what I do everyday but we just call it logic synthesis (Synopsys Design Compiler / Cadence Genus) and Place and Route in Cadence Innovus or Synopsys IC Compiler. We use Mentor Calibre for LVS/DRC.
I've worked in serdes teams where there is a lot of custom analog design with manually sized transistors and custom layout in Virtuoso. I'm working on chips in 5nm that are over 20x20mm so it would be impossible to do those without all the automation and it is still tons of manual work.
Some of my older coworkers told me about doing layout on transparencies and colored pencils in the early 1980's.
I have been out of that world for 30 years. The terminology has stabilized since, and the software has got overwhelmingly more sophisticated, and also (I hear) comically buggy. Comically if you are not obliged to rely on it. Maybe tragically, otherwise, with no expectation of improvement.
Some of us remember Rubylith with conflicted fondness.
> Google's hiring system is so Byzantine that buying companies, bypassing it, might be their main recruiting method.
Wrong. Google actually fires all former employees of acquired companies once a certain protection period in the acquisition agreement is over, unless they individually pass the tests applied to new employees.
This exact pattern has preceded every mismanagement disaster I've ever seen:
1) Management gives an unreasonable deadline to developers before defining the deliverables. Clock starts ticking.
2) Management then fails to settle on the requirements for months and/or continuously moves the goalposts while people are trying to work, turning an unreasonable deadline into an impossible deadline
3) Developers start realizing that they're going to receive the blame when impossible deadline isn't achieved, despite not having any control in the matter. They start leaving for new jobs, and the death spiral begins.
It's the universal pattern of a management team that doesn't know how to do anything other than make demands and then apply pressure. Unless you can get someone in charge who has real leadership and planning skills, it's not recoverable.