I think the most important part of these processes is to document what’s being proposed and have a period for comments / inputs. I also think it’s ok for a monarchy as opposed to democracy ruling what gets approved, assuming merit based is not an option.

In general merits (rationality?) can bubble up if it’s framed in correct way for upper levels (eg. risk, profit, time horizon), and can then sway the position.

But yes on average what’s decide at upper levels is gospel. But that’s how corporations function, and that’s ok.

    I also think it’s ok for a monarchy as opposed to 
    democracy ruling what gets approved, assuming merit 
    based is not an option.

    In general merits (rationality?) can bubble up if 
    it’s framed in correct way for upper levels

That's the intended purpose and origination of these systems. In a traditional hardware firm, marketing is constantly coming up with ideas but you can't constantly change hardware without delaying the project. So you come up with an engineering change request system. This forces marketing to go through a bit of bureaucratic pain every time they want to add something to the project. The committee acts as a gatekeeper but mostly, that little bit of extra work makes marketing self-select the more important ideas to go through the process.

Yep. Things like architectural review boards, RFC processes, corporate-wide approvals, etc are more about politics than anything else.

Often - not always, but often - the people seeking to sit on these committees are the least likely to be able to actually build software. It is a function of these kinds of boards that will invariably draw those who aren’t so great at coding or architecture.

A bit like being a film critic or book reviewer.

No collaboration process will remove people from the system. You should never expect it to, if you have problems with social power, that's a culture issue which isn't something you can control directly. You can discuss culture issues as a group and nudge toward changes. Process won't define culture - it might only nudge it, but it's very easy for established culture, especially that on the side of social power, to completely ignore the influences intended by process.

What I read from Squares description in the article is a lot of power uncertainty, which is sadly all too common in the software industry. What comes through repeatedly in the problem description is any uncertainty defaulting to no communication. This problem won't be local to the RFC process, and ideally should be tackled more broadly while also looking to improve it in processes. Communication needs to be rewarded even if the technical content is inaccurate - more people need to speak up more, and with less concern, and receivers need to approach the commentary with a positive attitude to facilitate both not feeling pressure and to encourage ongoing communication. The approvers list is for example doing this, though for a privileged few. What will likely come to light later is that the approvers portion of the process is causing an asymmetry of inclusion, further feeding a lack of communication from other parts of the teams.

An immediate concrete thing I would suggest that builds atop the existing described structure is to invite rotations for folks to join the "council" and review processes regularly but temporarily. This will increase inclusion and dilute exclusivity and prestige. Explicitly open space for participation and solicit input from visiting members, and again it is important to reward communication even if it did not have the desired content.

In my experience processes like these rarely work out as intended and usually add layers of bureaucracy for marginal benefit. It’s usually senior engineers or middle managers looking for “org wide impact” so they can get promoted.

I find those prejudgement political games damaging as well to the point that I'm fantasizing about absurd ideas like anonymous version of slack/hn like chat where messages don't have identities to push it slightly towards merit based conversations. Upvote on messages/threads, not user accounts etc. I don't mean anonymous usernames, I mean no identity at all or at most random identities per message, sticky on reply chain (to know the original author answered your question at most).

I worked at one company where (at least within our team of about 40) our process was legitimately good. There was a genuine back and forth discussion and good ideas tended to float to the top. Then we got acquired and things steadily changed. Slowly more and more decisions were made because some high level engineer or manager just wanted it that way. Of course, terrible ideas floated to the top and it lead to disastrous decisions.

It is possible for the system to work, but it’s a fragile equilibrium and easily destroyed.

Not sure if you have read the post fully, but they seemed to have created this architecture review meeting precisely to overcome the problems you are talking about. The orgranization wide meeting is a way to make sure everyone sees the RFC, while the architecture meeting is an in-depth review with a small group of relevant people.

Many people would agree the latter is needed in an organization beyond a certain scale, but I think the former is extremely important and often over looked. It provides a channel for people to be aware of what's happening across teams and build organizational context. It's also a forum for people to express themselves on anything they might have an opinion on and help establish a sort of the zeitgeist for the group. I've seen the alternative where you work within tight silos disconnected from the rest of the org, and it gets pretty dreary.

> In reality, it was just a test of who had the most political pull.

Every society works that way. When a group has to accept a decision, the most powerful person in the group decides.

