I've been spending a lot of time lately being self-reflective and this week I was thinking about building trust. The more I thought about trust, the more I wanted to write something about how to build trust with your team, lead or even boss. I've got a unique perspective having been a team member, team lead and lately the head of a department. Trust is something that takes time to build and an instant to destroy. But once you gain it, pairing it with influence and credibility is a powerful combination for you as a technologist. Let's dig into building trust in a technology team.

Trust

Trust is a fickle thing. The strongest of relationships are built upon and a relationship that is fractured is generally lacking it.

Webster's defines trust like this:

firm belief in the reliability, truth, ability, or strength of someone or something

There are countless articles, books and spoken word out there about trust. But what I want to dive into are some techniques and actions I like to do to build trust when I'm new to a team. In addition, I aim to provide you with tips and insights into how a tech leader thinks about it.

Trust in a Tech Team

Briefly put your mind back to a time when you were new in a tech team. This could be an engineering (scrum/waterfall) team, a solutions support team or maybe you are in a developer relations role and more customer-facing. Trust is trust and on day one I think you have two camps of people.

Camp 1: Welcome to the team, so excited to work with you. And they trust you almost instantly.

Camp 2: Welcome to the team, so excited to work with you. But you've got to earn your stripes.

There's nothing wrong with either of those approaches by the way. Often, Camp 1 is Camp 1 because they have trust in their leader and the process and know that a new person wouldn't be brought in that is untrustworthy.

Either, being the new person is hard. Building trust takes time. But how do you get started?

Find a Way to Add Value

Day 1. Find a way to add value to your new team. It doesn't matter if you are sharpening pencils or solving the most complex of problems that your new team has been struggling with for months. Add value.

But why? Simple. Digging in and rolling up your sleeves shows that nothing is above or beneath you. Put yourself in your new team's shoes. Does this new person add value to my team or does this new person take value from my team? Try not to be that person that takes value from your team. And surely don't take that value on purpose.

Tech teams are generally working on hard problems and expending loads of mental energy to hit their delivery timelines. When a new person comes in, if that new person makes things better, a little bit of trust gets added to the trust account.

And as the leader of that team, it does a couple of things.

1. It confirms those assumptions that you make during the hiring process. While it also affirms the decision to hire. Builds trust
2. A leader often is solving or doing things that can't be seen. There's never a shortage of things to delegate. Want to make an impact on your boss? Be the person who says "I'm on it boss". Be the solution to problems, not the identifier of them.

Be selfless with your time

Time is our most precious asset. Where you give your time says a great deal about the people and things one cares about. If you remember back to building influence, building trust is about how you spend your time.

Put yourself back in a mindset where you were the youngest, most junior or least knowledgable in a situation. This doesn't have to be technology-related, but if it is, you know how silly you felt. You remember how much of an imposter you thought you were for being in that position. Additionally, you probably didn't want to "waste anyone's time" with your question or suggestion.

Flip back into the position of being new to a team. Even if you aren't the expert, give up your time. It sort of goes back to finding a way to add value, but this one is a little more personal. Giving your time to help someone on your new team shows a level of commitment and being bought in. Remember, time is our most precious asset. If you want someone to trust you, you need to give away, for free, that which is most precious.

The second thing that'll happen though as you trust is that you will be in a relationship with that person or people as you spend time with them. And ultimately, building relationships and bonds on a tech team is worth way more than any feature delivered.

From a leadership perspective, when I see team members who are selfless with their time and freely give it away, I know that I have an individual who is committed to making the team as a whole better. Super cliche, but a team is made up of a sum of parts. And that sum is greater than any individual contribution

Approach interactions ready to listen instead of speaking

This is a big thing in my opinion. Technology can bring out passion and energy in some people. There is nothing wrong with this, but if you are new to a team, come with the intent of listening. My mother used to say, God gave you two ears and one mouth. You should listen twice as much as you speak. I believe you'd be wise to adhere to that early on in a new team.

My thinking is simple. You are the new member. When working on a new problem, understanding what questions to ask is more important than offering suggestions. Now this doesn't mean remain silent. But what I'm saying is, listen to your new teammates and then, once you've first reflected the situation to them, offer your suggestions.

As a leader, I want people on my team that I know will understand the problems, people and dynamics involved before offering ideas and solutions. The reason for me is that solutions come and go, but the trust gained and the relationships built by listening far outweigh those short-term solution benefits.

Be a Contributor

So you are probably thinking that this is a lot like "Add Value". And it is, but it's bigger than that. Adding value on day 1 is all about engaging and showing your new team that you are interested in them and their challenges. And that you are there to help. Being a contributor is more about elevating the team daily vs your individual goals.

