EP1: The COP Theorem for Success (my answer to McKinsey)

McKinsey article on measuring individual software developer productivity ignited many souls in the software engineering world. This is my perspective as a long-standing software architect.

If you haven’t heard yet about the McKinsey article “Yes, you can measure software developer productivity”, you must be living under a rock! In fact, it caused quite a stir in our industry. Experts have unanimously rebuked their arguments as flawed and potentially dangerous. Dave Farley did not mince his words by saying it’s simply non-sense. I can tell you my reaction was even more colorful! 😅

In this post, I will give my perspective of a software engineer and technical leader.

Why should we all reply to McKinsey?

The first step is considering why we should put some effort into replying to McKinsey article.

McKinsey audience is not software developers. It is managers and executives. McKinsey has a vested interest in selling its services to companies that are experiencing poor performance and high costs in software development.

Their article is extremely effective in catching the attention of struggling managers who have a poor understanding of engineering. Very often that’s exactly the reason why their companies are underperforming in the first place.

That said, it is in our interest to join the debate and show our insight and perspective. We want to reach those struggling managers and prevent them from doing some uninformed choice that will worsen their situation and have a negative impact on our companies and fellow engineers.

What is McKinsey proposing?

McKinsey argument is that software development productivity is undermeasured. It is a black box and it is not anymore acceptable.

Their solution to the problem is introducing higher visibility by the tracking the performance at system, team and (most notably) individual level through DORA metrics, SPACE metrics, and some of their proprietary metrics.

If you stick to their plan, you will be able to answer these questions:

• What are the impediments to the engineers working at their best level?
• How much does culture and organization affect their ability to produce their best work?
• How do we know if we’re using their time on activities that truly drive value?
• How can we know if we have all the software engineering talent we need?

If it sounds too good to be true then it probably is… 😝

Pilots fly planes

No metric will ever identify what is preventing engineers to work at their best level. Metrics need interpretation. Having more metrics than you have today is not going to make it easier for you to identify the source of poor performance.

Imagine being placed inside a commercial airplane cockpit. You have all the necessary information (metrics) and controls to fly the airplane. Will you be able to take off?

I think we can easily agree that unless you are a professional pilot, you will not be able to do anything at all. Actually, having anyone but a pro in control of the aircraft would put all passengers at risk.

The same concept applies to software development. If you are concerned there are impediments that are preventing engineers to show their full potential, there is high chance the engineers themselves have the answers you are looking for. If you don’t feel comfortable asking them, or simply don’t trust their opinion, you have bigger issues in your organization. Trust me I am an engineer! 😁

Engineers love metrics

High performing teams introduce best practices and metrics on their own. They are eager to monitor their performance and find opportunities for improvement. This is not an opinion.

For eight years Google has published the “State of DevOps report” outlining what are the practices that lead to successful software delivery and operational performance. The study involved over 30,000 professionals worldwide and the conclusion has been very clear.

The best predictors of performance are metrics that focus on system-level outcomes.

Software developers have one mission: delivery quality software timely. This why your best bet is to use the five measures of software delivery and operational (SDO) performance which are the DORA and reliability metrics.

Metrics that go to a lower level, such as the individual, foster local artificial optimizations that have a negative impact on the overall outcome.

I recall vividly a time where my team was struggling with the introduction of a new feature in a poorly documented legacy system. The manager (who is someone I regard very highly) showed me a report where developers were ranked by the number and size of commits. My answer was immediate. You will have my team triple the commits by end of week! That was enough for him to realize that we were simply desperate and just grasping at straws.

There was no metric or framework that would have sped up that job. All we needed was transparent communication and mutual support which takes us to the next important topic.

The COP theorem ©️

No it’s not a typo. This is a new theorem I just invented! 😂

Software developers and architects are familiar with the CAP theorem which highlights that in a distributed system you can achieve only two qualities out of consistency, availability and partition tolerance.

My COP theorem is very different and it states that

you need Culture, Organization, and People to succeed in your business.

If you perform poorly in one of these items, you are doomed to mediocrity. 💥

Let’s reason about it.

Having a positive culture and an effective organization structure is not enough for success. You need the right people (talent) to achieve your goals. If we go back to the commercial airplane example, you need the pilots to fly a plane. There is no way around it.

If you manage to employ the right talent but have a toxic culture, you are doomed to failure as well, no matter how you structure your organization. This is easier to understand if you think about start-ups because we can discount the effect of the organization. You could have a well-rounded team with incredible individuals that do not gel well together. This is typical when you slot two rockstars developers next to each other without the presence of a charismatic leader that can direct their focus on producing value rather than cockfighting on who has the better ideas.

Finally, culture and people can get you definitely further. Having talented professionals that work in empowered and motivated teams will surely end up in high quality deliverables being produced timely. However, you still need a good organization structure to make sure that business vision and implementation are perfectly aligned (promotional message: this is what a software architect does 😘). Otherwise, there is the risk that what is being produced is in no way beneficial to the overall organization’s goals.

What about Design and Collaboration?

McKinsey believes that to identify specific areas for improvement you can leverage their proprietary inner / outer loop time spent metric. I am going to quote them verbatim because I don’t even feel like paraphrasing what they are saying.

To identify specific areas for improvement, it’s helpful to think of the activities involved in software development as being arranged in two loops. An inner loop comprises activities directly related to creating the product: coding, building, and unit testing. An outer loop comprises other tasks developers must do to push their code to production: integration, integration testing, releasing, and deployment. From both a productivity and personal-experience standpoint, maximizing the amount of time developers spend in the inner loop is desirable

This statement is wrong in so many ways that we could write an entire book on it. A lot has been said already, so I will focus on one aspect which is directly related to my position of technical leader.

We have already stated that the main goal of the entire software development process is to deliver quality software timely. Quality and time are very important elements of this equation because we want to beat our competition in the open market. But, how do we improve the quality of our software while reducing the delivery timelines?

We need to code smarter; not harder.

We code smarter by fostering collaborative design, which is the exact opposite of what McKinsey is advocating.

Design equates to thinking and problem solving. That is the primary function of a software developer or engineer. The act of coding is just the final step in the process where you concretize your thoughts.

Since we work in a team, we prefer to design collaboratively whenever necessary. That said, we dislike useless or mundane meetings, but we are actually thrilled by the idea of modelling and brainstorming together. This is a necessary function to make sure we implement the business vision in the most efficient way.

Imagine we need to implement a new account and user management system that supports multiple authentication and authorization schemes. Based on McKinsey suggestion, we need to get down to code as soon as possible. No wasting time! That is an anti-pattern that will inevitably lead to a “Big Ball of Mud”.

It’s way better to invest one month in defining a solution that is lean and maintainable, than rushing to implementation and end up with a monster that we will regret for many years to come.

Conclusion

If you have performance issues in your software development practice, start by focusing on the COP theorem. Do you have the right culture, organizational structure, and talent in place? If not, there’s no metric that can help you.

Once you get the COP parameters in order, we can start working on metrics. The SDO performance metrics (DORA + Reliability) are your best bet. Let the engineers guide you. Trust your technical leaders. They know what they are doing. As a business owner or decision maker be transparent and define a clear vision and strategy for the company. The rest will fall into place.

Other media

If you liked the article, you could also browse my YouTube channel where I offer similar content https://youtube.com/@MarcoLenzo

Last week we talked about APIs and Events.