I see where this is coming from, but it's also pretty sad

People outside of engineering can't give engineers immediate credit for long-term decisions. They don't have the competency to know what to reward. I'd go further and say that even within engineering, people outside of a team can't give immediate rewards for work whose long-term value is internal to the team, for the same reason: they don't know if the work you're doing is actually valuable or is just superficially similar to the kind of work that often does have long-term value. If you're confident enough in your long-term decisions, and how you spend slack time, then you should be fine with being rewarded for delivery, since you expect your long-term work to pay off in future delivery and future rewards.

i'm struggling to see how what you are saying you value is any different from what i am saying i value (author here).

I think that rewrites are an important part of how software is written, and it's an important part of being "agile", in the sense that you can go in and write a prototype that's coded very simply without much regard for long-term architecture, knowing that requirements likely will change and that you likely won't get the design right on the first go anyways. Coding is like writing, in the sense that it's often faster to write a sloppy first draft followed by a better second draft than it is to agonize over getting the first draft right on the first go. The first draft is generative. Its purpose is not to be good but instead to let you get something built quickly and to let you explore the problem, so that you know what edge cases you'll need to account for in your final architecture. But this still of working will never get through management because the moment you show them a working pr…

I used to share this mindset, and I still agree that individual ownership is possible for engineers. Unfortunately many, many engineers simply do not want it. I would reckon most if not all engineers are comfortable with ownership at the team boundary, but many simply do not care beyond that. It's just a day job. Individual ownership at the individual engineer boundary can breed distrust within a team or org, but often alienates team members who like their job but aren't trying to lead, at least with respect to what ownership entails. In this blended environment someone almost always ends up without agency. Sometimes no one gets agency. Who wants that? It's surprisingly simple and effective by comparison to give a team agency and ownership, usually in part because of the dynamic of having a manager or lead to begin with. Simply put, there are too many modes of failure at the individual l…

>we're just responsible for "delivery" Ownership has never gotten me anything but more headache. I'm just here to put the things on the pages. We've got to charge for additional responsibility. Manager/executive pay scales with how many people they're responsible for, no sense in not giving developers that too.

Agreed that you can have real individual ownership. Not only that, I think that is the only way to be really "productive". But I think that is beside the point. Individuals are not fungible, but team members are - or at least can be, depending on how you structure your teams. And as your org grows, you want predictability on a team level. Skipping a bunch of reasoning steps, this means having somewhat fungible team members, to give you redundancy. The engineering parallel here is the tradeoff between resilience and efficiency. You can make a system more reliable by adding redundancy. You make a system more efficient by removing redundancy.

It's extremely simple. Stop hiring/promoting into management who don't know the job. This is extremely common in every other industry, and I and legion of people will keep saying this. It only seems like not a big deal while "good enough" is a really low bar.

that does work in smaller places, but there are many reasons and many books about exactly why this does not scale or work at most organizations. > I'm being a bit vague, but all I can say is that I've seen this before, and I'll know it when I see it again. being vague does not work when talking about organizational design so telling people that they don't need to build teams around systems is a bit irresponsible