Once you've built some trust, contributing to your team daily will only deepen that which you've built. You want to be known as the person people can count on. That could mean:

• Peer reviews for help with code
• Solution reviews on a new design
• Manual testing if you've finished your work early
• Writing tests even for code you didn't write
• Helping with project management tasks when you've got the space
• Assisting your product leadership to make the backlog the best it can be.

Building tech team trust is a lot like building a sports team trust. My teammates need to know that I'm willing to do whatever is necessary to make us better and ultimately succeed.

Be you

Last, most importantly and maybe the easiest or hardest, BE YOURSELF. Show up each day as you. If a team doesn't want "you", then you need a new team. That's hard to hear, but we aren't made to win in every environment. Pippen didn't win without Jordan. And I don't know that Jordan wins without Pippen. He surely didn't win in Washington.

Seriously though. Your best tool in this whole thing is to know yourself. Understand your strengths and weaknesses while playing to what's strong and be honest about what's weak.

Be you as there is only one. And you are enough.

How I like to Build Trust Early

Above are a few tips that I've passed along to others before about how to build trust in a new tech team. They aren't exhaustive but they are a start. And if you notice, they are very much about building credibility, demonstrating accountability and ultimately letting your team know that you are in it for the whole and not just you as a part.

The genesis for this article was me thinking about my process and how I've typically built trust in my teams or with my teams. Someone asked me "my process" and at first thought, "I don't have one". But I do. Maybe it's not linear, but here are the things I like to do and hope that they may help you as well.

By the way, these have worked for me at the individual contributor level with peers and a manager up to establishing trust at the C-Level.

Engagement and Relationships

My recipe for building trust personally starts by engaging with those that I'm working with. I don't like the term boss, I prefer to just be a member of the team who happens to have different responsibilities. So I make a big point to involve myself in as many of many team activities and projects as possible. I 100% DO NOT adjust or do anything while I'm learning. I mostly listen. Gather facts, and opinions and "read the rooms".

I'm ultimately looking to build relationships. Because at the heart of a tech team is people. And people are more about relationships than they are about Pull Requests.

The main goal for me is to let people know, I'm here and I'm here to help. I aim to help them do whatever it is they are doing better. I prefer roles where I'm additive to an environment. I can build from nothing, but most of the time, I'm not hitting File New on an entire culture. I've done it before, and it was great. But in general, I'm focusing on providing support. I have no preference for leading from the front, middle or back. There are times and seasons for each.

Show up when it matters

Ever seen a senior leader on a deployment call? Or hang around one evening when things were tough? Ever seen one offer code or suggestions when a production issue was occurring? I like to. And here's why.

People that are in your charge want to know you support them. What's the best way to support someone? Just be there. Remember further up, be selfless with your time. Nothing says that someone or someone's problems matter like giving of your time when it's not convenient.

Showing up is one of the single most important things I like to do as a leader as I'm building or maintaining trust.

Ask of others, only what I'm willing to do myself

This is another big one and one that I ended up having to prove from time to time. I try hard not to ask people to do things that I'm not willing to do myself. This is important to me for one main reason. I want to be able to be empathetic to whatever they are going through while building that task. Empathy is connected to intimacy which is connected to authenticity. And those that know me, know I'm 100% authentic. It's critical to me that people I'm asking to trust me understand.

Embrace bad news

The last part of what I like to do, and again this isn't linear, is to embrace bad news. Put yourself in this position, if you had something bad to tell your boss, and your boss is likely to blow up on you. Are you going to tell them what they don't want to hear? No! Of course not. No one wants to do that. And honestly, it's an indication of a low-trust relationship.

Contrast that with a leader who is willing to listen (back to that listening), empathize (because they've done it before) and help you navigate towards a solution (giving of time). That leader more than likely isn't solving your problem but often is looking for ways to make the situation less bad or help communicate at levels you don't have access to. This is 100% what I like to do.

When people begin giving me bad news, it's the best indicator that I've developed trust with that person or team and that a foundation has been built for a relationship.

Bottom Line, it's about people and relationships

I've just gone through what could be multiple chapters in a book in a single blog article. So if you are still with me, THANKS!

Ultimately whether you are an individual contributor or a leader embarking on a new team journey, your first order of business should be to establish trust. And consequently, you will probably have built relationships along the way.

Technology teams are team sports. I know a lot of tech folks who didn't play sports, but I've seen many tech teams that are more teams than some soccer teams I've been on. Just remember, you need to build relationships.

For me, that's done through listening, engaging, giving my time, being empathetic and embracing the bad news. It might be different for you, but figuring out your process is a helpful activity.

Thanks so much for reading and I hope you enjoyed it!

Happy Building!