Comment by nostrademons | Hacker News Reader

Comment by nostrademons | Hacker News Reader

Parent Full thread

I don't think open allocation works either once you get past Dunbar's Number. Instead of making politics go away, it makes it worse. All the political considerations that are out in the open when you're managing a formal org structure become hidden in the backroom deals of who wants to work with who else and how they want to go about doing it.

Here's another observation for you: there is a system where there is no org chart and nobody telling anybody else what to work on. That system is the startup ecosystem. And the end result of that system is what you term "VC-istan": some players become more powerful than others, and they freely choose who they want to associate with based on reputation, or how well their personalities mesh, or pattern-matching on previous successes, or who they went to college with.

The only "solution" I could come up with is that there is no solution. If you give people agency and freedom of association, you will eventually run into situations where their freedom to act impinges on someone else's freedom to act, and it is impossible to let both of them work on what they wish without forcing one or the other to make tradeoffs. Or, alternatively, they could both choose to work alone, in which case it is impossible to build anything larger than what one person can do by himself. Once you see that tradeoff, it's possible to make choices that stake out various parts of that space, eg. another thread currently on HN [1] describes how your options are management, niche development, or consulting as you get older.

[1] https://news.ycombinator.com/item?id=7373301

Can you give an examples political considerations that are out in the open in a formal org compared to open allocation? I think you could make a case for the opposite.

Example 1: You have a group of people who care deeply about performance, reliability, maintainability, and long-term health of the code base. You have another group of people who care deeply about user experience, development velocity, and pushing features to market quickly. In an open allocation system these two mindsets will self-organize into different teams, and will avoid working on each others' projects. The former group will find that the latter are cowboys who throw together messes that they then have to clean up. The latter will find that the former are slow killjoys who result in mediocre products delivered late. The latter group will get to market first, which makes the former believe they're marginalized and gets most of them to quit the company. When the product inevitably starts creaking at the seams, there will be nobody around to fix it and introduce robust development processes.

In a formal org, these would likely be two job functions (call them "SRE" and "SWE", or "Infrastructure" and "Features", say) who are forced by upper management to work on the same codebase. Disagreements between them become explicit negotiations where all the technical issues and trade-offs are laid on the table, and then people can come to an agreement after looking at all the considerations.

Example 2: You have a brilliant developer who is terrible at working with other people and doesn't particularly want to deal with them. In an open-allocation world, he will end up shunned; nobody will want to work with him. In a managed org, it's often possible for his manager to pick off a certain really difficult technical challenge, have him go off and find a solution, and then interface with the rest of the group via some technical API.

Example 3: You have a technical lead who can't let go of the technical aspects, and insists on taking all the most interesting work for himself. In an open-allocation world, nobody will want to work with him, which means that he won't be a tech lead for very long, and eventually he'll probably get frustrated and leave. A manager could gently explain to him that taking all the most interesting work is incompatible with being a team lead, and have him choose one or the other.

Example 4: You have a project where consistency is the whole benefit of the project. For example, you're doing a company-wide visual redesign to make the company's product offerings more consistent for users, or you're introducing a language styleguide, or you're defining standard APIs for communication between components. These efforts typically never succeed unless they have top-down support from a strong leader. Everybody sees the need to agree on a standard, but when it comes to deciding what that standard is, everybody has their own agenda and nobody has authority to decide in favor of one alternative or the other.

Standards committees are good public examples of this: officially, it's "open allocation" where every company and member of the public who wants a voice has one, but unofficially they're dominated by the actions of people who can afford to implement and bring to market a concrete solution.

What's your definition of public? For #2 and #3 things seem less public, since the conversation is between the manager and the individual, rather than the entire team. Maybe I'm just misinterpreting though.

In the context of this post, "out in the open" = spoken or otherwise communicated between individuals. In organizations without formal structure, you still get all the messy emotions and politics, but people don't verbalize them - they just adjust their behavior to avoid things or people that they don't like. The resulting culture can get very passive aggressive. It also often has a very lopsided power dynamic, where people who are naturally comfortable being outspoken or voicing grievances end up setting the agenda, while other people who are quiet but may have better ideas or observations end up being left out.

You have a group of people who care deeply about performance, reliability, maintainability, and long-term health of the code base.

Having a large, single, closed-source codebase is a mistake. You should have a service-oriented architecture for the necessarily private stuff. Anything infrastructural should eventually be planned for release into the open-source ecosystem.

