Building trust — with people and software

Intro

In a previous post, I talked about the fact that as technical leaders, we often have more information and training on hard skills than soft skills. Specifically, I wrote about giving feedback and used “Microservices” best practices as analogies on how to do it right.

In this post, I will talk about the foundation for feedbacks (and any other type of communication) — building trust.
When thinking on a technical comparison, I thought to myself, how can I build trust with the code I’m writing, and the answer was clear — testing!!

So let’s get started!

Why Trust

I think we can all intuitively answer this question. When you trust people, you don’t have to spend unnecessary time on second-guessing, double-checking, forming alliances, etc. The same applies to software; when you trust your code to do what you expect, you don’t have to manually test everything for each change just to make sure you didn’t break anything.

Here is an excellent video by Simon Sinek about the importance of trust in teams.
(It is not entirely related, but it is Simon Sinek 😄)

Another way to understand why trust is important is to observe what happens when there is no trust.

1. Did someone tell you to “Never deploy on Friday!”?
2. Did you manually check your application is still working every 10 minutes while writing code?
3. Did you stare at your code trying to figure out why something is not working (or why it is working)
4. Is there a part of the code no one touches because all hell can break loose if you simply look at it?

Liam Neeson knows your code coverage is too low

And some no trust leadership examples:

1. Did your boss ever tell you something and you were not sure what was their “real” intention?*
2. Do you ever feel you have to do everything yourself to “get it right”?
3. Do you tell people to do stuff, and it doesn’t happen?
4. Do you avoid giving feedback because you’re not sure what will happen?

* if you think that about your boss, other people might think that about you

Tools

So we established (I hope) that trust is crucial, and we know that for trust in our software, we have testing.

— So you are suggesting to unit test people? 🤔

No no. Our tool for creating trust with people is…
🥁🥁🥁
One on One meetings!

— We already have those. How are they related to trust 😕?

I’m glad you asked!
The main goal of one on one (1:1) meetings should be creating a relationship between the manager and his or her direct reporter (direct). A strong relationship builds trust.

Focusing on the goal

Understanding the goal is very important to achieve results effectively.

If we remember that our goal in testing is to be able to trust our code and not to achieve 100% coverage, for instance, we would make sure our tests are descriptive and focus on expected behavior and not on the implementation details.

Similarly, our goal in 1:1s is to build a relationship between us and our directs so we can trust them and they can trust us and not getting updates on project status, for instance. We should make sure we get to know each other, actively listen, show that we care, etc.

Before starting

You should announce in advance any change you want to make as a manager. If you’re going to start doing testing or 1:1 meetings or you already are doing it and want to change the approach, it is best to explain the motivation for the change and what is going to happen before you start.

Your team should be on board with the new approach because they will need to be a part of it — either write proper tests or come prepared to 1:1

Once you establish 1:1s, they can also be an excellent place to talk about other changes you want to make.

Clear structure

To structure our tests, we use the AAA pattern — Arrange-Act-Assert.

describe(‘some test’, () => { 
  test(‘should test behavior to be something’, () => {
    // arrange
    mockSomeStuff()
    mockData = createData()
    expectedResult = getExpectedResult(mockData)
    // Act 
    const result = someFunction(mockData)
    // Assert
    expect(result).toEqual(expectedResult)
  })
})

In 1:1, we would also have a definitive structure.
Schedule every 1:1 meeting for 30 minutes in the following way:

1. 10 minutes for them
2. 10 minutes for you
3. 10 minutes for the future (coaching status, discussing objectives, etc.)

If there is nothing to talk about in the last section, the agenda would be:

1. 15 min. for them
2. 15 min. for you

Very important to let directs speak first, you can always talk to them, but they don’t always have the chance to speak. If they need more than 15 minutes, let them have it.

If the direct has nothing to say on his part, ask some guiding questions like “what went well?”, “what have you learned?” “were there any blockers you could have used help with?”. If that doesn’t help, ask about specific projects or events.

Timing is everything

Tests — we should write tests as close to the code as possible. If you are working with Pull Requests (PR), for example, all relevant tests to the feature should be part of the PR. If you have missing implementations for a bigger end to end test, you should write that test as soon as you have what you need for it to run. The motivation is simple; if you write tests together with your code, it makes sure your code is testable and that you still remember what it should do. Also, you make sure your code will behave as you expect it so you can deploy it safely.

