Live data from Hacker News

Watching an acquirer ruin your company

startupwin.kelsus.com

51–60 of 347 posts

Re: Watching an acquirer ruin your company

#51

Earlier quoted context omitted.

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!"

Projects tend to need substantially less planning than people think.

The joke at my previous job was "Months of development can save days of planning."

The management in the company didn't plan anything and the meandering development process showed it.

Please don't underplan. It's awful for morale to throw away work because of bad planning.

Re: Watching an acquirer ruin your company

#52

Earlier quoted context omitted.

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!"

Projects tend to need substantially less planning than people think.

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.

Re: Watching an acquirer ruin your company

#53
post #37

Earlier quoted context omitted.

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 sw…

Classic. And when you tell incompetent management that 9 women can't deliver a baby in a month, they'll proceed to try with 10 women.

This is so common it hurts.

I wonder where this comes from. Is it just hubris mixed with incompetence?

Re: Watching an acquirer ruin your company

#54
post #50
post #37

Earlier quoted context omitted.

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 sw…

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.

Re: Watching an acquirer ruin your company

#55
post #50
post #37

Earlier quoted context omitted.

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 sw…

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 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...

Re: Watching an acquirer ruin your company

#56

Earlier quoted context omitted.

Projects tend to need substantially less planning than people think.

The joke at my previous job was "Months of development can save days of planning." The management in the company didn't plan anything and the meandering development process showed it. Please don't underplan. It's awful for morale to throw away work because of bad planning.

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.

Re: Watching an acquirer ruin your company

#59

Earlier quoted context omitted.

The joke at my previous job was "Months of development can save days of planning." The management in the company didn't plan anything and the meandering development process showed it. Please don't underplan. It's awful for morale to throw away work because of bad planning.

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.

At google it was repeated that Sergey Brin used to say "all work is throwaway work, it's only the time horizon which is in question".

Re: Watching an acquirer ruin your company

#60
post #10

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…

>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.

Post reply on HN