> * Give no feedback unless things go wrong

> * Treat your highly educated, intelligent and motivated devs like children by misusing agile in order to micromanage them

These two points made me cry. I suffered my very first burn-out due to that and although having a higher degree in computer science and love towards programming this really made me feel like a piece of shit. I have the feeling that it's really hopeless and it wants me to make the change to IT-Consulting instead of software-engineering.

Also hits a nerve for me. Our mgmt just shuffles devs around from fire to fire without really just sticking the same devs to a single project until it's done.

Then we get questioned why projects are not done.

And don't get my started on our new Agile process. We have scrum meetings for our scrum meetings. We have mgmt. popping in the project level scrum meetings to tell us what is and isn't scrummy enough to talk about during the meetings.

And I moved to this company after thinking my last company didn't have it together. Man, I was wrong. No one writes comments here, or any tests. We just "make it work". Pay is awesome though...

LPT: Don't complain, but suggest improvements. Stop looking at "management" as some evil superpower that can't be reasoned with. They're just people with different responsibilities. Align.

define awesome? Currently in a similar situation...

~95k inc. bonus. Good healthcare, paternity leave, etc.

Oh dear, I'm really sorry for touching a nerve! I think management often have zero insight into how much many devs care about their work. Not all - I'm sure there are plenty with a thick skin and/or that care little beyond getting paid - but some of us are only capable of delivering our best given the right conditions. Lack of feedback is one of the most serious red flags I would say, and shows either the company is seriously dysfunctional, or that they absolutely do not give a shit about your progress. At that point the job should become just a paycheck until something better comes along. The funny thing is when they expect you to do your best work despite not keeping up their side of the bargain!

That is very true for me. A lot of managers don't understand my motivation at work, they don't understand that what actually keeps me going is the love for technology and for software engineering. That is being able to learn and develop interesting things, to research, to create, that motivates me. I can't bother on corporate politics. I don't care on going up the corporate ladder (I'm already in a top engineering position, I don't want to stop doing coding to become some sort of manager/architect/VP/etc).

Unless you're doing your own thing, consulting is often way worse.

> I have the feeling that it's really hopeless and it wants me to make the change to IT-Consulting instead of software-engineering.

Doesn't IT Consulting involve a fair amount of software engineering? Or by IT Consulting you mean like design high level architecture in a way that is abstracted from the app(s) it runs (e.g. setup a docker swarm)?

>Insistence that all devs time must be billable

That one can hit all areas of ICT real bad when the company is a managed service provider, leading to a 'Chefs kitchen/Plumber's bathroom' where the company provides great outsource ICT services offering to its clients, but runs an absolute shitshow for it's own systems because they're chronically under resourced (you can't bill it, so don't spend time on it).

That has extra interesting results when such a company tries to spin up and sell services which it's built/hosting/maintaining/developing itself.

This last point is universal in companies that bill hourly.

I think I get what you mean by 'Chefs kitchen/Plumber's bathroom', but I've never heard either colloquialism before and can't find anything on Google, either. What's the origin of these terms?

Based on the context, something like "the cobbler's children have no shoes" meaning they are too busy doing paid work for others to the same work for themselves.

https://english.stackexchange.com/questions/159004/the-cobbl...

I don't think it's related to too many chef's in the kitchen. More a reference to chefs having a spotless kitchen at their day job, but a messy kitchen at home. Likewise for plumbers.

"Too many chefs in the kitchen" is the first one. Not sure about the second, but probably the same kinda thing.

There is a required reference here to "Too Many Cooks". Thanks, Adult Swim!

Hadn't heard that one before, interesting observation.

A lot of non-tech companies treat IT as a cost center and that can lead to short sighted decisions that cost them a lot in the long run (or more accurately, they fail to realize benefits that were available to them with appropriate investment).

But it seems counter intuitive that this effect can be worse for some tech companies, where a major part of their business involves convincing clients to treat their tech as more than just a cost center.

Like, you have an entire staff compliment of developers, architects, PMs, engineers and customer service staff, and your own entire ICT practice is a disaster? HOW?

I ended up having to draw people's attention to it by pointing out 'this is your single biggest client, and receives the least attention of them all'.

Loops into the old 'eat your own dog food' wisdom, but from an angle that seems to often get missed.

Well you could be like IBM which sells remote working solutions but has banned it for their own staff. Or maybe that was HP, or both.

That was a slimy downsizing measure. IBM doesn't have to pay severance if their remote workers quit on their own rather than come in 9 to 5.

Because of this mindset, companies who decided to outsource IT as an obvious cost optimization realized how their company actually runs.

Specifically that there are huge off-the-record operations (outside of the ticket system). The more VIP the problem is, the less tickets.

And suddenly, the people supporting them (particularly if they were outsourced but stayed in the company as contractors, and were pissed off) had one sentence "open a ticket". Doesn't matter if this is the CEO asking, or something "urgent", ticket it is.

And the gates to hell opened.

Source : me not being IT anymore (huge company) but strongly advocating against the outsourcing (pointing to the above), and then taking a backseat and watching the world burn with popcorn in hand.

> * Trying to use one off contracts as a way of building resellable products

Can you tell me why? Sometimes, asking a client for 50k instead of 80k with a "spin-off" agreement can pay to both parties. The client can get long-term support with new features without the need to pay for it.