1:1 — Once every week. No exceptions. Here as well, the motivation is simple; if we have a 1:1, every week, employees don’t need to wait for more than a few days in most cases if something is bothering them. Also, most people have a hard time remembering what happened two weeks ago (not to mention even longer), so if we wait to talk, some stuff might get lost.
Manager tools* did significant data collection to show this is the most effective approach (If you don’t trust me, 😛 you can listen to it yourself).

Consistency

In code and when managing people, consistency is crucial, especially for trust. When something is consistent and predictable, it is easier to trust it.

Effective tests should be consistent on two levels:

1. They should be reliable and consistently work unless logic has changed (and even if the implementation did).
2. They should use consistent structure and follow the same convention

Our 1:1 meetings should also be consistent. Every week, a similar place, same opening question.

— Same opening question? 🤔

On top of helping to get into the 1:1 mindset, using the same question allows us to see if there is a change in the response. If I’m asking “how is it going?” and the usual answers are “great”, “super” or “really great”, when I hear something like “OK” I can suspect something is up and ask about it.

Pyramid

Most of you are probably familiar with the testing pyramid

You probably already know the different test types but just in case:

1. Unit test — test a single logical unit (usually a function)
2. Integration test — test the communication between logical units
3. “End to end” test — Test an application use case externally (e.g. do a REST call to the application server and test the response)

The goal of the pyramid is not to say that unit tests are better than integration or “end to end” tests; it shows us that integration and end to end tests are costly and we should use only where a unit test is not enough.

In leadership, we also have a pyramid, the “power pyramid.”

Here is a simple way to explain the difference:

1. Relationship power — Can you do this thing? (because I asked)
2. Expertise power — Can you do it like this? (because you respect my expertise)
3. Role power — Do this thing (because I say so)

When we want to get someone to do something for us, what we should use most often is the relationship power. Expertise power works very well with technical people, but you have to be an expert in everything to use it all the time. Role power also work but comes with a price — use it too much, and no one will do anything unless ordered to

Pair programming with Kim Jong Il

Tests are documentation

When written correctly, tests will become the documentation for the system. If a test clearly describes what a component should do, we don’t need to look at the implementation to understand it.

1:1s can be great for documentation as well. I usually write down feedbacks I gave (even if they didn’t deliver them in the 1:1), what we discussed in general, and action items.

If you take notes during 1:1 meetings, you will have a lot of data to be able to see patterns and have decision-making material such as arguments and examples for why someone needs to get a promotion, change positions or, unfortunately, let go. It is also a great source of information for yearly reviews.

Sanity tests

On top of the usual tests that run for every piece of code we add, we also have sanity tests that run on every new release.
Those tests don’t try and look at specific features, but just make sure the system as a whole seems to be working.

We can do something similar to 1:1s. We can have a periodic 1:1 meeting (e.g. quarterly) to do a “sanity check” and ask how is it going on a more general scope. We can use previous 1:1 notes to look for patterns in the last period and discuss them in the meeting

Dealing with pushbacks

You might be worried that some of your developers will pushback on starting to write tests or coming to 1:1s, and you might be right. Here are some tips that can help

1. Give your directs a “heads up” and explain the motivation.
2. Don’t rush the process; as long you see progress, you’re ok.
3. Set an example — write tests, comment on tests in code review, come prepared to 1:1, be genuine, share stuff about yourself (even personal)
4. Give positive feedback on effort
5. Be consistent and remember the guidelines

In most cases, it will work after a while, but sometimes it won’t. If you don’t see improvement, start giving negative feedback on pushing back.

If feedback is not working check my guidance on systemic feedback

It might be difficult if you don’t already have a good relationship with your developers, but if you do 1:1 correctly, any future changes will be much easier to introduce.

Summary

Trust is crucial for a productive team. It might take time to build, but you have the tools to do it. All you need is to be consistent and follow the guidelines.

If you don’t have high-quality testing and frequent 1:1 in your team, I recommend you start working on it. You can thank me later 😉

It might take some time, and there might be some pushbacks, but it is definitely worth the effort.

Additional information

1:1s
The content of Manager Tools heavily influenced me, and I highly recommend it. Manager tools have a free podcast, a book, and other training material.

According to Manager Tools, if they can get you to do only one thing as a manager, it would be weekly 1:1s.

Testing
If you are not convinced testing is important, you can try reading this amusing post by the testing evangelist Gil Tayar.

For more heavy-duty material, you can check out what the great Martin Fowler has to say on testing here