Skip to content

The Broken Finger Paradox of Engineering

A distraught man walks into his doctors office. “What is wrong with you today?” She asks.

“Oh, I am miserable” said the patient as he sat in the doctor’s exam room.

“Tell me what hurts” the doctor responded.

The patient gingerly touched his right kneecap. “Ouch!” He then reached up and touched his left elbow with a grimace of pain. Then the tip of his nose, right hip, and finally his left pinky toe, all the while showing great discomfort.

With a curt nod the doctor stood up and proclaimed, “I see what the problem is!”

The patient looked hopeful.

“We will get you some painkillers right after we put a splint on that broken finger!”


How much time and suffering do we endure because we often focus on the wrong aspect of a problem or issue?

The proverb tells us that there are more than one way to skin a cat. This is definitely a hard line to argue due to the fact that finding someone that has actually completed the task of skinning a cat is a nearly impossible task. Yet, over and over again people will ignore the true meaning behind this statement and only see one pathway to success.

Just like the patient with the broken finger, we are often blinded to looking at things from multiple viewpoints that can not only provide new and insightful ways to address problems, but that can also uncover the truth that is right there in front of us should we simply choose to pay a little more attention.

Photo by Edi Libedinsky on Unsplash

Therefore, it is up to the Engineering Managers to stay vigilant and work through these crises with patience and perspective. The hard part is that this is easier said than done. How does one evaluate what is a real issue versus one that is perceived? How do we tell a broken finger from a broken arm or leg?

Besides these questions, there is also the human element to deal with. People are not easy to manage. Everyone is different and unique and these differences can manifest in ways that are not easily anticipated. Besides the obvious Star Wars vs Star Trek battles among Engineers, how should the conflicts between introverts and extroverts be handled? The younger team-focused people against the older silo dwellers? What about the pair programming aficionados battling the refactor-everything VIM warrior?

On top of the people, there are schedules and timelines to manage. When will something be done? When can we sell it. Oh wait – we already sold it, now when can we tell them that they can have it?

Ok, with quite a few challenges identified, what methods can an Engineering Manager stock in their toolbox of tricks to keep a team moving forward as efficiently as possible?

The following is a collection of tips and ideas to do just that. Engineers need focus and perspective. Some Engineers can manage to step back enough to see the forest while some are transfixed on that single piece of bark on that lone tree a few inches in front of them. That is OK! It takes a mix of people and approaches to comprise a highly functioning and effective team. The concepts below are intended to help support and build these teammates to perform even better while alleviating many of the headaches for the Engineering Manager.


Photo by Robby McCullough on Unsplash

Promote Investigation of Problems From Different Angles

One of the hardest skills for any Engineer to master is to understand that there are always a million and one ways to solve a problem. There are always different angles to attack and no matter what there are no requirements so locked down that some form of compromise cannot be achieved.

This concept is very straightforward, yet many people struggle with it. To them, they are on a path and on this path they will stay. If there is a chasm across that path then there really is no way to continue. This mentality doesn’t work in Engineering.

A successful Engineer needs an ability to zoom out from a problem and view it from different angles and explore other options to get to the solution. Maybe a bridge can be built across the chasm. Maybe it can be climbed. Maybe there is a different path that can lead to a similar solution. It is even possible that a creative Engineer can review the requirements and suggest an alternative solution, thus putting themselves on an alternate path without the same roadblocks.


Tom Smykowski’s Jump To Conclusions mat from Office Space (1999)

Reduce Jumping to Conclusions

Tom Smykowski: “It’s a ‘Jump…. to Conclusions Mat’. You see, it is a mat that you put on the floor, and it has different CONCLUSIONS written on it that you could JUMP TO.

Michael Bolton: “That’s the worst idea I’ve ever heard in my life, Tom.

Samir: “Yes, this is horrible, this idea.

from Office Space

Yes, jumping to conclusions as a problem solving technique is a horrible idea – yet it happens. This practice leads to assumptions that can prove to be very negative for a project or team. Not understanding all of the facts and information can lead to easy button answers but long term failures.

A good manager will continue to ask questions until the facts and intent are fully understood and will also work to ensure that all people that they work with receive proper information in order to make informed decisions.

