Date: 13 Oct 2024
“It will become inefficient,” said the 10x developer. Having worked in the IT industry for quite some time, I’ve heard this statement frequently. In the past, I also emphasized the importance of following a defined approach, and deeply invested in creating perfect systems. My obsession with perfection sometimes blinded me to the actual value being delivered. Fast forward to today, after reading numerous books and articles on software development and understanding the business impact, I feel it’s the right time to write about how engineers think when solving problems—and how those on the business side should interpret it.
What distinguishes a great engineer is their attention to detail and ability to see things at a granular level. However, this can sometimes prevent them from seeing the broader impact of their work. From an engineer’s perspective, it makes perfect sense to investigate why 1% of API calls take longer than two minutes. After all, this is their way of showcasing their skill and proving their worth. The fact that a business person might argue that these API calls serve only 10 customers contributing 0.01% to revenue doesn't have to make sense to them.
For example, if someone can’t find a particular TV show on a streaming platform, a typical person might just give up. An engineer, on the other hand, might get frustrated and set up a home server with network storage to store all their TV shows, making them accessible on any device. In their eyes, it makes sense to apply their skills to solve even the smallest of problems.
To understand an engineer’s thought process, it’s essential to recognize the journey they undergo to land an engineering role. Their KPIs are heavily focused on grinding down problems and solving them. For a software engineer, this means understanding the architecture of computers, the layers of technology built upon them, the various ways data is stored, and the techniques used to manipulate that data. This technical rigor explains why they often use specific jargon in meetings—they are trained to rely on precise terminology and facts.
There’s a book by Robert C. Martin titled The Clean Coder, which, while intended as a guide for engineers to become better professionals, offers non-techies a window into how engineers think. Engineers approach problem-solving systematically, breaking down complex challenges into smaller, manageable parts. They focus on understanding the root cause, and carefully analyzing each component before progressing. Precision and consistency are paramount, and they often test different solutions to ensure the most reliable outcome. This methodical approach is paired with a strong sense of responsibility, ensuring their work meets high standards. For non-tech individuals, understanding this mindset highlights the importance of clear communication, thoughtful planning, and a commitment to long-term, sustainable solutions—values that apply in any field.
To effectively filter out low-level details and align engineers with business goals, non-developers should focus on fostering open communication and collaboration. By engaging engineers in discussions about the broader impact of their work, business professionals can help them see how their technical solutions fit into larger organizational objectives. Encouraging engineers to articulate their problem-solving processes in simple terms can demystify technical jargon and make it more relatable.
“Clean Coder” by Robert C Martin
“Radical Candor” by Kim Scott