[YmiYugy]

That sounds like a management error, not a Pete problem. If Pete was told to get a demo done as soon as possible, that's what he did. And in many cases that's not a bad thing for management to tell people. Finding product market fit, usually trumps tech debt. The thing is, that management should know, how time intensive and difficult it can be to turn a cobbled together demo into a production system.

[intelVISA]

Pete's just a rational actor in this scenario, the real issue is management with no insight into the reality of what they're 'managing'.

[photonthug]

Mostly agree, although Pete is kind of a jerk if he’s self aware enough to notice exactly what he’s doing to repeatedly and intentionally exploit this pattern of ignorance in management anyway.

But engineers blaming engineers that benefit from being a rational actor inside the mainstream incentive structure of corporate life is basically a distraction, because it gives management a pass for their mismanagement. Like, you don’t have to know the details, but it’s pretty fundamental to understand / recognize / triage tech debt.

[roenxi]

What choice does Pete have? There is a certain romance in defying management but that sort of move is ... career limiting in multiple ways. Management are not there to be defied.

Persuasion and honesty are great tactics with good managers. With bad managers they tend not to work. Bad managers will demand bad software and only be happy when they find someone to deliver it.

[photonthug]

> What choice does Pete have? There is a certain romance in defying management but that sort of move is ... career limiting in multiple ways. Management are not there to be defied.

Pete's got a choice about whether or not to act with integrity, same as everyone else at pretty much every other fork in the road. If management orders you to do something stupid, ways to act with integrity might include: you can say no, or you can do it under formal or informal protest, or you can do it under the condition that related technical debt is prioritized in a timely fashion, etc. There are usually many options for a proportionate response. Design docs with some formal structure will often increase accountability, or since management isn't reading the code anyway perhaps a bare minimum is a comment for posterity that says "Code written under duress. Senior manager SomeGuy said on SomeDate that this would be temporary and can be rewritten by OtherDate" ?

In terms of acting without integrity, sure it's possible to go through a career/life acting out endless scenarios where you basically enter into a conspiracy with your direct superior to screw the other people at your level and to a lesser extent the company in general, all so that you can possibly go one rung up the ladder and do the same thing again. Setting aside the ethical question of how this effects others, and whether or not this is a soul-crushing and dehumanizing thing for Pete to do to himself.. my guess is that most engineers will avoid this mainly just because they'd find ladder-climbing more boring than problem-solving.

> Management are not there to be defied. [..] Bad managers will demand bad software and only be happy when they find someone to deliver it.

Oof. Lucky that when people talk about engineers working "down in the trenches" or "on the front lines" it's usually just making apps or whatever and not actually soldiering, otherwise the whole "just following orders" thing can get ugly. Bad outcomes may always happen regardless, but it makes a big difference to me whether I'm the one that's responsible.

[motorest]

> Pete's just a rational actor in this scenario, the real issue is management with no insight into the reality of what they're 'managing'.

That's the norm, isn't it? The bulk of product managers aren't even technically oriented, let alone software engineering experts with a deep understanding of their own codebases.

Once I worked with a PM that quite openly stated he had to google what was a frontend and a backend developer and still failed to get a clear idea of what they did. How do you explain concepts such as technical debt to this sort of character?

[mrngm]

Find out their frame of reference, look for comparable concepts in the real world. For technical debt, this scene from Malcolm in the Middle (S03E06) https://www.youtube.com/watch?v=AbSehcT19u0 might be a good comparison.

If you refuse to explain relevant concepts to your PM, as a neighbouring commentor suggests, that increases the knowledge gap between you (or your team) and the PM. I think it's in the best interest of both the team and the PM that they have a shared understanding of what happens within a project. On the other hand, if the PM is not interested in any of those details, that is a sign that they might not be a good fit in that part of the organisation.

[intelVISA]

You don't, PM is mostly secretarial. If the actual line manager doesn't understand domain basics they're managing in name only: a deaf conductor.

Sure it happens often because tech is a very profitable, grifter magnet, but we really shouldn't normalize it nor expect to solve what is ultimately an organizational problem.

[tacitusarc]

It sounds like folks don’t understand that part of engineering is solid technical communication up the chain. Sometimes you’ll get a manager who just wants you to push the thing through and plugs their ears, and that sucks. But in my experience, what managers (and execs, for that matter) want is someone who can do the work AND explain the trade offs in terms of business value.

If you are an engineer with a reputation of getting things done, they will listen to you. They may not always follow your recommendations, but often they have context you do not have.

Admittedly, some managers are just ladder climbing batards who will make bad calls regardless.

[rrr_oh_man]

> Finding product market fit usually trumps tech debt

This, 100 times.