Skip to content

A few things I learned on managing an engineering team

Published: at 06:33 PM (4 min read)

Table of contents

Open Table of contents

Introduction

More than two years ago I was working full time as a frontend developer at mono, a web agency based in southern Italy. A few successful projects led to a fairly rapid general growth, which meant I had the opportunity to take on a leadership role and see things from a different perspective.

After a few years choosing what to delegate and to whom, what to deal with personally, who to hire in order to design a sensible team while at the same time trying to keep growing myself technically, I’ve learned some things. Most of them may be obvious to many, but have been insightful to me when I learned them from within, a “bottom-up” learning process that hits differently than the plethora of Medium etc. articles providing actionable but sometimes sterile advice, since every team is unique.

Modulating your absence

If someone asked me to tell briefly what I think management is, I’d answer that it’s mostly about continuously finding the balance between presence and absence among your teammates.

The easiest thing to do is to be overly present, wanting to be involved in everything your team does and never truly letting go of the need to keep everything under control. After all, you’re only trying to support your colleagues, right? Not to mention the fact that, as a leader, the responsibility for anything that may go wrong will always be at least partly yours.

You don’t need to micromanage in order to fall into this trap: sometimes all it takes is inflexibility in the face of a different proposal by your teammates, fear of losing control that becomes excessive caution, or a failure to recognize unexpressed potential in a colleague or any situation in general.

In fact, I’d say that the most difficult thing to do about modulating your presence is knowing when to get out of your team’s way. Hopefully, you contributed to hire smart, capable people: your job as a leader should be both to be there when your team needs direction and to step back when the team is confident in getting the job done, even if differently than you have would.

Trust is a two way street

Teams are made of people, and people are driven mostly by emotions. There can be a huge difference in the behavior and the results produced by the same people if they trust your leadership, respect you and your company’s contribution to their own personal project, and agree at a fundamental level to a common mission you’re all embodying.

A team project is a common struggle to create, fix, innovate, and everyone is better when there’s a climate of mutual trust and respect, because both are the foundational elements of cooperation.

Numerous, hidden social dynamics are at play even when only brainstorming the tech stack for a new project together. Your opinion and your leadership will be perceived as more worth listening and considering if your team respects you and your expertise. You could impose yourself with authority — after all, you are the leader — but everything would become worse because of it.

Just as you learn to trust someone who tends to solve problems rather than to cause them, your teammates will trust you if you prove capable to solve their problems and to be effectively helpful to them.

People prevail over process — for better or for worse

I’ll repeat that here, because it’s the most important thing: teams are made of people. It’s like dieting versus exercise: you can be fit by only following a healthy diet with little to no exercise, but you can’t do the opposite. If your diet is unhealthy, there’s no amount of exercise that will make you lose (or gain) weight.

In the same way, there is no policy or process that can fix a team made up of the wrong people; however, the right people will indeed find a way to solve problems regardless of process.

It could be the way your team reviews code, how it handles learning from the experienced and teaching to the less experienced, up to more abstract intents such as fostering quality ideas and innovation: people will make the difference between a network of passive automatons or a living organization that creates value.