Engineering Efficiency Tale

Today, you’re a CEO. As any CEO, your allegiance is stretched across three populations plus one aspiration: your investors, your customers, your employees and your vision. How you order this list determines the type of CEO you are. But that’s not the topic of today. No, today, you look at your books and you’re simply not sure. Nothing tangible, you simply get a general sense of inefficiency. For instance, two years ago, your Product & Engineering divisions were 30% cheaper but can you say this business is getting bangs for these bucks? You’re not sure. During the last meeting with your investors, someone mentioned how Elon Musk had halved Twitter staff with virtually no impact on its operations. So shouldn’t you challenge your CPO and your CTO to think “degrowth” and 10x efficiency? Or would that kill the current momentum, not stellar but decent, that pushes the business forward? You’re not sure. And recently, one of your friend, also CEO, raved about how Zuck’s mojo is still impeccable by the look of Thread’s launch. This Twitter-like app started internally at Meta in January 2023, under codename Project 92, to launch on July 5, 2023 as Threads and scored 100M subscriptions in less than 5 days. Isn’t that the definition of success? Or is it that launching an unmonetized app as a companion to one of the most successful social network on a concept that has been under discovery for years isn’t actually proving anything? Well. You’re not sure.

You decide to talk to your CTO. Her team is both the biggest with the highest salaries. If there is any place where efficiency matters, it’s with that division. You ask for a deep dive on how this resource is allocated and what are the latest indicators of performance. From all the data you’re flooded with during the session, you keep two data points: only 60% of your engineers are directly contributing to your strategic roadmap and revenue-generating projects; and the time spent to “keep the light on” (KTLO) is about 30% of the total bandwidth in Engineering. Each looks like glaring areas of inefficiencies. The combination of the two seems to you a huge opportunity. That your CTO doesn’t seem to align herself easily to this view persuades you further that “you’re onto something”. You have always steered things so that the highest number of engineers work directly on solving customer problems. You see that as the definition of being customer-centric organisationally. But in Engineering, this has never reached what you would consider satisfactory levels. You decide that now is the time to crack this tough nut. You end the session by asking for a plan to be presented to you next month to take the ratio of engineers focused on the customers to 90% and the KTLO level below 10%. You coined the term Customer-Centricity Coefficient (CCC) as a metric name for the 90% target. As you do, you can’t resist mentioning Twitter layoffs and Meta’s time to market as evidences that we can do better.

Let’s now jump into the body and soul of your CTO to understand why and how to get out of the pit.

Your CEO has just left the room. You look through the window, seeking some bearings with reality. That didn’t go down as expected, did it? You’ve always taken great pride in being data-driven, in large part for the transparency it enables. You’re now reminded that transparency is only desirable insofar as the receiver of the shared insight is properly equipped to interpret it. Otherwise, it’s not building trust, it’s shattering it.

Where to start? Surely, it should be with this Customer-Centricity Coefficient. It definitely has a ring to it, hasn’t it? Let’s look at its premise. The more engineers working on customer needs, the better. If only, you think. You figure you need a clear analogy to educate your boss. From an ethnocentric point of view, the real impact of technical progress has always been a redistribution of labour. But is its effect to increase the number of workers at the end of the chain? Let’s look at an example.

What we observe here really is that while the number of French stomachs nearly doubled over the period, the number of workers closest to their needs was divided by more than four. Could your CEO see the elephant in the room here? The elephant here is a tractor.

This tractor embodies the level of industrialisation of the work to be done. In Software Engineering, it takes the shape of a CI/CD tooling, of a maturity regarding observability, of a computational framework that abstracts away the inherent complexity of building solutions that are both resilient and scalable through assembling distributed systems, etc.

This tractor in our industry has been the constant elephant of every board room. Any concept of R&D investment as a percentage of revenue needs to understand the state of said tractor to be informed. Only it never does. It’s not that cost reductions, even headcount reductions don’t have their utility, it remains that’s the only strategic way to drive costs down is through investing in this tractor. Otherwise it’s a bit like cutting yourself a leg in hope that it will force you to figure a way to learn how to run faster on a single leg. Arbitrary cost cuts when the tractor isn’t up to scratch will in fact ensure this tractor never reaches the right level of usefulness. Given how poorly it is considered among powers that be, it’s the first thing that will get deprioritised.

Let’s remember one of the most profound quotes of our field:

Premature optimisation is the root of all evil. –Don Knuth

That’s exactly what these cuts are: premature optimisations. As a CPO once said, “engineering efficiency isn’t about typing faster on the keyboard”. And yet, in a world ruled by the Customer-Centric Coefficient, divesting your tractor is the way and typing faster becomes the only real efficiency lever at hand. Mind you, it can still be used. However, it will only be a matter of time before the team gets burnt out and attrition kicks in, starting from your top performers of course.

There is the rub: what is the right level of investment in this tractor? How do you balance it with the required Product Development investment? In other words, and assuming you should embrace such terminology, what is the optimal Customer-Centricity Coefficient? There is no equation that can solve this question for you. If the tractor is one central consideration, the level of KTLO is another and these are just the beginning of a long list of dimensions that need to come together to land you a balanced investment profile.

You reach out to your CEO’s EA to arrange for another catch-up at the earliest. You hope you have enough ammunition with your tractor revolution to make it the paradigm shift that will rebuild faith in your division. The EA comes back with a slot for tomorrow 9am. You accept. You look back through the window. You note the wind has changed direction. It triggers a thought. That there is a lot in your professional life that doesn’t depend on how good you are at what you do. Likewise there is a lot that you fight for which real impact you may never witness. Does that make of you one of the spiritual heirs of the cathedral builders from a millenary ago? What grand ideal keeps you going? Unfortunately, you’re already late for your next meeting.