It is always good to remember that the higher the pressure, the easier it is to make these leaps of logic. The pressure to deliver results sets patterns in front of us that might not be real or accurate. Our brains want to simplify complex problems and this effect is magnified when the brain is under stress.


Photo by Alejandro Luengo on Unsplash

Eliminate Pointing

Many cultures around the world view finger pointing as a rude and obscene gesture. Eliminating the practice from an Engineering team is a worthwhile effort. While some of thewestern origins on this hand gesture are rooted in people not wanting someone to put a hex on them by merely pointing a finger, eliminating this practice can greatly help a team.

This action can be performed in one of two ways. First, physically pointing out issues or flaws is a bad habit for a team. Conflict can be a very good and healthy interaction for a team, but it is possible for it to cross a line. Having a stickler pointing an actual finger at a person or their code that doesn’t completely confirm to the rigid code standard may not be the best form of conflict for a team. Instead, allow both sides to face the issues together and air out the grievances while focusing on a solution as a group.

Another form of pointing comes in the form of assumptions. When an issue comes up quickly pointing at one area of the product can actually have an overall detrimental effect towards resolution. As an example, say a customer purchases a product and upon installation finds that the application settings are corrupted. This gets reported to the support team and an Engineer points at the database as the culprit so that group jumps into the problem and starts researching and digging.

Meanwhile, everyone else walks away from the issues and goes back to work. This is all fine and good if the problem is truly in the database, but what if the problem was that there is an error in an install script called by the main UI thread that is corrupting the data? Now triage has gone on for some time with the database group scratching their heads and no resolution in sight for the customer.

This is not a good scenario. Eliminating point, and assumptions, will always product a better (and usually faster) solution for a team while also building communication and general knowledge throughout the group.


Photo by Markus Spiske on Unsplash

Make Communications Open and Transparent

Many teams have silos in regards to people bunkering up in their offices or cubs, slinging code all day then going home. This is often referred to as a silo approach. When it comes time for another person to review this code or, heavan forbid, to modify it in some meaningful way, it is often orders of magnitude harder than it needs to be.

The same principle applies to communication. A healthy and open team will conduct communications in open channels no matter what is going on. When the public channels on Slack or other chatting tool are quiet and silent most of the day, either every is bunkered up in their silo or the team has fragmented into small cliquish groups for private chats.

This hurts the team in many ways. First – important information is not shared across the entire team. This puts everyone out of reach at a disadvantage. Second, it always leaves people out, whether intentionally or unintentionally. Feeling left out and alone is a negative aspect of working in teams that can hurt trust and efficiency.

In order to combat these direct messaging tendencies, issues and successes should be discussed and celebrated in open, public forums and channels. Stand-up meetings are good places for this as well as general public team chat channels.

Emails by default are also private messages unless we want to blindly copy everyone on the team all the time. These are a double-edged sword as emails are great for communication of specific information in a medium that is easily referenced at a later date – but the flood of emails from different sources can cause important messages to get lost in the shuffle.

A good manager will work on achieving a good balance in all communications to ensure a solid, yet restrained flow of information to their team.


Photo by Waldemar Brandt on Unsplash

Provide Ample Context

One of the quickest ways to lose control of a team is to continually keep asking them to complete tasks that, to their ordered and fastidious brains, do not follow any logic that they can currently comprehend. Context is king. Use it. This is not a need to know situation.

This is a difference between the statement of, “I don’t care how long it took to build the control, make it blue because that is what you are getting paid to do” versus “The client looked it over and happens to be colorblind. I know you worked really hard on it but we need to change from a red-green palette to a red-blue palette in order to achieve signoff.

Both lead to the same amount of work, but one provides logical context whereas the other ignores the context and commands acquiescence. Guess which one is always received better by the Engineer?

Managers need to provide context so that appropriate solutions can be provided. It is as simple as that. Managers that don’t practice this risk missing out on the full abilities of their teams. Having the proper context ensures that the solution is the best possible for the need provided, instead of the one called for in the specific task.


The goal of the Engineering Manager is to keep their team focused, efficient, and well informed. This reduces the opportunities for assumptions, finger pointing, and jumping to incorrect conclusions while keeping communication open and flowing throughout the team. If done correctly, these methods can greatly enhance the results and solutions for any team. Thanks for reading!

Comments are closed, but trackbacks and pingbacks are open.