Welcome to the ‘PRty’: The All-Inclusive Pull Request

Private parties always sound like something you wish you were invited to, super interesting and exclusive. And in fact, this allure of exclusivity is often used as a business tactic as well. With secretive, VIP launch parties and early-access deployment ploys, brands try to leverage the power of “FOMO” to create a buzz around their product or service.

Interestingly enough, when looking inside development team workflows you’ll find similar patterns in the form of  PR (pull request) workflows, primarily reserved for Dev to Dev interactions. The prevalence of this type of exclusive process in engineering organizations has been driven by the git workflow, which enables coders to work in a flow that is familiar and contextual to them.

But unlike marketing ploys and brand-building, taking this approach in an engineering context has its drawbacks. By not getting other stakeholders involved, engineering teams may actually find themselves suffering from more hectic feedback loops, constant interruptions, and a slower decision-making process overall.

The benefits of a more inclusive workflow are potentially significant, with a recent study quantifying ”the difference in employee performance between nondiverse and diverse organizations as high as 12%. Furthermore, according to the study, “multidisciplinary teams — which include business roles, not just IT — leverage their diversity of expertise and experience to enable faster decision making.”

So, if a multidisciplinary team performs better as a whole from a business delivery perspective, perhaps these same productivity principles derived from multidisciplinary structures could yield a better outcome for less-inclusive development processes?

A Peek Inside the Exclusive PRty

But before we invite other stakeholders to this party, let’s first understand what it is that’s working for the developers involved.

The code review format is pretty standard across engineering organizations and is basically comprised of this typical Pull Request Workflow created with the onset of git workflows.

A common workflow usually looks like this:

1. 1. Write the code
   2. Open a PR
   3. Perform a code review
   4. Resolve the open issues or comments
   5. Validate the changes
   6. Merge the PR

There are several key benefits from current code review practices:

1. Micro-Reviews: Typically a reviewer only checks the last changes of code that have been made, so when utilizing best practices for opening a PR, the effort doesn’t usually involve multi-context lines of code to review as the target is to break the tasks into smaller tasks via smaller pull-requests. This modus operandi is intended to cost the reviewer a minimal amount of time, to not become a burdensome or major event during a day of work. We can see some suggestions for best practices from companies like Palantir, on its blog that: “If a code review makes substantive changes to more than ~5 files, or took longer than 1–2 days to write, or would take more than 20 minutes to review, consider splitting it into multiple self-contained CRs.”
2. Contextual Comments: Whenever you find room for improvement to specific pieces of the code (and there is always room for improvement), you are able to add your comments directly to the relevant lines of code, providing the code owner full context for where the improvement should be made. Referencing a specific line of code leaves no room for ambiguity.
3. Actionable Suggestions: As a reviewer, you can simply write code within your comments in order to be as clear as possible about the desired outcome. This enables the code owner to actually learn from your comments and choose whether to implement them fully, partially, or implement the change in a similar manner. If there is a conflict with the suggestion, it is easy to discuss it within this specific context.
4. Intuitive Workflow: There is a shared understanding between code owners and code reviewers about what is expected from one another. This understanding facilitates working asynchronously without creating any bottlenecks in the development process. What if design and product reviews worked the same way as code reviews?

It’s clear that the PR workflow is highly effective for Dev to Dev reviews. But what happens when we need to add additional stakeholders to the process — how does this process carry over? This isn’t just a theoretical question, but a very practical one. This is essentially the challenge that organizations face when moving outside the boundaries of the code itself and into the realm of product and feature design.

When it comes to designing new features or products, engineering is only one piece of the puzzle — there are other equally important functions in the process, such as designers, PMs, and QA — each with a different working process and mental model.

You could even say they speak different languages altogether, so we can forget about the benefits of code suggestions or contextual comments. When it comes to development processes, these additional stakeholders will have many issues of their own to raise of no less importance than code review, and some equally urgent. And some of these comments may not even be related to the latest version, not to mention a specific PR.

This ambiguity and lack of context, in turn, creates a hectic feedback loop, that often consists of:

1. The meeting invitation is equivalent of a “shoulder tap”, inviting you to an unplanned Zoom session to understand why something isn’t implemented as defined or as requested.
2. Multiple new tickets opened on your beloved task management tool.
3. A shared document listing multiple issues along with some screenshots. And just to make sure it’s as enjoyable as possible for everyone involved — it includes bugs and comments from a super-outdated version of the product.
4. The expectation that this document will trigger one of your favorites — ANOTHER MEETING!

The impact that the hectic feedback loop has on coders cannot be overstated:

1. Stress and frustration due to out-of-context interruptions.

👁 Image

The table above taken from “The Cost of Interrupted Work: More Speed and Stress” (2008, Mark, Gudwith & Klocke), demonstrates how mental workload, stress, frustration all significantly increase with interruptions, particularly when they are perceived to be out of context.

2. Costly context switches between multiple features in development

👁 Image

Data from “The Daily Life of Software Engineers during the COVID-19 Pandemic” (2021, Russo, Hanel, Altnickel, & van Berkel) clearly demonstrates that the less context switches — whether email, interruptions, or even breaks (often imagined to foster greater productivity), the less coding is achieved.

