How Taking the Time to See Others Can Actually Cut Down Overall Cycle Time

A few months ago at WP Engine, a director of engineering and internal Arbinger facilitator sat down in a conference room with one defined purpose: to see if they could generate meaningful and measurable business results that were a direct result of implementing Arbinger. After about 30 minutes of brainstorming the director’s eyes widened. He sat up in his seat and said, “Code reviews! We need to be doing code reviews with an outward mindset!” Here’s how these two leaders helped their team apply Arbinger principles to increase their efficiency and reduce their time to deliver software by over 2 days per project.

Code Reviews and an Inward Mindset

When authoring software, all computer code must first be reviewed by a peer before it can be merged into existing systems. Code reviews are critical to minimizing bugs. They also offer an opportunity for mentoring and learning between the code reviewer and code author. However, if approached with an inward mindset – a focus only on our own priorities and results – the code review process is prone to all sorts of problems, inefficiencies, conflict, delay, and financial business costs. To properly review code, the code author will seek out another engineer with expertise to provide feedback and corrections. Interestingly, all engineers are sometimes code authors and reviewers. You might think that this shared experience would automatically invite effective collaborations. However, if an inward mindset is adopted, it can invite us to see the other person as a vehicle, obstacle, or irrelevant to our own needs, goals, and challenges. And it’s this way of seeing the other person that leads to a variety of problems. As a Code Reviewer Being Asked to Provide Feedback, an Inward Mindset May Invite Us to:

1. See their request for help as nothing but interruptive to our own work.
2. Wait until the last minute to submit feedback thus not allowing the code author enough time to complete their work and meet their deadlines.
3. Not invest in understanding the desired outcome of the code leading to feedback that isn’t beneficial.
4. Provide feedback that isn’t helpful to the author’s own growth or objectives.

As a Code Author Needing Feedback, an Inward Mindset May Invite Us to:

1. 1. Submit requests for help at the last minute without considering the reviewer’s needs.
   2. Avoid specific engineers who may hold the most expertise but who have not been helpful in the past.
   3. Not supply helpful context or supporting information that would help the reviewer with this task.
   4. Become defensive and dismissive when critical feedback is provided.

As the examples above demonstrate, an inward mindset invites us to focus on our own needs and objectives sometimes at the expense of our coworkers’ work and our shared results as code reviewer and author.

So How Does This Team Ensure They Approach Their Work with an Outward Mindset?

Starting in the Right Way

With the help of their internal facilitator, this team of engineers got together and simply discussed what it would look like to review code with both an inward mindset and an outward mindset. This simple discussion helped to highlight the ways they were each being helpful or not helpful to the overall mission and to each other.

1. 1. They asked each other:

1. 1. • What are the needs of others when we ask for our code to be reviewed?
      • What happens when we, code authors, only focus only on our own needs and results?
      • What are the needs of others when we review code?
      • What happens when we, code reviewers, only focus only on our own needs and results?

Meeting to Learn

The next thing they did was hold ‘Meet to Learns’ to better understand the experience of others within their team. They each took a turn learning about the personal experience of their team members in their roles as code author and code reviewer.

1. 1. They asked questions like:

1. 1. • When you need your code reviewed, what are your hopes, objectives, needs, and challenges?
      • When someone asks you to review code, how does that potentially affect your ability to do your work (both positively and negatively)?
      • How might I be able to discern or check-in to see if I have had a positive impact on your ability to do your work?

The Results – A New Outward Mindset Business Outcome

After going through these two exercises, the groups recognized a new business outcome: How can we consider each other’s needs and objectives while doing our work? By making this a key business outcome, the group could achieve a faster completion time for code projects and increase overall organizational productivity. This led to a series of questions, considerations, measurements, and systems to support working with an outward mindset that was more helpful…and produced far better results! Collectively this work allowed this team to shorten a typical code review by 2 days! The reduced time also helped solve or avoid problems, like conflict or burnout, inherent with more lengthy wait times.

1. 1. The engineers also found the new outward way of working to be personally and organizationally helpful. Here’s some of their feedback:

1. 1. • “We knew it was imperative to shorten the time to complete code reviews and now we understand the ways, both positivity and negatively, we impact this goal.”
      • “We began writing and submitting code in smaller chunks making it easier to be reviewed.”
      • “We wore earphones less and talked more.”
      • “We created a system to alert us of code review requests that were 3 days old so that nothing would fall through the cracks.”
      • “More people were getting up, walking around in groups, and working in pairs. We began to author and review code in real time.”
      • “We turned days of work in into minutes of work by helping the person side-by-side.”
      • “We began to notice casual collusions between people that led to learning and teaching.”
      • “We would erase the whiteboard in the morning and notice how long it took for it to fill up with diagrams and information; a sign that teaching and learning was happening.”
      • “Every two weeks we meet and discuss how successful we are at being helpful to each other.”

As a result of this new mindset and focus, this team has built a strong team dynamic through their helpfulness. Their relationships are stronger, personal growth has quickened, and their output is both more effective and more efficient.