5 ways to build trust with engineering managers

We have two options in life:

1. Never make a mistake or do anything to break trust with anyone, ever

2. Learn how to repair broken trust

The illusion of reaching perfection is tempting, but it’s just not realistic. Humans make mistakes. Our strength lies in our ability to notice our mistakes, own them, learn from them and repair harm that was caused.  

It is critical to learn to account for human error and have a plan for how to course correct when situations that put trust in jeopardy arise. Failure to address these issues results in work coming to a halt, anxiety to spiral and morale to drop.

Rather than hope we never encounter these situations, it is an intelligent strategy to know exactly how to navigate them and rebuild trust. 

There are five components necessary to rebuilding trust. Neglecting even just one will leave the repair incomplete. 

There is a difference between intention and impact. Most of the time we don’t intend to do harm. How many times has a request been made by an engineering manager or another member of your team, and they never specified when they needed it done?

In one person’s mind, it would get done by the end of the week. In another person’s mind, it needed to be done within an hour. Trust can be broken by small things, and we don’t need to have malicious intentions for there to still be some damage done. 

Regardless of our intent, if our actions caused harm, it’s important to acknowledge the impact.

When there is defensiveness or over-explanation of intent, it can shift the entire tone of the conversation. It puts the other person in a position of having to “prove” there was trust broken, rather than moving straight into a discussion on how we can solve it. 

Whether or not the intention was malicious doesn’t matter at this point — acknowledging impact is an essential first step before we can move into problem solving mode.

The second step is to understand what contributed to the impact in the first place. 

If a developer is consistently submitting buggy code, acknowledging that they are doing so, but have no idea why, an engineering manager and fellow teammates have reason to doubt they will be able to fix it.

However, if the developer submitting buggy code, takes a moment for self reflection, and realizes that he/she typically submits their worst code late at night, during a 3 a.m. coding session, it might be a starting point to begin to change this behavior and experience a different outcome that is better for the team. 

We have to identify what contributed to the problem in the first place, so we don’t repeat it. Apologizing for harm, and then doing the same thing over and over again, will not repair trust. It will simply confirm a lack of self awareness.

Once we have identified the problem we must come up with an adjustment. 

“We are not delivering on our tickets at 100% capacity because they are not being estimated accurately. In order to fix this, we are adjusting our estimating framework to improve accuracy.”

This is an example of what it looks like to identify the problem and proposes a solution that can prevent the event from repeating. 

Words are cheap, but action speaks volumes. After we have acknowledged the impact, identified the problem, and made the adjustments, it’s time to do what we said we’d do. 

Taking action and showing the difference our adjustments are making is the final step to repairing harm and rebuilding trust. 

It is not an easy road to take ownership of your actions and do the work required to rebuild trust, but when we have these tools, we don’t have to be afraid of making mistakes. 

Fear of being “imperfect” locks us up and slows us down. When we know how to repair harm, we can take action quickly and trust that we are skilled enough to correct and repair and move forward.