4 ms·

> The smallest unit of software ownership and delivery is the engineering team. I see where this is coming from, but it's also pretty sad. In my experience, it

> The smallest unit of software ownership and delivery is the engineering team. I see where this is coming from, but it's also pretty sad. In my experience, it tends to create environments where engineers are second-class citizens compared to managers or product: we're just responsible for "delivery", but can't independently make any real decisions beyond a tiny scope. Our timespan of discretion becomes measured in days or weeks, while, on the best teams I've seen, it's measured in months, quarters or years. It's counterintuitive, but you absolutely can have real individual owernship for engineers without creating single points of failure or brittle systems. It's a matter of having other sources of slack, encouraging quality work, and giving people a lot of room to fluidly adjust what they're working on when. Folks still have real ownership and can make longer-term decisions on their own, but they also collaborate in ad hoc ways and share tacit knowledge, so that somebody else can jump in, help out or even take over in a pinch. 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. In practice, the model I saw did end up with more rewriting than a normal team—but we were still way more productive overall, even accounting for the rewrites! Turns out that rewriting systems incrementally, in self-contained chunks, is an amazing way to both evolve the design and to build up instutitional knowledge and capacity. It looks like waste, but it's actually slack that is crucial to making your system as a whole more flexible, adaptable and resilient. (In fact, that's true of a lot of the "waste" top-down management systems try to reduce—I'm incresingly convinced that anybody trying to optimize software team "utilization" is actively sabotaging the work!)

