Hacker News Reader

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

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.

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

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.

> strict deadlines and OKRs

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

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.

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.

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

Those aren't the only two options. You can try to get a team to develop systems that any other capable software engineer can pick up reasonably (such as via effective documentation, and reasonably maintainable nature of the code).

One of the biggest barriers to that (besides teams needing guidance on how to do it) is conflict of interest, which is a factor in the why. I started saying it upfront with founders at my last company, when speaking of who we wanted to hire, and how engineering should be done: "One of the jobs of an engineer is to 'document themselves out of a job'." Then I add something like "And the company has to realize that engineers who can and will do that are generally the best engineers, and extremely valuable to the company."

Though, if the engineers didn't trust management (e.g., not exhibiting analogous professionalism and duty, such only looking at near-term selfish impact), then I can't argue that engineers should go out of their way to be easier for a stereotypical anti-leader to treat poorly. I'd have to appeal to the engineer's sense of professionalism, or of some degree of duty to other team members. I'd also know it's probably only a stopgap, and to give them whatever support I can if/when they look elsewhere for a home for an unusually great engineer.

> Those aren't the only two options. You can try to get a team to develop systems that any other capable software engineer can pick up reasonably (such as via effective documentation, and reasonably maintainable nature of the code).

That sounds nice in theory, but I've only ever seen it be a disaster in practice. It's like that mirror thing from Harry Potter. As soon as you actually try and make a maintainable code base, it starts going the other way.

The only way to truly optimise for onboarding is by writing the simplest, cleanest code possible. Everyone is already trying to do that by hiring the best devs they can. Any further efforts just look like more dependencies, more patterns, and more incidental complexity to act as guard rails in the pursuit of a newb-friendly codebase.

The end result is that new devs are productive at small and simple tasks, but big things take longer. Also, you're never going to find a manager that understands this trade off, so your new dev is going to be left in a terrible position trying to explain how they got so much work done in the first month when they knocked off all the small cards, but now the new feature that the business desperately needs has taken 3 months all by itself.

> Now I'm more convinced than ever that it's better to pay the price of an owner leaving

And it's also worth to pay the price to get the owner to not leave. So many companies seem to think penny-pinching is worth it, or only start giving out raises when actual attrition starts going up and many more people are already invisibly in the process of quitting.

Sometimes you can’t pay the owner not to leave. I’ve had two colleagues die. Another one had a stroke. Granted, I’m now around for like 20 years and a bit, things like that are rare, but no money in the world could have helped in these cases.

And sometimes people are just ready to move on. It doesn’t need to be because they’re underpaid or it’s a bad work environment. I was there and just wanted a change to a somewhat different type of work.

Didn't you all do code reviews, project planning, etc.? These are all ways to get other devs involved and knowledgeable without explicit "you are now the owner".

Does a code review provide the necessary time for someone unfamiliar with the code base to understand all of the business logic that will be affected and where this new addition sits within that hierarchy? Code reviews have never seemed contextually rich to me.

I think the theory is that for code review to be its best, it sits on a contextual pyramid composed of reviewed design docs, pair programming, standups, and all the rest of it. That the "reviewers" are not hearing about the background, motivations, alternatives that were considered, broad implementation choices, etc etc for the first time when the PR goes up.

But often there are some or all of those pieces missing, and so yeah, code review ends up being a bit shallow and performative.

Yes of course, but code reviews do not always tend to transfer a lot of context.

There's no substitute for actually working in a code-base.

If they don’t already feel ownership, it’s easy to just approve PRs without looking at them critically. Why deal with confrontation trying to uphold code quality for a project they don’t really own? I find people don’t pay attention in reviews unless their personal success is tied to the long term success of the project.

All too often, code review amounts to no more than making sure there are no grievous mistakes. Management only cares about you completing your own work, and if reviewing the work of others slows you down, that's your problem. Time spent on code reviews have never counted toward mine or anyone else's performance. A bad PR making it to production certainly gets negative attention, so that's the aspect given priority. The incentives do not align to make code review a place for knowledge transfer.

> Productivity plummeted with every project. It was as if every owner of every project had left the team every quarter.

This only generally happens if you have an environment where every project is a snowflake and the ramp-up time per project is thus high. If you standardize on a stack, then the internal organization of your codebases starts to look pretty similar, and there's less for people to ramp up on when they switch projects. Kill resume-driven-development at your company.

The principle is sound, but your managers' way of implementing it is stupid. Productivity shouldn't go down as a result of knowledge sharing, it should go up.

Me and my peers sharing WW2 knowledge at the water-cooler probably considerably reduced productivity at one of my jobs. Your work on a part of the application that I have no interaction with is just about as relevant. Sharing knowledge just in case costs time.

It’s surely an article of faith in the tech management community, but practitioner experience says it’s dead wrong.

Practioners of the 'hero' model also feel that they have it right. And that's all true right up to the point that they don't and then it is up to other people get them out of their mess.

See also: documentation, testing, refactoring and all the other goodies that keep a large codebase maintainable.

You can always tell the documentation and testing of a shared / non-owned codebase, just like the code: it’s incoherent. A series of random people make random get-in-get-out local changes with no awareness of non-local effects or any kind of design integrity. It’s like Twitch Plays Pokémon.

Do you base this opinion on any evidence?

Because all I have are anecdotes, but all of my anecdotes are on the side of shared knowledge being heavily biased towards safety and consensus building demanding a lot of time. That happens even between two people that mostly agree, and only increase with more people or different opinions.

Of course, some times a bias towards safety is exactly what you want. But on informatics projects, that happens very rarely.

Once in a long while two people can have complementary ideas that make them faster. But it tends to happen more often when one is the clear owner of the project and the other is advising. Shared ownership seems to almost kill those chances.

The project I work in has almost zero knowledge sharing beyond code review and I can tell you it is super ineffective.

Oh, and we don't do ownership thing either.

My anecdata (at multiple companies) supports their opinion.

What matters is that there is a clear owner who is the voice of final decision. In most cases there is no objectively better way to do something, so having a person who is a tie-breaker is beneficial. Of course, they must be involved in actual coding, doing code reviews of other people's code and similar. And other people must review the owner's and each others code.

But, having an owner is not the same as having a bus factor 1. There should be an owner, but other people should know the project and the codebase enough to step in at any given time, even as (temporary) owners if needed. And this is only possible if they actually work on the project, even if the approach that the team (/owner) decides upon is not what they would pick.

I don't know what you would consider evidence but I've looked in-depth at 200+ companies now and as far as I'm concerned this is no longer up for debate. But feel free to see things differently, that keeps me in business. Disaster recovery is a trick that comes with very high fees and what are you going to do about it?

That might work if just one project from each maintainers portfolio was shifted.

> It didn't really matter if the old owner was around to support.

why?

Given the comment elsewhere that having multiple people on a project wasn't possible because they'd not meet their goals then, presumably the old owners were more than busy with their new tasks and helping others wasn't a priority.