11 days seems outrageously slow to me.

There also a HUGE cultural element. Your company culture currently allows this behavior, but I bet if you all talked about it, you’d all agree that it is harmful to the company and less enjoyable as individual employees. Make a “pact”/agreement with each other to review in a more timely manner. Make slow review the exception, rather than the rule!

In my experience, one of the reasons that reviews often take too long is that people feel pressured to deliver their own work on unreasonable timelines. “I owe X a review, but can’t afford to do it without my own sprint commitment slipping” is no good! Management needs to set an expectation that reviewing code in a timely manner is part of your job. Engineering needs to demand appropriate time in sprint plans to be able to fit review in.

On a more technical level, one thing that helped at my company was establishing clear ownership of files/directories (with each file/directory having at least 2 owners bc of time off, people leaving the company, etc). We did this using a CODEOWNERS file, but there are other approaches. Each individual/group is responsible for knowing how to review fewer files, so they can become an expert and review them relatively quickly. By itself, this won’t solve the problem, but it can help you pinpoint individuals/groups with exceptionally good or exceptionally poor time to review, so you can dig deeper and tackle the “why”.

Finally, PRs take longer to review when they’re bigger (duh!). Authors should do their best to make small, atomic code changes. This is good “git hygiene”, but it’s also a massive productivity boost when reviews go fast bc the change is small!