dkarl 1y ago
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.
- maxsilver 1y ago
  > They don't have the competency to know what to reward. I'd even take this a bit further, and say this is basically an argument that the engineering manager, engineering/dept VP, and CTO all need to be engineers or past-engineers themselves, so they actually do have enough competency to know what to reward.
  - spimmy 1y ago
    just made this exact same point myself, lower in this thread. (author here)
  - tikhonj 1y ago
    the best manager I ever had was a VP who came from a banking background—the key thing was not that he had written a lot of production software himself, but that he had seen what great software looks like (apparently he worked closely with the core Slang/SecDB guys), and was willing to trust engineers who could build similar styles of tools on the other hand, the recent skip-level I had that got me to quit in six months was an engineer himself, but had no real opinion on code quality or anything more than a superficial, process-oriented understanding of the dynamics on the team :( moral of the story: taste is necessary; direct technical experience is mostly necessary, but nowhere near sufficient
    - marcosdumay 1y ago
      What you are describing is direct technical experience. That the banker did have, but the one titled as engineer didn't.
  - EPWN3D 1y ago
    Honestly, I don't even think that does the trick anymore. Once you're on the management track, you get infected with the same MBA bullshit as the rest of management, and your brain rewires itself around that culture and those incentives. I've worked for VPs who were former engineers, and they eventually lost their appreciation for the artistic side of the discipline and got obsessed with features, demoes, burn down charts, etc. If you want to solve this problem, you need to keep the professional manager class out of your org. Because once they get a foothold, they fuck everything.
spimmy 1y ago
i'm struggling to see how what you are saying you value is any different from what i am saying i value (author here).
- tikhonj 1y ago
  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?
  - spimmy 1y ago
    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.
    - tikhonj 1y ago
      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"
    - Jensson 1y ago
      > 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.
matthewkayin 1y ago
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 product, they'll tell you to ship it and won't give you a chance to rewrite. I think the best way to solve this is to flatten the hierarchy. Get rid of the notion of managers who rule over engineers and give ownership of the code back to the engineers. Have the engineers and product "owners" make decisions together in a democratic fashion.
xyzzy_plugh 1y ago
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 level for software ownership to settle there comfortably: staffing changes, job security, career growth are the obvious ones, but the dysfunction (even in otherwise healthy orgs, there's always some amount) will find the shortest path to complete the circuit here. I like to think of it like a gearbox. If you only have one gear, and you break it, or wear out all the teeth, then you don't get to go. If you have many gears, well, the ride may be uncomfortable at times, but you'll keep moving.
- almosthere 1y ago
  I personally think _most_ people should treat their jobs as a _day_ job - unless they have actual ownership in the company (beyond what would be a 50-100k payout at option time)
  - thePhytochemist 1y ago
    I think this is key when people talk about "ownership". Actually owning a product means that if it fails you're holding the bag, if it succeeds you take the profits. And you have full control over it. Unless a company actually wants to do this I wish they wouldn't use that english word. Trying to hire an employee and tell this story that they "own" the product is just silly. It's like companies that try to describe themselves as a family - just kind of a weird and incorrect use of a real word that has other meaning.
  - ghaff 1y ago
hnthrow90348765 1y ago
>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.
- deleted 1y ago
  [deleted]
athoscouto 1y ago
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.
- bsoles 1y ago
  I blame Agile and the like for fucking up individual ownership by treating every engineer and every task interchangeable. You can't build expertise by working on a different type of task every sprint...
dkkergoog 1y ago
[dead]
sublinear 1y ago
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.
inky-solver 1y ago
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

dkarl 1y ago

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.

maxsilver 1y ago
> They don't have the competency to know what to reward. I'd even take this a bit further, and say this is basically an argument that the engineering manager, engineering/dept VP, and CTO all need to be engineers or past-engineers themselves, so they actually do have enough competency to know what to reward.
- spimmy 1y ago
  just made this exact same point myself, lower in this thread. (author here)
- tikhonj 1y ago
  the best manager I ever had was a VP who came from a banking background—the key thing was not that he had written a lot of production software himself, but that he had seen what great software looks like (apparently he worked closely with the core Slang/SecDB guys), and was willing to trust engineers who could build similar styles of tools on the other hand, the recent skip-level I had that got me to quit in six months was an engineer himself, but had no real opinion on code quality or anything more than a superficial, process-oriented understanding of the dynamics on the team :( moral of the story: taste is necessary; direct technical experience is mostly necessary, but nowhere near sufficient
  - marcosdumay 1y ago
    What you are describing is direct technical experience. That the banker did have, but the one titled as engineer didn't.
- EPWN3D 1y ago
  Honestly, I don't even think that does the trick anymore. Once you're on the management track, you get infected with the same MBA bullshit as the rest of management, and your brain rewires itself around that culture and those incentives. I've worked for VPs who were former engineers, and they eventually lost their appreciation for the artistic side of the discipline and got obsessed with features, demoes, burn down charts, etc. If you want to solve this problem, you need to keep the professional manager class out of your org. Because once they get a foothold, they fuck everything.

spimmy 1y ago

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

tikhonj 1y ago
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?
- spimmy 1y ago
  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.
  - tikhonj 1y ago
    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"
  - Jensson 1y ago
    > 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.

matthewkayin 1y ago

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 product, they'll tell you to ship it and won't give you a chance to rewrite. I think the best way to solve this is to flatten the hierarchy. Get rid of the notion of managers who rule over engineers and give ownership of the code back to the engineers. Have the engineers and product "owners" make decisions together in a democratic fashion.

xyzzy_plugh 1y ago

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 level for software ownership to settle there comfortably: staffing changes, job security, career growth are the obvious ones, but the dysfunction (even in otherwise healthy orgs, there's always some amount) will find the shortest path to complete the circuit here. I like to think of it like a gearbox. If you only have one gear, and you break it, or wear out all the teeth, then you don't get to go. If you have many gears, well, the ride may be uncomfortable at times, but you'll keep moving.

almosthere 1y ago
I personally think _most_ people should treat their jobs as a _day_ job - unless they have actual ownership in the company (beyond what would be a 50-100k payout at option time)
- thePhytochemist 1y ago
  I think this is key when people talk about "ownership". Actually owning a product means that if it fails you're holding the bag, if it succeeds you take the profits. And you have full control over it. Unless a company actually wants to do this I wish they wouldn't use that english word. Trying to hire an employee and tell this story that they "own" the product is just silly. It's like companies that try to describe themselves as a family - just kind of a weird and incorrect use of a real word that has other meaning.
- ghaff 1y ago

hnthrow90348765 1y ago

>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.

deleted 1y ago
[deleted]

athoscouto 1y ago

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.

bsoles 1y ago
I blame Agile and the like for fucking up individual ownership by treating every engineer and every task interchangeable. You can't build expertise by working on a different type of task every sprint...

dkkergoog 1y ago

[dead]

sublinear 1y ago

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.

inky-solver 1y ago

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