I don't understand why any educated person today would think meritocracy is a good thing. A child looking at Wikipedia for 10 minutes could see all the flaws in it, yet it keeps being touted as some idealized model of social contract. In reality it keeps white straight rich men in charge.

You described my 2018-era experience in Uber’s infra org

> egalitarian meritocracy

Oxymoron.

Amen. Really silly things happen too, like you go through all this process and then months later some hotshot asks “wait, why are we doing this?” when launch is imminent.

Like we all agreed this was worth doing all along, right up to this very moment, and now we’re not sure all of a sudden. All the approvals, all the documents written and decisions we went through were apparently not compelling to this person. We could have had this discussion and perhaps killed the idea in the crib, now we’re having this discussion about something we’re about to launch.

In other words the processes are a fig leaf, which as you say is fine, but then it doesn’t even do the job of the leaf.

Full democratization/decentralization of engineering decisions is how you get into a quagmire of technical debt that can eventually kill your engineering teams. Some decisions need to be made by a group that is accountable overall to the health of the technical implementation. Like you can't be letting people use 5 different message bus solutions and expect your devops/support people to manage all of them effectively. Someone has to maintain sanity.

Yes we should rewrite it in language Y if everyone on the team is comfortable with the language, it provides nonfunctional benefits, and has potential to drive business value.

It’s just about acknowledging the conditions that would make an idea a good one. All ideas are good in a specific context. Instead of assuming everyone’s aware of the current context, state the ideal context for an idea.

> What if someone proposes "we should rewrite X in Y language,"

Yes, if 50% of our development team is proficient in Y, X is a bottleneck or EOL, rewrite will solve significant problems.

> we should use Z database instead.

Yes, if Z is widely used in our stack, Z will realize advantages that cannot be achieved with the current database, Z is required to solve upcoming problems.

That's how I take it, at least: You shouldn't say "No," you should say "this is why not."

The "no" is bc challengeable reasons, which are useful to be explicit about

"This would take resources away from delivering X and limit devs ability to collaborate, so we need a way to motivate the budget precedence / growth and a way to afford 50% + 6mo per dev productivity hit around retraining"

"Database x is a VC co toy that risks dying, acquisition by Oracle, and losing customer data when we do not have time for self-inflicted nonsense. We need ways to mitigate the risk such as $10M in NIH DB dev budget in case the likely case happens. We already spent our innovation budget for X, so need more to motivate doing it again on Y."

Less than gate keeping, this is a great way to help mature early/mid career devs / job hoppers who haven't had the chance to live with many self-inflicted senior-level mistakes yet

The above comment is a good example of non constructive ways to say no.

Anybody could reject any RFC with the reasons you gave (especially with the vague “bunch of other issues” catch all).

So I’d say, yes, you can say no, if there’s specific, written down, largely agreed upon principles or goals. The thing is, when a no is in reference to specific principles and goals, it’s no longer a no. It’s a “yes if it fits with XYZ. Can you explain how this works because I can’t see it.”

If it’s a no in reference to vague reasons, it’s just gate-keeping. I suppose I can say yes to gate keeping if you can find a way to be encouraging to the RFC author and value the efforts and thinking that went into it. Otherwise gate keeping breeds frustrated complacency.

I get your point, and they do address this later on in the piece kind of. It sounds like it's perfectly valid to say no, especially after reviewing the document and their architectural meeting where they discuss it more in depth. But they're also not trying to actively encourage saying no in the document, instead encouraging responses that points to how to get to a solid idea.

So saying "no" isn't forbidden, but it isn't the default either. At least that's my interpretation.

I had the same reaction but thinking more I’m actually kind of surprised by the elegance of “yes/not yet.”

One of the best questions you can ask someone (including yourself) when in disagreement is “what new data/fact/different condition would convince you of my position?” The “not yet” framing kind of sneaks that question in via just two words! “Not yet” implies you must define the criteria by which it turns to a yes.

Yeah. Not everyone who thinks they have a good idea has one, and the way this is structured it's very, very time-consuming to defeat a legitimately bad proposal. It feels a lot like when a conspiracy theorist says "Bildenberg cabal is made of hollow earth lizard people" and your only retorts are "yes" or "I'm not yet convinced".

Its like an Uber rating of < 5 means bad. A rating of "Yes If xxx" means "No"

Yes, if you use the current language rather than rewriting.

Yes, if you use our current database rather than a new one.