1. Building a product for a specific client takes less time than building a configurable generalized product that you can sell to others. The business may be willing to take a $30k haircut as in your example, but are they also willing to have development take 50-60% longer (and the additional financial costs of that)?

2. Once it's a generalized product, how will that first client feel about being told that a new feature they want won't be built?

3. As a corollary to #2, the first client will also look at it as something they purchased, not a service that you now offer to them. They'll demand things and the business will need to have the fortitude to tell them no, and most businesses can't (or won't) do this.

It's very hard to get a scenario like this to work out where people are still happy with the arrangement 2-3 years in the future.

In my experience, often the product ends up being molded to fit the particular client (it's custom software, after all) and then the cost of altering it for other clients is perceived as too steep. Or you end up with a bunch of similar, incompatible projects.

This was the one that really struck a chord with me. You start of trying to take the product you created for one specific client and then generalising it.

You end up, in practice creating a individual bloody application for each client.

(Not a coder, more a manager who created specs and tried to shield the coders from the worst of the shit-storm).

It is not individual applications. It is SAAS.

I agree that sounds like a reasonable approach - but in my working life it's always been seen as this fantastic wheeze of 'let's charge one customer to build something and then go off and sell it to everyone else!'. It seems like a great idea, but the usual story is that either making it generic burns up days that would otherwise be spent meeting the specific customer's requirements, thereby ensuring a worse product, or you stay on track with the customer's requirements and ditch the idea of making it generic as soon as days get tight.

This is one of the things that always makes me groan, along with 'and you can learn x technology along the way!' >:|

Out of the blue, I was once expected to set up a recording studio and learn the electrical engineering side of things 'along the way! You've got the afternoon, in addition to your normal duties.' My background is in CS, not physics or engineering, so you can imagine how that went - and of course, the manager wasn't to blame.

Sometimes it can work. More often it starts innocently and mutually as you describe, but it very quickly becomes a game of firefighting and drains innovation within the product line. Next thing you know, you're selling based on roadmap features and don't have control over your own product anymore.

Unfortunately I've just thought of another - moaning about time estimations - even after these have been pared down to the absolute minimum with the expectation of putting in extra hours on the side to meet the deadline!

Good to get this stuff of the chest sometimes.

oh that one drives me insane.

"This will take 40 hours" (I hate estimating in hours for individual tasks as there's no way to average the overrages with the ones that went under estimate).

"Thats too much, can you do it in 20?"

"No, 40 is already underestimating imo"

"Well, it won't fit in the project plan at 40"

"Sorry, that's really as fast as it can"

"Well, lets put 20 and either make up the time or just go over" (wtf?)

> All of this inevitably leads to a bunch of pissed off devs. The ones that are happy to eat it become the golden boys and get promotions.

The question asks about behavior that management repeatedly makes. If management repeatedly makes these mistakes, then the mistakes should become expectations, so one should simply accept them and understand that they are part of the game being played. If they are expected behaviors, being "pissed" about them simply is foolish.

Of course, by "accept them" I don't mean one should never try to influence or change the situation, but reacting emotionally rather than rationally is silly. Even if there are no upward-feedback or 360 review procedures in place at the workplace, one can articulate these concerns more diplomatically (less offensively) and send out an email requesting that they be considered. One can even illustrate and trace through how such mistakes have impacted recent projects.

It seems to me that the ones "happy to eat it" simply understand that others have limitations and make mistakes and will try to make the best of the situation. It sounds to me like such people indeed deserve the promotions more than people who bring anger to bear on their work.

> one should simply accept them and understand that they are part of the game being played. If they are expected behaviors, being "pissed" about them simply is foolish.

Does this apply to athletes who are upset when referees seem to be consistently favoring their competitors? Does it apply to people living under an oppressive government? Does it apply to a person who is being verbally abused by a spouse?

Sure it'd be great if these people could seek to improve their situation through rational means, or perhaps just accept it if they can't change it, but humans and emotions don't work that way.

> reacting emotionally rather than rationally is silly

Humans are emotional creatures. Expecting humans, even yourself, to act rationally shows a misunderstanding of human psychology and behavior.

That sounds a bit like you are suggesting excusing bad behaviour, or blaming the victim. If someone warns you they are going to hit you before they hit you, does it make it hurt any less?

Also when eating it means 60 hour weeks to make up for terrible managers (all the while collecting their substantial pay packets) I'm quite happy to walk out the door and let then find someone else to be abused.

Passed a telephone interview today, got a f2f next week, hopefully onwards and upwards soon.

> * Give no feedback unless things go wrong

As a DevOps engineer, I feel it all the time (and not only from managers)

Ah, the realities of supporting IT infrastructure. When things go right, management wonders why they even pay you. When things go wrong, management wonders why they even pay you.

> * Inadequate training and expectation devs can just piggy back learning technology x from scratch whilst writing production software using it

Yeah that's funny, believe it or not - I prefer the exact opposite. At my last jobs I had a hard time diving into new technologies unless I knew them completely. Thus I think synchronization is an important thing...

To be fair, these managing behaviors happen in other areas like civil engineering consultancies. In fact, it happens so frequently, I really don't know what a "correct" managing behavior looks like.