How to Help Engineering Teams Avoid Action Bias and Apply the Pareto Principle to Achieve Maximum Productivity
By Boris Korenfeld, Global CTO and General Manager of Tech Practices, Sphere Partners
Since 2000, I’ve held a variety of roles with some of the world’s most renowned organizations, including HP Software, Gett Taxi, and Google. Throughout my career, I’ve contributed to the development of diverse tech across different domains, while leading high-scale B2B and B2C tech teams to success.
As a CTO, I’ve had the privilege of leading the technology vision for these organizations. This involved a range of tasks, such as developing roadmaps, selecting technology stacks, implementing methodologies, optimizing engineering productivity, designing architectures, ensuring system availability in production, and managing cloud and third-party budgets.
My passion for leadership within both large and close-knit, change management, and innovation has been a driving force behind my career. I’m dedicated to leveraging my expertise in these areas to make a positive impact on global businesses. In particular, I’ve learned how to utilize the Pareto Principle and avoid action bias to maximize productivity in my roles. By identifying the most critical tasks and taking action quickly, I lead teams to their most successful outcomes.
What is the Pareto Principle?
The Pareto Principle, also known as the 80/20 rule, is a concept that states that 80% of the outcomes are derived from 20% of the inputs. In software development, the Pareto Principle can help to achieve ambitious business objectives with existing resources, especially in situations where adding more resources is not an option and the timeline is tight.
Applying the Pareto Principle in software development requires identifying the right 20% of causes that will have the most significant impact. This can be challenging, particularly during highly stressful periods, where the focus is on delivering tangible results, such as fixing bugs or coding. This is often due to an “action bias” which is the tendency for middle management to want to accomplish tasks just to feel like progress is being made, rather than mapping the appropriate tasks and accomplishing those as a priority.
To overcome the action bias, it is essential to prioritize allocating time and resources to examine the big picture. As you and your senior team take the time to understand the broader context of your IT needs and identify the 20% of causes that will have the most significant impact, you are able to give your implementation team a proper direction. Thus, software developers can ensure they focus their efforts on the most critical needs and achieve their business goals within the given time.
I’ve also found it beneficial to apply the Pareto Principle when performing quality improvements. Software development teams can focus on fixing the most impactful bugs to improve the overall quality of their products. This powerful tool can help your teams achieve their business objectives and deliver high-quality products with limited resources and tight timelines.
Real-Life Examples Where the Pareto Principle Was Key
Scenario One – A CTO’s engineering team was struggling with a large number of bugs that were affecting a release.
We drew upon the Pareto Principle to help focus the software development team as they were facing quality issues close to the release date of a major version. In this scenario, the team was fixing bugs as they caused problems but weren’t taking a holistic look at the entirety of the bugs before fixing them. Knowing that it is likely that 80% of the impact on product quality comes from 20% of the bugs, we took a step back to determine which bugs should be our priority for fixing.
To determine which bugs to correct, we needed to identify the significant issues affecting the most essential flows of the product and make a plan to correct those before working on anything else. The engineering leader had to make what felt like a counterintuitive decision to pause bug fixing and allocate the team to run a bug hunt for a few days. By identifying the pivotal bugs that needed fixing, we didn’t waste time fixing what didn’t need to be fixed and focused on the bug fixes that generated the most productivity.
Stepping back and plotting out our bug fixes first allowed our team to meet the delivery timeline while also ensuring that the product’s quality met the required standards.
Scenario Two – An IT team needed to perform code refactoring to expedite the system, but couldn’t overhaul all of the code at once
One of my IT teams was struggling to determine which code changes were needed to improve their time-to-market while using a fragmented spaghetti code. The developers knew code refactoring was needed, so they wanted to overhaul all of the code.
Here we identified that 80% of the code changes are made in 20% of the components and micro-services. So, by refactoring only 20% of the system, we made it simpler for 80% of the future code changes to be accomplished. We were able to improve our time-to-market and expedite all future refactoring as well.
Scenario Three – A system’s technology was no longer appropriate for its growing business and needed improvements or an overhaul
The Pareto Principle was also useful in a situation where a system’s technology was no longer appropriate for its growing business needs. In this scenario, the system was developed in Ruby for MVP purposes but needed to handle a massive load of millions of users per minute and it couldn’t handle the load. We knew that changing the technology completely would require a significant amount of effort and time.
We analyzed the system’s traffic, CPU consumption, memory consumption, and other factors, and identified the critical 20% of the system components that needed to be refactored to handle the massive load.
Focusing on the critical 20% of the system’s components, my team quickly impacted the system’s performance without having to refactor the entire system. This approach helped the system handle the massive load and meet the growing business needs.
Leading the Team
As a senior tech leader, your leadership should guide your managers and offer support to map the big picture. One of your roles is to help managers overcome different human- and work-based biases that can get in the way of problem-solving technical issues.
By offering support and encouragement to allocate resources and time for mapping the big picture, your senior leadership team will have the correct approach when navigating technical crises. From this perspective, the Pareto Principle can be applied to challenge your team’s decisions and improve their problem-solving tactics. Encourage your team to take the position of an observer to analyze the situation. This will help your team to identify the 20% of causes that are driving 80% of the outcomes.
As a CTO or other technical leader, encourage your team to make decisions without action bias or unnecessary urgency, but to make them based on sound reasoning and data. By asking questions and critically evaluating their decisions, your team will ensure they are prioritizing their efforts and resources in the most effective way possible. This approach can help them to avoid wasting time on activities that do not have a significant impact on their goals.
Commit to Learn and Expand Your Team’s Abilities
To stay ahead, a software engineering team must commit to learning. This involves prioritizing coaching and mentoring for all, seeking advice from field experts, and constantly updating skills to enhance problem-solving and process efficiency.
As the head of the department, it is essential that you model this commitment to learning and provide resources and opportunities for coaching and mentoring to all members of your department. By fostering a culture of continuous learning and growth, you can elevate the entire team’s skills and capabilities and ultimately deliver better results for your clients and customers.
Chat with Me
To connect and discuss ways to improve your IT department’s process or simply share experiences, drop me a line here.
