Turn your small team of engineers into a productivity powerhouse using Owned Pull Requests

This post audience: CTOs, Tech leads, Sr software engineers.

A team member creates a pull request that you have to review.?

Then you write some comments and send it back to be fixed. The next morning, it is sent back again for review.?

This time you hesitate to actually pull the branch locally and test the code because you are working on a feature that requires a particular migration on your local database that makes it incompatible with `main` until you finish up your task.?

Instead, you either let the pull request sit there, review it lightly or just approve it to avoid being too pushy on your teammate. Hopefully nothing too bad gets merged.

If you are not worn out, you focus on the PR review and provide a thorough, insightful reply and avoid approving it until it reaches the quality threshold you are happy with. This can result in the PR being stuck in review for several weeks.

During my work on startups throughout my 17 years of experience, I have noticed the thorough insightful reviews end up generating one of these three scenarios, each one of them uneasy to revert.

?- the reviewer is fed with PR reviews and lowers the quality of approvals

?- the reviewer keeps their standards but some PRs take a week or more to be merged.

?- the reviewer slowly becomes a bitter person (as incredible as it may sound, I've seen this happen several times)

There is one exception, when the reviewer continues doing a great work throughout time without degrading or changing in any way, I've seen this twice.

### I see there the ideal scenario to unleash a productivity machine that speeds up the release cycle by an order of magnitude

?- Without compromising code quality

?- Cutting off unnecessary cycles of review

?- Still providing insightful reviews so the PR creator keeps improving

But then, how do I do to:

?- Merge PRs in the same day they were submitted

?- Keep the quality standard up high

?- Provide feedback to the PR creator

The "Owned Pull Request" merge mechanism I use

First, define a project owner, the champion that will have the most accountability on the project, maybe that's you.

The project owner will proceed and pull the branch, and use the code as ground-work to?

?- finish up the feature,

?- fix what's wrong,

?- complete what's missing

?- add comments when they're needed

?- properly name variables, functions and classes

?- make the code look unified, in style and marvelous as the rest of it.

At the end of that, notify the creator what you have changed, and have them review your code instead. I'd invite them to let me know if they see anything wrong with my code changes just in case.

The first week working this way may be counter intuitive as it pulls you off from the features you are working on. But after you pick up the peace of it, the sprint turns into a swarm of tasks you request the team to pre build for you to finish up. Only if you have extra free time, you grab a task from the backlog.

It does require the entire team to be aligned with a certain set of values, being the main one asking the question "Is this good for the project?".

This strategy allows me to release several new features a day. It is ideal when starting up a product from scratch when you have to build fast and release ASAP.

Many engineering teams do code reviews the way they do it, just because that's the way everybody does it.?

Ask yourself why do your team review the code the current way, then try the "Owned Pull Requests" method, you will not want to go back from it.?