Comment by smokey_circles | Hacker News Reader

Comment by smokey_circles | Hacker News Reader

Parent Full thread

The air quotes sell it.

It's easy to blame management because developers and engineers haven't the foggiest idea what management actually does.

Instead of engaging with that problem, they retreat to themselves where they hiss the name management in dark corners.

Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand.

I absolutely hate how accurate that is because I always thought I was a big boy and I wouldn't need management if I just had "1 good tech idea".

Docker had the philosophy.

Now they are dying after losing the container wars. That's what happens when you have no idea what a product actually is...

>but insist to intercept every decision

Yes, because left to our own devices, developers will not contribute meaningful business value.

There is a better way, evidently it's not agile, but it needs management's buy in, because well they're in charge (get over it in all honestly, none of us actually want the job, trust me).

WE as engineers need to find a better way to engage management.

But those of you who just grumble "management ruin everything" deserve the pain that such a divide causes and we need to stop wasting lifeboat's on that mentality please

> Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand.

I beg to differ.

A dev team doing agile, with a team leader who is a manager/dev, can definitely self-organise. The team leader interfaces with non-dev management, removes roadblocks, and in collaboration with the rest of the devs sets the direction for a sprint.

You need this team lader role to keep the suits off your back, and to ensure the demands are achievable.

Project managers used to be people who wandered around with GANTT charts, and signed-off expenses and timesheets. Very rarely, I worked with a PM who saw their role as removing roadblocks, and shielding devs from suits. Those few PMs were a delight to work with (this was long before the appearance of Agile etc.)

> Yes, because left to our own devices, developers will not contribute meaningful business value.

I think that's rather obvious; management runs the business and sells the products. They set the business objectives, and there has to be clear communication between the devs and management, otherwise you get the "rewrite it all in X" syndrome.

> I think that's rather obvious; management runs the business and sells the products. They set the business objectives, and there has to be clear communication between the devs and management, otherwise you get the "rewrite it all in X" syndrome.

That’s a view in many large corporates. However, in product focused companies and many startups every developer has to have a customer focused mind. Every single day.

I think you'll find that view in any smoothly-running business with an eye on the future - not just large corporations. Unless the management are the devs.

We have to specialise at some point - not everybody that gets hired is going to be an ace industrial strategist. Few devs know how to qualify a sales prospect. If you have such people in management, then as a dev I don't want to do their job for them; they should set strategy and find good customers.

I guess we all have differing perspectives on this kind of thing; one's perspective is partly formed by one's experiences.

I'm not talking about startups - I never worked in one. But I've worked for quite a few companies with < 20 staff.

I agree - though unfortuetly it seems its less common for developers to experience working in a well formed and efficient team these days.

I've found the opposite to be true. Management is what chases the quick buck and not the long term scalability of more money.

When I first started we would be doing 1-off feature requests "because the client would _really_ like it". Everything was justified because money and because "we cant afford to lose that customer!" in our SaaS product.

I saw our main product being neglected because we'd invest so much time in these 1 off features only 1 client would use. All we would ever do would be client features, I was going crazy. It took a lot of talking, and still to this day I have to get him to think in terms of the product instead of the individual client.

Now we make more money, have more clients, and better our product for everyone which in turn gets more clients to get more money.

Doing 1 or 2 features at a time to make 1 client happy or win one deal is called consulting. Not that there's anything wrong with consulting: consulting can be quite lucrative and fulfilling but mistaking it for "product" work is responsible for some large X% of small/early startups failing.

> Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand.

Open source does self-organise, and manages to produce some products of exceptional quality. It’s just almost completely unsteerable.

In a company, you can pretend to order people around. But the truth is that what really matters is how all the personal and political goals happen to align.

I think the difference is having a leader vs shepherds. Most open source projects have shepherds who do a lot of invisible work.

The project I work on has around 100 regular contributors, but also a few small teams, either volunteer or staff, who meet regularly and make sure things move forward in a coherent and sustainable way.

> Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand.

If that's true in an organization, its only because either management has failed to hire developers that can self organize, or management has constructed structures and incentives which inhibit self-organization by developers. Usually, both. Often deliberately, because line managers are often more comfortable passively recieving directives from above and crafting directives for below than any other mechanism of management, since this minimizes conflicts with those in organizational power positions.

If developers were given Operational Research and a couple management classes during university training, the pretense that they are some kind of highly functioning idiots would evaporate overnight.

Problem is that the industry is full of untrained individuals who hustled their way ”fake it until you make it” and will use all their political and manipulatoy clout to justify their positions and fight back any attempt at effective process engineering.

I agree and want to add that sometimes the devs are not very good at, well... "deving".

It is very convenient then to shift attention to inadequacy of others.

There is probably some truth in all of that (although I strongly disagree in some specific points), but also consider that if "management" is incapable to convey their own value, and to cooperate with "engineers" in a non-antagonizing way, maybe they share some of the responsibilities in the divide... esp. if they are supposed to be "management" and take care of rational things (business value being an obviously rational one...) while engineers are basically... playing with their toys?

I don't understand how your vision of things is not also contributory to a strong divide.

> Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand.

Heard of Linux?

Reply on news.ycombinator.com