3. More meetings just to align all stakeholders to be on the same page.

Harvard Business Review also recently published an article Collaboration Overload Is Sinking Productivity, that focuses on the impact that meetings have on overall productivity.

“These interactions resulted in a 30% decrease in focus time (defined as two-plus hours per day of uninterrupted time that can be dedicated to a task or project).”

If any of this sounds familiar to you, you are not alone. The friction between coders and other stakeholders is an age-old pain point that exists in virtually every engineering organization.

Thankfully, I’m here to try and cheer you up! What’s coming next might help you eliminate this feedback loop once and for all.

The All-Inclusive PRty!

For much of my career as an engineering manager, I have been focusing on eliminating this friction. When considering all of the above, it seems fairly obvious to me that we should take the same core benefits inherent in code reviews and the PR workflow, and apply them to all of the relevant stakeholders. Call it a “PRty.” This would mean that:

1. Any piece of feedback by any stakeholder is contextual by design
2. All discussions happen asynchronously and are documented
3. Actionable issues will be provided with PR granularity and within the relevant workflow

And while this seems fairly straightforward, this begs the question: WHY doesn’t this happen in real life?

The answer lies in the way code is made accessible to other stakeholders.

1. Code reviews today for the most part happen inside the organizational git provider, where other stakeholders don’t really operate, or oftentimes don’t even have an account to be able to take a meaningful part in the review.
2. Other stakeholders rely on the deployment environment provided to them by developers to experience the latest version. If you are using any one of these:
   1. Feature flags in production
   2. A single staging environment
   3. A limited number of Dev environments

This “developer mindset” just might be the root cause of some of the friction and breakdown in communication, that leads to the disruptive and hectic feedback loops with other stakeholders, who are highly reliant on the preview you provide them with.

What tools do they have to share their feedback? People will use the tools that they have at their disposal, and the process they are familiar with to get the job done. So if Zoom and Jira are the tools that they are provided with to provide feedback, it only makes sense to hop on a Zoom call or open multiple tickets to share their feedback.

Can We Utilize Technology to Impact the Culture?

So, in order to really shift the existing paradigm, we need to try and bring all of the multidisciplinary functions into the same development workflow.  One approach I’ve been exploring that has been highly effective in fostering more collaborative processes is utilizing ephemeral and shareable environments. These environments can make this party all-inclusive while still maintaining the natural workflow for all the relevant and high-value stakeholders in the process.

There are many examples of ephemeral environments that already work for other use cases to solve similar challenges. A few of those are: automatically running your E2E, integration, or UAT tests upon a specific change as a trigger.  Ephemeral environments are transient staging-like environments that can be created automatically, an infinite amount of times. In the context of our multidisciplinary stakeholders, this means that they would essentially have a preview that is automatically generated for any PR or branch in a joint project.

Taking such an approach to the product development workflow has multiple benefits:

1. Accessibility to the project and its progress by any stakeholder. Since the ephemeral environment has a unique URL it is inherently shareable by design, making it possible for anyone to click and experience the progress whenever they want or are asked to.
2. Contextual issue-reporting. Coupling issue-reporting into such an environment provides greater context for the code owners, along with the ability to easily reproduce issues with an up and running reproduction environment.
3. Orchestration and management of these environments will become a version control time machine in the long term. If any one of the environments is ready-to-use at any given time, it becomes easy to traverse between them and compare between older versions. Think of a shorter root cause analysis as the benefit, just without the heavy lifting of building and deploying previous versions from your SCM.

Collaboration Between Stakeholders Powered by Ephemeral Environments

Once we make collaborative ephemeral environments the new normal in engineering organizations, this collaborative model can evolve even further to turbocharge and streamline business delivery. This can be achieved by adding a layer of actionable suggestions and intuitive workflows to micro-reviews and contextual comments.

For example, assuming we have an ephemeral environment generated per PR, it will then be fairly simple to connect it with a  tool for issue reporting, while integrating the tool’s output to the actual PR in the organizational SCM.

Let’s examine  how this maps to each of these benefits:

1. Actionable suggestions: While reporting an issue within the ephemeral environment one  can also add more abilities such as console logs, network calls, and even CSS changes(which some designers and PMs like to do via the developer tools in their browser).
2. Intuitive workflow: Sending these issues directly to the SCM embeds seamlessly into the git workflow, and provides the same output as code reviews, maintaining a familiar workflow.

Sufficient data has come to light over the years that demonstrate that more collaborative and multidisciplinary working cultures — whether its disciplines such as DevOps, Fullstack, squads, and guilds, or even just plain old diversity and inclusion, have clear cut business benefits. Engineering practices have been lagging behind, and remain a fairly exclusive process to other stakeholders in the organization. I believe it’s time we upgrade these outdated processes for development teams as well.

By refreshing this paradigm, we can derive direct business and productivity benefits, all while creating more inclusive and enjoyable engineering processes. So let’s start a revolution through a more inclusive PRty!