[trulyme]

Sorry to say that, but it sounds like you got it backwards. The idea is not to remove the owner from the project, but to always have at least two people working on any project at the same time. Instead of 2 devs working for 2 months each on their own project, put them together on the first project for a month, then on the other project for the second month (simplified example, of course). They both work on their own tasks, but because they are familiar with the code and the project, they can review each others changes.

In my experience this works great. Context switching is a problem, but there are ways to minimize the impact (similar tech stacks, good work organization, clearly defined priorities,...).

[eckesicle]

With strict deadlines and OKRs to hit it wasn't really feasible for people to double up on projects.

> Instead of 2 devs working for 2 months each on their own project, put them together on the first project for a month, then on the other project for the second month (simplified example, of course).

We did try this and it sounds good in theory but as the old saying goes 'two women can't have a baby in 4.5 months'.

In my experience (in this particular team and org) it would've simply been better to invest some time into documentation and suffer a short drop in productivity on a project when owners left.

[trulyme]

I'm sorry to hear you couldn't make it work, but I can assure you that this approach works in practice. You don't get a child in 4.5 months, but you can get 2 children in 9 months.

I agree that not all environments are good at managing developers though (and that is probably a huge understatement).

[fendy3002]

> strict deadlines and OKRs

Simply said, that deadlines and OKRs don't account for bus factor.

[Viliam1234]

Before the developer gets hit by the bus, it is cheaper to only have one developer on the project. For many managers, the economical analysis seems to end at this point.

[bee_rider]

Robustness and efficiency are fundamentally enemies, right? Unfortunately this means that the 'best' solution is often the least robust one that survives.

[fendy3002]

correct. Risk aversions most of the time are expensive. And it's always management's decision to take the risks and cheapen out or avert the risks.

[bobthepanda]

It kind of depends on how exactly the sharing mechanism works.

If you are in a place with code-review, the 2-person system allows one person to at least read the code that is being written as it's being written, so the genesis and reasoning behind such code might be a little more obvious.