That's because maintenance is utterly necessary, but maintenance requires good people, and talented people will maintain OSS, because it benefits their reputations and usually involves improvements to infrastructure they need, but closed-source maintenance always ends up being a ball of work thrown onto people with the least clout, who are either not very good or pissed off.

That's how you solve the SRE/SWE conflict you talked about.

Either that or you take the hedge fund strategy: pay people so goddamn well (hedonic adaptation says that's in relative/growth terms, so 25% over market in the first year, and 25% growth each year) that they'll be happy to do whatever you ask of them. But for an average $120k developer that has you over $1M/year after 10 years, and most tech companies aren't willing to pay that.

You have a brilliant developer who is terrible at working with other people and doesn't particularly want to deal with them. In an open-allocation world, he will end up shunned; nobody will want to work with him. In a managed org, it's often possible for his manager to pick off a certain really difficult technical challenge, have him go off and find a solution, and then interface with the rest of the group via some technical API.

It's actually the norm for the best team size, in software, to be one. There are exceptions, but not many.

In an open-allocation world, either he finds a project where he can contribute on his own, or he asks for suggestions (from someone like this manager). The difference is that he gets to pick (although if he doesn't, he might have to be let go). He's not reliant on one company-assigned manager (who might abuse the power) to be his interface.

In an open-allocation world, nobody will want to work with him, which means that he won't be a tech lead for very long, and eventually he'll probably get frustrated and leave.

I see no problem with that outcome.

If he's not showing leadership, and no one follows him, that's what should happen. If it bugs him, he can change his attitude or quit.

How many managers, in a closed allocation system, are actually going to know that a tech lead is taking the best work? This requires people on the team going to the manager (behind the tech lead's back) and most people would be too afraid to do that, knowing what will happen if the manager names them to the tech lead.

You have a project where consistency is the whole benefit of the project. For example, you're doing a company-wide visual redesign to make the company's product offerings more consistent for users, or you're introducing a language styleguide, or you're defining standard APIs for communication between components. These efforts typically never succeed unless they have top-down support from a strong leader.

Ok, this one is a really good point. You're right that this is something that requires top-down delivery of vision. It's hard to imagine Steve Jobs running an open-allocation Apple. I think the benefits of open allocation in terms of what people are allowed to work on an experiment with are very strong. The fact is, though, that this can't be taken so far as to allow people to impose complexity on the design or the ecosystem as a whole. You probably need centralized authority and vision to keep, for example, a simple product design. I don't think that that should be an excuse to prevent people from organically forming and changing teams, though. It requires conservatism about what actually gets into the product, but not as much about how people work and what on.

The Dunbar's Number theory doesn't seem to hold as people thinks it does. Yes, organic groups become trust-sparse instead of trust-dense as they get bigger, and there may be reasons for the threshold to be around 150 in "organic groups" (i.e. those that come together without a direct purpose, such as an emerging tribe) but a corporation is not an organic group. Inorganic groups follow different rules entirely. They may fall into trust sparsity very quickly, or not at all despite scale. (Note: trust density doesn't mean everyone trusts everyone; it means that the prevailing attitude is that people trust each other to be basically valuable to the group. It's about the default setting of the "bozo bit".)

Open allocation takes work. The paradox is that it does actually require management (of a non-traditional form) but the management is exerted to protect the open allocation system (and, to some extent, to protect people from each other). You'll still have political issues in an open allocation environment. Management has to address them in a fair way without becoming extortionist or meddling as one gets when the conflict of interest between people management and project management is unaddressed.

Open allocation isn't a panacea. Open allocation has a million problems. So why do I advocate for it? Because closed allocation has all those million problems-- and a billion more that come from a corrupt, self-serving edifice ripe for abuse and that (except in an immediate, existential crisis where every decision must be made and executed fast) has no purpose.

You should think of closed allocation as like programming in assembly code instead of a higher-level language. If you actually need that extra 1% in execution speed over certain special cases, go ahead. Usually, you don't. This typically premature optimization of closed allocation will usually create incidental complexity that becomes permanent and corrodes your company.

You might argue that VC-istan is open allocation, but with extreme (and unacceptable) social inequality, bizarre income effects that can damage future jobs, and reputation-based extortions that make it, nonetheless, dystopian. It is a market culture, but a deeply manipulated one reminiscent of the blatnoy elite of the Soviets.

Reply on news.ycombinator.com