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.
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:
As a Code Author Needing Feedback, an Inward Mindset May Invite Us to:
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.
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.
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.
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.
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.
Sign up for the latest insights & ideas on how to shift mindsets to drive growth.
Diversity, equity, and inclusion training to foster belonging at work is no longer a nice-to-have fo
Often, DEI training programs fail because they prioritize directing employee behaviors instead of ad
We explore how the bell curve approach to employee performance management is limiting—and what org