In 1986, computer software development pioneer Fred Brooks wrote a paper called “No Silver Bullet”. In this paper, he asserts, “there is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement…”

(Brooks, Frederick P. (1986). “No Silver Bullet—Essence and Accident in Software Engineering” (PDF). Proceedings of the IFIP Tenth World Computing Conference: 1069–1076.)

As an aside, if you have not read this paper, nor his book The Mythical Man-Month, I highly encourage it. The tech he talks about will seem dated, but if you look past that into his conversations on people management and software project management, you will discover it is all still amazingly relevant.

Anyways, back to Mr. Brooks’s original paper, and the concept the paper conveys. This is also still something amazingly relevant to today. A common occurrence that I witness happens when I’m in a group session with other leaders, and we are discussing the strategic challenges being faced by our organization. What I frequently see is two specific things, related to each other:

• People see strategic challenges, roadblocks, and issues through the lens of their projects and customers.

Which leads to:

• People see the ideas and solutions to address aforementioned challenges through the lens of their specific projects and skillsets.

One time, a really long time ago, I was working on a project that combined hardware and software. I was leading the software effort, and another engineer was leading the hardware effort. Partway through the project, we realized that a particular input bus on the device, which had 16 wires, had been designed and installed backwards. My solution, since I was the software lead, was that this could be easily fixed by us just changing something in the software, to read the wires in the other direction. The hardware lead, looking through her lens of hardware, decided that in fact we should redo the leads and swap the wires the other way around.

If we examine this situation more closely, and spend maybe 10 minutes discussing it, we could make an information, holistic decision. How much development effort would it take to change the code? How much engineering effort would it take the change the wires? Would changing that code, or changing those wires, impact anything else? But we did not do that; instead we just went head to head asserting our decision was the best one. Because, we were looking through our specific lenses of expertise.

When you are faced with a problem you are trying to solve, take a few moments. Maybe take a sip of coffee/soda/water, stare out the window a moment. Try to think beyond what you immediately know, and also listen to the others around you. This sounds so simple, but it can be truly hard to really listen to other people’s ideas. Even if we let them talk, we already have made up our minds and are just waiting for our turn to talk. Because there may be a way to solve the problem beyond your myopic lens.

(By the way, we ended up changing the wires, not the software.)