[tikhonj]

possibly we're saying the same things in different ways, or maybe it's just hard to pin the difference down in a words

what do you mean by "the smallest unit of software ownership and delivery is the engineering team" in practice?

what's the largest scope of work some engineer can do entirely on their own recognizance?

[bevr1337]

> what's the largest scope of work some engineer can do entirely on their own recognizance?

None. Everything we develop was built on someone else's work. Even when our collaborator is not physically in the room with us, the work is still a collective endeavor.

[spimmy]

well obviously there's a ton of variance here. but in the type of engineering i'm most familiar with, any sizable amount of production services or surface layer being owned by a single person is a bad thing.

individuals can get sick, go on vacation, etc. having it be owned by a team creates resiliency from a people perspective.

[Jensson]

> individuals can get sick, go on vacation, etc. having it be owned by a team creates resiliency from a people perspective.

Resilience against what? It isn't like teams make decisions quickly, an individual will get decisions done faster in almost every case, and if they are on leave right now its just slightly slower than a team.

For example, if you ask a team "can you get this feature in", likely they will come back at you a few weeks later. That isn't faster than an individual on leave, so I don't see what "resilience" even is here.

[inky-solver]

what if that one person quits suddenly because they're not getting paid enough, wants to move to a different country, etc?

> For example, if you ask a team "can you get this feature in", likely they will come back at you a few weeks later.

feature not a bug etc. they should already have and know their priorities and if yours doesn't trump theirs, there's no reason you should get a concrete answer.

[karmakaze]

For most teams that I've worked in, I've chosen certain parts to guard and nurture into a better state. I'll recognize certain shortcomings that have a real-world negative impact and incrementally nudge the design and future decisions in that direction. At some point it will have arrived. Eventually people that are in non-adjacent teams gets to know that I'm the XyzService person. I do socialize the design and implementation changes and even distribute the work and write up thought/decision processes for the team to see. I'll eventually run out of challenging work and move on to another sore area with the team well capable of managing what they've got. If the process were to be interrupted at any time, it's generally not in any worse shape than it started, only failing to reach the desired end improvements.

Edit: My current pet project is eliminating a bad DSL which has led to so many bad implementations and near-identical but different copies because factoring aspects isn't well supported. I started with a PoC, then a Hackdays project, and now with that looking good, the team is willing to convert all of the codebase we maintain so that we can use normal programming language features like static typing and source navigation with easy to follow data flows.

[tikhonj]

well, maybe that explains why I've gravitated hard away from general-purpose backend work :)

I've had a great time on teams where folks can go off and build great tools/libraries/etc that others can use and adapt, without needing a whole team around them—ideally there's lots of collaboration, but it doesn't have to be formally structured

I guess the main difference is that you don't have to operate a tool or a library; if somebody has issues with it, they can patch the code themselves or simply adapt around it in their own code

I also enjoyed working on simulation and optimization problems for similar reasons; there's lots of direct business value, but there's enough slack around it that if I go somebody else can take a model over and maintain it without any issues

unfortunately lots of organizations do not know how to make library-style code "count" the same way a service or stateful component "counts"

[closeparen]

We have a pretty strong culture of individual ownership, but each owner has at least one other person reviewing their PRs, usually several junior engineers contributing, design review at the team level, and oncall at the team level.

When the owner is away, the other people involved keep things moving. If they're away long-term or leave the company, we'll designate someone else to take ownership.