People can become obsessed with becoming an expert in their field, actively avoiding learning from or in other disciplines. I think this is a mistake. While you can, need to, and should continue to learn in your specific domain, what is often overlooked are aspects of other disciplines. For example, human psychology. A lot can be learned and transferred into leading software engineering teams by studying other disciplines. And it does not need to take much. In most disciplines, there are three or four absolutely core concepts that have been very well documented. This means that if you read three or four books on the main concepts, you will gain a meaningful understanding.
A good place to start to find what to read, is simply to look up Nobel Prize laureates. Laureates have usually published their subject area in book form.
Next I outline some disciplines and books to read in some subject outside of software engineering.
Psychology
In psychology, it is very helpful to understand how humans think. I can highly recommend the book "Thinking, Fast and Slow" by Daniel Kahneman (2002 Nobel Memorial Prize in Economic Sciences). It separates thinking into two categories: System 1 and System 2. System 1 is your everyday, run of the mill thinking. Have you ever driven your car for 30 minutes and, once you stopped and got out, realized you can not remember most of the journey, and yet you arrived safely? That is System 1 thinking.
System 2, however, is different. If someone asks you to multiply 7 by 28 while you are cycling your bike, most people switch to System 2, some even fall off the bike. System 2 requires concentrated thought and attention.
Most of the time, software engineers operate in System 1. They are not being heavily taxed cognitively. They are working on problems they have seen before or mostly seen before. This is not to say the work is easy, but it is important to understand the cognitive load on people doing different tasks. If, however, engineers are working on a brand new problem (to them) and there are multiple layers of complexity in that problem, they are likely operating in System 2. It is unwise to disturb an engineer who is working in System 2, as you will disrupt their process, and it will take a significant amount of time for them to refocus and become productive again after your interruption.
Negotiation
Negotiation. Negotiation is a key skill in leadership. Everything can be seen as a negotiation, and of course excellent literature exists on this topic.
"Getting to Yes" by Roger Fisher is an outstanding book on negotiation. He was a professor of law at Harvard Law School and director of the Harvard Negotiation Project. He explains the process of successful negotiation and introduces what is known as a BATNA (Best Alternative to a Negotiated Agreement). Going into a tough negotiation without a BATNA is going to be an uphill struggle, not impossible, but having a BATNA vastly increases the negotiator’s chances of success.
A BATNA is not even a hard concept to grasp, and many people effectively have BATNAs and use them even if they are not familiar with the formal term. For example, if you are buying a house and negotiating on the price, you might already know that there are two other similar houses on the market that you would be willing to buy instead. Even if you have never heard the word “BATNA” you are still using the idea, you are comparing the current offer to your best alternative. If the seller refuses to come down to a reasonable price, you can simply walk away and pursue one of the other options.
That willingness to walk away strengthens your negotiating position. It prevents you from feeling pressured to accept a bad deal, and it signals, implicitly or explicitly, to the seller that you are not dependent on this one outcome. In other words, you are already applying BATNA thinking. The formal concept just gives people a clearer framework to understand what they are already doing intuitively and to use it more deliberately.
This concept can be applied to software engineering leadership in many, many ways. All to your benefit and the benefit of the companies goals and directions.
Investing
Investing is a wonderful topic to become familiar with. Not only can it help you improve your personal financial life, but it can also teach you to think like a large corporation or any publicly traded company. All publicly traded companies have shareholders, and much of what a company does is guided by, or done directly for, the benefit of those shareholders. This is not a difficult concept to understand, yet a surprising number of people are not well versed in the ins and outs of investing.
This gap is largely due to the fact that, in the past, the average person had far less access to the stock market. That has changed dramatically in recent years. As investing has become more accessible and more common, becoming well educated on the subject has become increasingly important.
With that in mind, Warren Buffett’s "Tap Dancing to Work" is an excellent place to start. The book offers insight not only into investing itself, but also into the mindset of one of the most successful investors in history, helping bridge the gap between understanding the market and thinking the way major companies and investors do.
If the way you think becomes more aligned with how a company thinks, it will indirectly benefit the way you lead software engineering teams as well. By understanding more about how and why the company sets its goals, you will be better equipped to guide your team in a direction that supports those broader financial objectives.
Systems
"Thinking in Systems" by the late Donella Meadows is an excellent piece of writing that describes systems, and how to think in them. The premise of the book is that the entire world is just a collection of many, many systems all interconnected to each other. The book provides a framework on how to understand these systems and provides some wonderful examples to clearly bring evidence to, and easily explain, this idea.
For example, imagine a software team struggling with slow code reviews. At first, it seems like a people problem, just “review faster.” But with systems thinking, the team looks at the whole system around reviews. They notice that developers often start new work while waiting for reviews, which creates even more code that eventually needs reviewing. That growing pile makes reviewers busier and slower, which makes developers start even more work. It is a reinforcing loop.
Once the team sees this as a system, the solution becomes obvious. Limit how many tasks can be “in progress” at once. Suddenly, reviews happen faster, queues shrink, and overall delivery becomes smoother. This is not because anyone tried harder, but because the system was changed.
Obviously, in software engineering, patterns and systems exist everywhere. They are inescapable. Getting to a deeper understanding of systems, system behavior, and why and how they work so well will without a doubt help you to lead software engineering teams. Once finished with this book, everything can look and become a system, and to an engineer this is a natural place to think and be.
Final Thoughts
I have not touched on science, healthcare, history, or many other disciplines, but each of these fields contains books and ideas that can make you a stronger software engineer and a more effective engineering leader. Wisdom is scattered across domains, and the more perspectives you explore, the more tools you gain for understanding people, systems, and the work we build together.
