Building high-performing engineering team

How to make your team effective

A couple of years ago, Google and it’s re:Work team published results of the study about what makes teams high-performing. What was the important takeaway? It’s not about who do you work with, but how do you cooperate as a team.

Psychological safety was called the most crucial dynamics that drive a team’s efficiency the most. It’s more critical than work meaning, or the impact we have on society. Feeling safe makes us more resilient, open-minded, and confident. According to HBR, the roots of it hide in our nature. The evolution developed our brains in a way where every threat is responded with fight-or-flight reaction. Each situation that we aren’t comfortable with results with narrowing the perspective and shutting down analytical reasoning. And the psychological safety is here to help with that.

It all sounds great, but now you can think — who should lead the change? What can I do to improve the psychological safety of my team? Those things don’t have to come from the very top. Actually, you, the team leader or even a senior software engineer, can have an impact on the psychological safety of teammates.

Blameless culture

We live in a time of constant change. Very often moving forward in a linear-growth manner isn’t enough. You cannot build a better product or better processes, in the same way, year by year.

You cannot be resistant for a change. You should seek for it. But very often, to change something, you need to break it first. And sometimes you will fail — it’s a normal process of learning.

But is it really normal for you? Your company, your team?

Do you and your teammates feel comfortable with failure? Or maybe is your team afraid of an embarrassment? Is it easy for them to admit the wrong decision they made?

If your company cannot tolerate mistakes and it doesn’t give any space for trying and failing, your team won’t learn. They won’t share their ideas, or even worse — they will stop asking about reasons behind some decisions you or the company made. And If they don’t know or don’t understand goals, how they can strive for excellence?

While taking the risk all the time can be dangerous, not taking it at all can harm your teammates and the company equally badly. If you haven’t done it yet, let’s think about how to introduce space for moderate risk-taking. Otherwise, you will stop moving forward.

Risky friendly environment

Risk-friendly workspace is not only about people and communication. To improve psychological safety, you can also introduce some techniques directly in your tech stack. First — automate testing and deployment processes. When you decide to introduce a new solution like code architecture or replace 3rd party integration, your tests will be there to ensure that your product still works.

How would it help? Your tech stack also has to evolve — to adapt to new processes, bigger teams, greater complexity. Solutions that you picked at the beginning won’t be enough — not scalable, not so fast, too hard to maintain. Automated QA process will give you enough space to move forward with technology.

Live example? At Azimo, we could migrate RxJava to RxJava2 (hundreds of files) within one 2-weeks sprint, without harming our customers. And It simply wouldn’t be possible without proper automation in place.

For more about how and why you should automate testing, check my article: Automated testing will set your engineering team free.

Next thing — introduce remote feature flags and controlled rollout process. Often product delivery is delayed by very (very very) cautious software engineers who multiply edge cases and possible failures in their heads. But sometimes you won’t see a full picture until your product reaches end-users. Controlled rollout process and remote feature flags will give your engineering team more control “afterward”. They can sleep well, knowing that even when they fail, it won’t affect hundreds of thousands of users at once.

To make it even better, you need to know that when something fails, this information comes to you first. With feature flags, you will give your engineering team control, but with proper data, you will give them the freedom to make decisions more autonomously.

Here you can read about some solutions that help engineering teams at Azimo to keep a finger on the pulse: Dealing with bugs on mobile apps.

Work and expectations predictability

Re:work study calls it “Structure & Clarity”, and puts as a separate point, next to “Psychological Safety”. But actually, expectations predictability can also be an integral part of feeling safe at work.

Take software engineers as an example — it is expected from them to deliver working software to end-customers. Easy, right?

It’s not that simple in reality. Software delivery is the result of work. But without proper clarity, it can be really hard (even for a senior engineer) to make it happen. In fact, they can work hard, sometimes for weeks or even months, and the product won’t be there. And it can end up with scenarios like:

They are demotivated because they don’t deliver, despite working hard. They expect to be rewarded because they worked hard, but you cannot do this, because they don’t deliver.

In both cases, we can see the same problem — expectations regarding your teammates weren’t clear enough. They worked hard, but they didn’t have enough engagement to put their workforce in the right place.

By exactly knowing what is expected from them, they can focus on excellence instead of worrying about what is and isn’t their competence. So don’t ask for “making the job done”. Explain what does it mean to do the job well. Expect things like:

Ownership — they are responsible for product (not the code!) delivery.

The product is delivered when: backend is done, client-side is done, cross-platform communication is done.

The product is delivered when: backend is done, client-side is done, cross-platform communication is done. Partnership — they don’t only implement, they advise.

Are you client-side engineer? Talk with a designer about what’s feasible what’s not. Propose what can be done instead of talking “this animation doesn’t make any sense on Android”.

In teams I work with, we name our expectations by very clear Wikipedia’s definition:

Being a software engineer — Don’t follow commands, resolve problems. “Software engineer is a person who applies the principles of software engineering to the design, development, maintenance, testing, and evaluation of computer software.”

Hearing their voice

Very often, blameless culture isn’t enough to guarantee psychological safety. You also need to have a space for honest, undisturbed discussions. 1:1s sessions are very often underestimated, especially in start-ups and smaller companies. They also aren’t easy to run. But the earlier you start, the sooner you realize that it is not possible to build an efficient team without them.

There are literally hundreds of publications about 1:1s, so here I’ll leave just a piece of advice — during those meetings you are both equal. And honesty is the most important value you both should seek (you will likely need more than one session to find it).

Many sources say that 1:1s are for them (your teammates). I believe they are for both of you equally.

They can motivate them, point them the direction, develop their skills. But they will also broad your perspective and make you understand.

They will make you a better leader, a better teammate, a better person. There are not many other things that taught me so much — about me, my team, and the company.

How does that help with psychological safety? In hard situations, it will be much easier to deal with tensions knowing the full context. Live isn’t black and white — you won’t agree on everything. But at least you can understand each other’s motivations.