There are other ways to solve the problems the author calls out. Reviews being slow can be largely solved with review SLAs/automation to ping reviewers. Code r

There are other ways to solve the problems the author calls out. Reviews being slow can be largely solved with review SLAs/automation to ping reviewers. Code review themselves can be quite fast if you know the code author well. Some people you can trust to make high quality changes and the review covers more high level/directional questions. Others are more junior/haven't built the trust yet and require more scrutiny. But having done a large number of reviews, it really doesn't take long to do even an in-depth review, if you're already familiar with the area of the code in question. The goal of a review is not to test the code for the code author, or to identify bugs for them... which is where things could really slow down. I used to do 10 or so reviews a day and it would take an hour or so to get through them, while still writing a lot of commentary on them, where applicable... not a rubber stamp. I know the author mentions not wanting there to be a lack of trust, but its pretty evident they'll realize the need to build trust first as they scale. There is also an aspect of the code author writing code to a higher standard when they know it will have to go through another set of eyes before being merged. The best people can set this standard for themselves regardless, but it's unlikely that you could run an org at scale on this premise without a drop in code quality. It is an interesting idea to try to run a company only hiring people that have the skills/attitude to be implicitly trusted. I think this approach is very feasible at a small scale if you can maintain very high hiring standards and are able to nab mostly 10x style engineers. These people will make mistakes, but will recognize them and self correct. Then you could just have people contributing under a guiding set of principles/standards, and "retroactive" review to ensure standards being followed. But almost certainly impossible to hire at this quality/bar at scale. Having said all that, I did work in a startup where in the early days certain people had write access and pushed directly. It mostly worked well at that small scale, but lots of technical debt developed in certain areas of the product that took years of effort to reverse/fix.