> 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.
All too familiar a story, and the advice at the end ("know your acquirer") is pointless. Simply put, the acquirer isn't ruining your company, they are ruining their company. The contract you signed and the money you exchanged gives them that right. It is foolish to expect that you will get a big payday and will get to keep setting the company direction and calling the shots as you like indefinitely.
Here's better advice – the moment you sign the contract start counting the days left in your retention agreement and quit right after.
> the advice at the end ("know your acquirer") is pointless
Agree. It's impossible to really know your acquirer unless they are a bigger publicly traded company. Every acquirer puts their best foot forward, talks about how awesome their culture is, and how they are going to do all the things to help you grow faster. IME, it never works that way.
> the moment you sign the contract start counting the days left in your retention agreement and quit right after.
That's a bit too cynical for me. But, you do need to answer some questions, do you want to be an employee? Are you ok not being the one in charge? If you got a decent payout in the acquisition, you have a lot of freedom in the new job if you want to try to keep things going.
One other thing to note, is that many times companies can be spun back out. I know multiple founders who have had this happen.
Corollary: don't keep minority ownership. I know a company owner who sold to a PE firm but kept a minority stake and a board seat, so he actually got to watch them wreck "his" company.
I think it's safe to assume that if your company is acquired, it will be "ruined". Even in the best case, where the product/service stays alive and some of the original team is still working on it, it's going to be somebody else calling the shots and taking it in all sorts of unexpected directions.
Yeah even ones that are "successful" like Whatsapp still have the founders unhappy with the direction. Acquisition is almost never a way to achieve any goal other than getting paid.
Which is fine. It's fine to get paid. That's the deal -- you are getting a bag of cash (more than you could ever make as an employee) for an asset. You lose all say over it once you have gotten your bag of cash.
Maybe GitHub is different enough? I know FAANG acquisitions are mostly different (but not always[0]), but it seems GitHub started a new focus on features around the time Microsoft was in talks for an acquisition[1]. Even if this you attribute this feature focus to the increased downtime, the features probably outweigh the downtime in terms of value provided to their cloud/enterprise customers. Also, they've kept their own job board (not careers.microsoft.com).
So this project was started in 2017, raised enough money from backers to get to (some) fruition, and was acquired within 18-24 months? Did its founders get a good payout from that, or were they just grateful to get funding to continue the project with someone else's capital? I can't tell from the article but this seems like a darned flash in the plan.
Compare - I sold my bootstrapped company in 2018 after 16 years. It had been my entire career, and had hit a wall basically because of me & my big head not being able to work with my co-founder (and old friend & brother-in-law). Even then I understood the lie you have to tell everyone for the cash - we're very excited, nothing will change, etc. etc. The awful blog post is still up :-O
The acquirers insisted on an earn-out based on profit over the next 12 months. And 2 weeks after the acquisition I realised. I called them on Friday and said "so I had started a lot of projects with a payoff in much longer than this time. Nobody at the parent company seems interested in them, I've contacted (long list of people) and had nothing back. Since you were explicit about short-term profit being the goal, I'm intending to start firing 40-60% of staff related on Monday, which should lift profit considerably in the remaining quarters on my contract - there's no risk to operations."
I had a pearl-clutching call back from the CFO who was shocked SHOCKED at how I would treat my former company. That's not how they do things at (parent company). He would put his foot down and use his statutory right as a company director to stop me. Then he offered me & my co-founder about 20% of the earn-out cap to leave immediately, and we took it.
Of course they fired everyone anyway 3 months later. Maybe I'm just older than the OP was, I was 38 and tired of the whole thing, but (after travelling up a few times to the parent company's offices) I assumed the acquirers would do the worst, most short-term thing possible and I was not disappointed.
(A small consolation was seeing the CFO purchasing gobs of his company's own shares at the near-peak share price following the acquisition - it's declined steadily, and now suddenly, and is stands at 40% that peak).
> the CFO purchasing gobs of his company's own shares
It would be interesting to see how noisy that signal is. I wonder if there is a subset of people that would give a better signal? Maybe an external party that hasn’t drink the kool-aid and has enough inside information - board member? VC?
It sounds like the acquirer was at much fault as the company. Launching a musical instrument at CES is dumb - you go to NAMM (winter and summer), AES, or even NAB - somewhere where early adopters are, and press that will showcase the product to them.
Requiring theory and practice to use an instrument isn't bad design. Compromising creative potential for potential market size just turns it into a toy, not something with staying power.
Killing the android version would have been fine. Music apps and tools have been great on iOS since well before Oboe dropped on Android to fix the latency issues. The poster seems to be as wrong a fit for this product as it was for the market.
All that said if you make a music tool and find an acquirer for any dollar amount you've succeeded. The market is teeny and people don't want to pay for new things.
kickstarters do not provide profits. i personally went through a succesful one and it was the same situation.
i also think it’s lame the article does not mention the marketing cost to reach the 188k funding.
also, building realtime synth / audio apps especially for professional use is a highly specialized job you should not outsource to generic mobile devs. you need to hire people who have been doing that for many years.
android has many audio stack related problems and those still haven’t been solved. someone who specializes in audio apps already knows that.
i get that the author is frustrated but the real reason people probably didn’t buy the product is that it was not good enough and not a “need”. to really want something it has to be crazy good. i’m surprised they got a deal from apple to distribute a poorly executed product.
it sounds like sphero and other parties were wowed by the idea and acquired or partnered with a startup with a prototype that was still far from a real product. i don’t think it’s fair to blame sphero in this case…
> Make sure you’re convinced that they understand the level of investment needed from them post-acquisition.
It’s way more than this. The acquirer also has to share your vision, be willing to let you execute on it without interference, be willing to commit funding for sufficient time for it to grow legs, have deep enough pockets to sustain the investment, and be honest about all of the above. Quite often the acquirer is just as caught up in the heat of acquiring as the acquired is.
In my experience, if you are trying to execute on a vision, acquisitions are supremely dangerous.
> have deep enough pockets to sustain the investment
Exactly! I recently saw someone blame Nissan's failure on how Renault ran the company into the ground. Only problem is that Nissan was on their way to bankruptcy when they were acquired. "Beggars can't be choosers". To be fair, Renault has done Nissan dirty, taking out money instead of re-investing
Honest question, does anyone have some examples of an acquired company thriving post-acquisition? It seems like they just all burn out or stop doing cool things. I’m thinking of examples like Nest and Tumblr, but I haven’t noticed any where I think “wow, they’re really doing amazing things now after being acquired”. I get that many are acqui-hires or done for the IP portfolio, or as favors to founders or other investors to make a few people a whole lot of money.
YouTube, Instagram, Github, Android, Slack, Heroku (until recently), etc. And those are just the ones that were left to their own devices.
There's also a ton that have lost their brand, but melted into the parent company. It's not obvious from the outside, but the tech (and team behind it) goes on to become a vital feature. Like, look at any acquisition by Stripe.
Lastly, companies sell because things are going really well or they're going really badly. This company was closer to the latter, and that has a much smaller success rate – but teams often get continued employment, some get promotions, people make money, etc.
It seems like you’re asking about whether a brand survives the acquisition, but I think there are lots of examples of an acquisition absorbing into the parent company and the parent company being better off and performing well and making good use of the new IP and new talent. I bring it up because I work in a group that was acquired a decade ago and now represents a major division of the parent company having brought it’s product to the parent company’s massive market successfully. I also know several people who’ve started various startups, been acquired, and now run teams based on their original independent product in the parent company under the parent company’s name.
Recent example (last ~6 months): Anduril acquired a 30-person company, Dive, that built autonomous submarines with some novel low-cost process. They had built a small number of vessels for internal testing and maaaaybe had started to generate a little revenue, but nothing serious.
Then, four months post-acquisition, Anduril’s influence earned them a $100M contract to build prototype submarines for the Royal Australian Navy. Dive benefitted from Anduril’s political savvy and connectedness in a new part of the world; Anduril benefitted from Dive’s tech of course.
I watched that happen from the inside during the "dotcom" bust,
Not a startup, but we'd grown to be a public billion dollar revenue organization when we were acquired by a much larger company (not using names here, as I'm sure there are folks on HN who were also there and would remember this and I don't want to doxx myself).
We were very profitable and had an excellent company culture, with almost everyone pulling in the same direction. It was one of the best jobs I've ever had. Until the acquisition.
After acquisition, as significant portion of our services were essentially given away to customers buying hardware from the acquirer, and our revenue plummeted.
New top management then proceeded to destroy the company culture in an attempt (a guess) to bring it more in line with the acquiring company's culture.
It was a disaster, and after a half dozen rounds of layoffs and 3-5 years, the division (that was the original company) was sold off for ~5% of the original purchase price.
I'm sure there are situations that make an acquired company better, but that wasn't the case here. And more's the pity.
Having been on the acquiring side of a few of these, I've seen where the company being bought didn't really understand why they were being bought. It can be hard to to internalize why you're being bought as being bought is a sign of success. Some of the acquisitions I saw we were buying something very specific yet the company had a lot more. People get excited about their future roadmaps when they're often being bought for what they have, it can be hard to turn that off.
And lets not get started on the 1-2 year slowdown that an acquisition can put into a team.
The Fuzzy Pumper Barber Shop. WTF happened to jingles? This one was dead and buried in my head until just now.
Edit: see the sibling comment, they gave a link. Brother need a little off the top.... and I never even had this or most of the crap whose jingles are still in my head.
I assume it means https://en.wikipedia.org/wiki/Fuzzing which in this context would be trying the idea with multiple input parameters until one works best. Kind of like neural networks.
I may be watching a train wreck of an acquisition right now, on the acquisition side no less. It makes little sense and everything I'm involved with over it seems to boil down to "we want it because we want it."
The classical (and to some degree unfair) view of financial controllers (often wrongly labeled as "accountants") is that they only want to cut costs.
Basically there is a very negative view of finance, that they want to cut costs to the bone, optimize everything, dont care about anything else then the numbers etc.
In some ways it is a wrong view, but there are tons of people who see most things in a company as "cost centers".
So maybe get someone to do cost planning for you and then compare actuals to your budget - often even setting up a budget allows you to understand where the money should go. Other thing is where it actually goes.
If you are talking about personal finance then the time cost of properly analyzing where your money goes is high, but even with crude registering you probably can get an overview where most of it goes. Then you can work on biggest positions to try to minimize them. Those personal finance subreddits probably can help you with such analyses. There are also those "frugal" communities.
But for most people: the more they earn, the more they spend. Also some of those frugal types are just weird (e.g. run around with a broken phone while you use it every day).
I think the real lesson is only sell what you’re willing to live without. Even if the initial contract says you get to stay involved, I wouldn’t take that unless I had to.
If the money isn’t enough to make me walk away from a project, then the money isn’t enough for you to bug the project.
Dum question from someone who has no business experience but trying to start a company.
If my goal is to build something useful for my customers, is there any harm in converting the company into a co-op or something when I get bored? I have a lot of money (not bragging, because it’s not like millions and millions, but I’m fine) so I’m not motivated by that. Rather I want to solve problems and create an environment where my team can prosper professionally and we are all on the same mission. I’ve worked at companies before where the culture was amazing and it was actually a joy to work. And it’s not like we were some hippie company - I’m talking unicorn status and later an IPO. I want to emulate that sort of environment where people were legitimately happy to be there.
Instead of selling to some PE firm to come ruin things, has anyone converted their company into a co-op or is there something better where the remaining employees can be empowered to keep the engine running and steer the ship to new shores?
There are reasons why successful co-ops are uncommon and that most successful organisations are top-down structures. A good way to cheaply and deeply learn the reasons for yourself, would be to join some co-op’s (or perhaps charities) in your area. A little experience within a successful co-op and within at least one unsuccessful co-op would go a long way. Good luck!
Please tell me more? I've a bit been wondering if a non profit could be better than a Limited Liability Company for some future projects
And I work 60h/week already, cannot join two coops to learn more :-(
I suppose one problem could be that they'd try to make decisions via consensus or votes -- but there might be one person who is brighter and/or knows more than the others, and leaving most decisions to that one can be an improvement?
Imagine the Linux kernel starting to make decisions via consensus or votes, rather than a BDFL?
I have little direct experience, but what I do have all points towards failures of consensus.
Look at the most recent company you worked for, and from your colleagues think of: one idiot engineer, one idiot manager, and one idiot admin. Now imagine that they each feel they have equal rights as anyone to share their “input” into that business, and imagine trying to find consensus with you. Now multiply that problem by 10, because it isn’t just idiots that want to have their say, and most people have valid input that needs to be ignored because most businesses need a leader to provide focused power on a few plays.
I know of successful co-ops, but those seem to usually have a corporate structure and members have limited power, and I don’t know their internals.
Do you feel you have the skills to manage a co-op? Superficially you appear to be somewhat idealistic and innocent of the difficulty: although I think most traditional startup founders have and need those traits! Advice is cheap and experience is expensive: go with whatever works for you.
I'm leaning towards an LLC (and not a non profit), even more now.
The engineer, admin and manager example sounds frustrating!
I can run a company (it seems) but a co-op, then I'm afraid one would need much greater charisma and persuasion skills, and also enjoy that?
Otherwise the co-op would be unstable? With equal voting power, then any member with bad ideas and persuasion skills would be an existential threat? But in a company, s/he could just be fired? (Or contract not renewed)
> We set Ghost up as non-profit foundation so that it would always be true to its users, rather than shareholders or investors. Our legal constitution ensures that the company can never be bought or sold, and one hundred percent of our revenue is reinvested into the product and the community.
People are always more comfortable volunteering for hardship than having it thrust upon them. Course, to the employees I’m not sure it’s all that much different. Some suit shut it down. A different one than the one who promised us he wouldn’t, but what comfort is that?
Three data points: The best econ prof I ever had taught us, "Someone wants to buy your dream? Great! Sell it! You'll have another one." And two start ups I worked for, sold to Microsoft, and destroyed by the absent managers from Redmond.
I've got a new dream now, and if the boss sells it, pfft, I'll just keep dreaming.
My startup was acquired and it was fucking hell. Next time I get acquired I'll make sure to have everything in writing and planned for me to get out within one year.
I think that’s a pretty reasonable plan, and I would do the same. I don’t want to end up with a large stake in something I don’t have a corresponding level of control over. Sticking around to hand things over smoothly makes a ton of sense, but transitioning from founder to middle manager at your acquirer is a nightmare (depending on your personality).
That’s a very good takeaway. I’m curious how you ended up being acquired without having everything in writing, and what hell ensued, can you share the story?
I honestly think the BB8 toy killed sphero. They mistook a flash of luck and a fad for PMF. It also made them cocky. Next thing I knew they were calling it a “robot” which while possibly technically true it was more of a neat remote control car that cost a fair amount of money. This was at time when you could by cheap rc helicopters that actually flew for $20.
I always understood the BB8 saga as Disney looking for a toy company to work with then designing a movie character that fit into the company’s capabilities. So it wasn’t luck as much as a single large enterprise contract that swallowed any other focus.
Founders can offer to buy the rights back later. I did this exactly - sold exclusive rights to software and team was hired onto acquiring company, years later acquiring company decides to shut down software arm and terminate existing service agreements. I offered to buy the rights plus our team back (for about 1% of the initial sale - they were going to just shutter it all), and immediately engaged the clients in new contracts. That purchase agreement was a doozy, spent more on lawyers than buying the rights back.
There are always things the acquirer can do to not exactly discontinue a product, but effectively do nothing with it.
If you look at the film industry, they are masters of this. Buying scripts and sitting on them etc. A company could buy your widget startup and say they are still selling it, but mail order telephone sales only.
For some of my trades I use capital to purchase shares on the stock market
For some of my trades I have a 100% premine of shares and sell them at a higher price until I’m down to 20% left but only because I minted 500% more shares to sell to the PE guys
> For some of my trades I have a 100% premine of shares and sell them at a higher price until I’m down to 20% left but only because I minted 500% more shares to sell to the PE guys
I didn't understand your example at all. Care to explain?
When you create a new company, you write down an arbitrary number of shares that it is made of, and give yourself 100% of them at $0.00.
From then on, the goal is to sell shares at > $0.00
But instead of selling any of those shares, when an investor comes you create a bunch more shares at $0.00 and sell them, dropping your percent of ownership to < 100% while not incurring a capital gains tax event.
The majority of acquisitions and mergers fail. It should come to no surprise for those whose company or employer is acquired that the acquisition will fail as well.
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.