Tales of a First Time Tech Lead (part 3): Trust

Previously in this series, I mentioned that people and processes come before the technology itself. Without well defined processes, it becomes very difficult to build, deliver and employ high quality software. Without people, it becomes impossible. If people are at the root of what makes a technology-empowered business hum along, then the tech lead must share the responsibility of doing whatever it takes for his or her team to perform at the highest level and be as close as possible to fulfilling their potential.

A key ingredient to unlocking this potential is trust. In “Leading with the Heart”, Coach K. writes:

“Almost everything in leadership comes back to relationships. And, naturally, the level of cooperation on any team increases tremendously as the level of trust rises. The only way you can possibly lead people is to understand people. And the best way to understand them is to get to know them better.”

— Coach K.

I spend a lot of time thinking about how to make a team (or, in fact, a team of teams) out of a group of people. The biggest eye-opener in my fairly short tenure as a leader has been how effective, enlightening and rewarding one-on-ones can be. It is mind blowing what you learn about people simply by talking to them. And for that to happen you really just need one thing.

You have to care.

It Starts at the Beginning

One of the things I decided early on as I stepped into a leadership role is to religiously have an on-boarding one-on-one with every single new joiner in my team. It is important for me to get a first impression and start on the right foot with everyone. I want them to get to know me as soon as they arrive and start building that trust right away.

I usually say that we all spend so much time in the office that we might as well enjoy doing it. For that to happen, we need to be happy: about the work we do and about the people we work with — provided basic needs are met. Working on that happiness begins there in that initial 1:1 simply because everyone is different and unique. My main goals in this conversation are to try and pick up on what makes that person tick and to convey that I will always strive to be fair with them.

I want to set some ground rules too. These are the foundation of our identity as a team and are non-negotiable. For example, my team does not tolerate oversized egos. My team always has business value front and center. And I always push for everyone to think and act like owners and leaders. Using a short slide deck, we briefly go over our core principles, core values, what our priorities as a team are, what is expected of us and how feedback sessions will work during their probation period.

I do my best to keep a live file for each of my reports, which I start at this point. I use it to collect notes during specific checkpoints but also to jot down whatever observations I may have at any moment. This helps me keep an accurate view of the engineer’s trajectory and capture situations we can later reflect on together. I find it important to timestamp everything as well, in order to keep a chronology.

Feedback is a Gift

Building trust within a team involves open communication, not only in an onboarding session, but also during our more structured review period.

As is standard in the industry, at least in Germany, employees go through a probation period in the beginning of their contracts. The way I see it, it goes both ways: it’s about the company understanding whether the employee “fits” but it’s just as much the other way around. I find it crucial that everything is in place to set the person up for success during this period.

At the company I work for, this is usually 6 months and we hold three feedback sessions during this period, more specifically at the 2, 4, and 6 month markers. While it’s been extremely rare that we let someone go (and always excruciating), the rule of thumb is that there must be no surprises one way or another. For a person to be let go, there has to have been clear negative (yet always constructive) feedback. This is important not just to be fair and transparent but equally to not have everyone else who is on probation fearing for their jobs.

I find it very enjoyable to conduct feedback sessions (and even more to receive them). Because I truly appreciate having my manager prepare and take the time to focus and help me become better, I make a point of doing the same for all my reports. The way I approach giving feedback, however, has progressively changed as I become more experienced and learn from each session. There is a massive difference in how effective feedback can be depending on how structured and well prepared the session is.

Getting The Most Out Of It

For engineers in this probation period, my current methodology is to do a 30-minute session with them at each of these checkpoints. There is a reason why the session is not longer: I want us to get to the point. And I want to indirectly demonstrate the value of short, focused meetings. They should be the standard for us.

I am trying to accomplish a few things with this:

  • Give the engineer a clear idea of what I currently think of their work and trajectory at the company, and constructively address any shortcomings.
  • Understand how the engineer regards their own work and how well it aligns with my view of it.
  • Get feedback about my own performance.
  • Give room for whatever the engineer wants to talk about.

In practice, I tend to break down these 30 minutes as follows.

10 minutes for me to ask questions

This is designed to bring out, through asking questions, a self-assessment but also to get subjective opinions on matters. I may ask what is the one thing they would have changed in the last N months, how they see their integration with the team, or what they think about a specific process. I certainly ask flat out where they believed they did a good job and where they felt they came up short. I also ask for feedback about my own performance in leading the team and in helping this specific person. This allows me to course correct, if necessary.

10 minutes for me (and the chapter lead, if applicable) to give direct feedback

This is where I deliver a few points prepared in advance regarding areas where the engineer excelled, and areas where they should make improvements. It is important that at least some of these come with specific examples and, in case of areas to improve, with concrete suggestions on how to improve.

10 minutes for free-range chat

Regardless of the profile of the engineer, I always give space to talk about whatever they want to talk about and be open to answer any questions (provided there are no overriding reasons preventing disclosure of a specific topic). Engagement with the work is sometimes severely impaired if you have questions hanging over your head or if you feel you don’t have the room or the trust to bring forward your ideas.

I won’t deny that I am still struggling to really stick to this structure every time, but I feel it makes for an effective way of running feedback sessions. Note that these are not performance reviews. Although close relatives and of equal importance, they are not in fact the same thing. Something for a future article, perhaps.

Ongoing Discovery and Continuous Feedback

Feedback is not just something that happens at predefined intervals, in pre-arranged situations — it’s a continuous process of getting to know each other and of building a relationship based on trust and mutual commitment. There is no better indicator of the health of a team than its members feeling safe and comfortable to give and receive constructive feedback. It not only means the feedback giver is paying attention and cares enough, it means the receiver has an opportunity to learn and the humility to do so. Make this part of the fabric of your team and you have the right foundation to be successful.

As an example, I recently did a presentation to my whole team to go over some internal data. After it was over and we left the room, I asked my chapter leads for feedback and what I got was blunt, very candid and extremely constructive. I know that, thanks to them, I will do a better job next time around. They acted as leaders and I am happy we were able to foster an environment where this is not only possible but becoming natural. By having our core principles, core values and core priorities in mind, every situation where we come up short is an opportunity to improve.

The Narrative

I tell my reports that, no matter how cliché it may sound, I want them to be better engineers when they leave my team than they were when they joined. It would be a waste of their time, my time, and the company’s time otherwise. One of the most rewarding things for me when having a 1:1 with an engineer — especially if it’s a new joiner — is to see a clear sign of what Colin Breck calls a “narrative” in his articles about tech leadership. This is about understanding we are all treading a certain path and some of us have strong beliefs about where we want that path to take us.

For me, an engineer with a narrative is golden. If they come into the team carrying it, that is fantastic. If not, we will work together to create one while helping the company at the same time. And whenever I am working with someone who shows a clear drive to get somewhere, it fascinates me but at the same time it gives me a very sobering sense of responsibility — this person is trusting me to help, even if in a small way, accomplish their dreams and ambitions. I have to be at my best.

It is their life that is at stake, after all.

If you got this far, thank you so much for reading and I hope it has been useful for you in some way. I’d love to hear your comments below and get the discussion going.

On a mission to help fix the way work. Leadership/Executive Coach. Previously VP Engineering, Engineer | hagakure.substack.com