On How To Lead Devs

During the last two years, my role in my current company has shifted from being purely a developer. It is still mainly a technical role where I am tasked with designing and implementing software, and I have also been entrusted with a few (junior) developers whose code I review and for whom I write tickets.

This is a first for me, as previously, I had no one who could be annoyed by me or my behavior. As I personally know that the attitude of a superior (even though I don't consider myself to be one) can have a huge impact on the morale of the people who have to work with them, and I have also left companies because of it, I want to try to avoid the same mistakes that always annoyed me.

This is probably not the first post of this kind that exists on the internet, nor will it be the last. What follows is my list of five things that I want to do better when leading people from a technical background. I ask anyone to measure me against these standards that I will set for myself.

Appreciate consistent results

This is something allegedly even Google struggles with. Understandably so, considering the environment in which a middle management person usually exists, where your mind is fixed on the next fire that needs to be put out and the deadlines you expect to miss. Especially because of this I think that it is important to stop once in a while and give praise to all those people that have recently hit all deadlines and make sure that their achievements are just as visible as those of the people that threw together the latest, shiny proof of concept.

Create an atmosphere in which one can openly talk about mistakes

Mistakes happen. Deadlines are missed, stuff breaks in production, a customer feels neglected and complains - the possibilities are endless. Usually these things lead to extra work. Overtime has to be put in. Someone stays late. This means that not only does the overtime counter tick up , but personal lives are also affected: Someone might have to cancel their plans or spent less time with their children. After the stressful period is over some hands are shook, "well dones" are spoken and the stress is quickly forgotten, but nothing is done to prevent the same thing from happening again.

The reasons why can be quite manifold, let it be because the next deadline or incident is already looming and no one even thinks about taking the time to analyze what happened, or because the person that feels responsible for the mistake is afraid of the consequences or simply does not like to talk about their own errors. Without reflection there cannot be any improvement and without improvement people will get "tired of this shit".

An atmosphere to talk about mistakes openly and without fear of repercussion is needed, but this is something, I think, that can only be created through example: I need to openly talk about my own mistakes, create post-mortem meetings whenever something goes terribly wrong and try to be realistic while doing so.

This will not only encourage others to be more open about the mistakes they have made, allowing everyone to learn from them and creating the possibility to improve my company's processes, but it will also improve their morale when overtime had to be put in to fix a mistake, just because someone acknowledges that something was wrong and tries to find out how these thing can be prevented in the future.

Leave room for emotions

Every employer wants an employee that is passionate about their work, right? Someone who always gives their all and is highly motivated to put in the extra mile. But at the same time, this person should always be professional and leave all emotions at the door. In my opinion, such an employee cannot exist. One has to choose.

I'd rather work with people who love what they are doing, but this means that I will have to account for their feelings - after all, working on a long-running software project can be like watching a child grow and learn. This is especially important whenever there are structural changes to the organization of a software development team. Whenever people are moved from one project to another, or a project is cancelled completely, it is important to make sure that the changes will not impact the morale of the people that are affected or the team as a unit. If this is unavoidable, one must take the time to onboard everyone as to why the changes are unavoidable and how you made sure that this is really the case.

Know the expert(s) in the room

Even when you are a full time developer, there can be (sub)systems in the software that you are working on every day that you have never touched or don't quite understand. If you don't spend the whole day shuffling through code anymore, those areas get bigger all the time, while your opinions continuously gain gravitas. When leading devs, it is important to know where my own knowledge ends and take the concerns of my engineers seriously, even if I don't understand them on a technical level (anymore) - nothing is more frustrating than warning about a problem and not being taken seriously, only to encounter the exact same problem later on.

In these cases I want to develop a plan with my engineers on how to evaluate the impact of the concerns that they have raised , and how they can be addressed before they get too big to handle.

Throw yourself in front of the bus

Even if I and my team do everything right, there will be a time when shit hits the fan. When this time comes a good tech lead has only one job: To keep the brunt of the stress away from the team to allow them to fix the causes for the situation as fast and as thoroughly as possible. This will most likely include unnecessary and/or unpleasant meetings with stakeholders, but it is way more efficient if one person sits through it all than if the whole team has to juggle communications with working on a solution.

While doing so, I want to refrain from finger pointing at all costs - if I think that there was a possibility to prevent the situation there will be plenty of time to talk with the team after the situation is defused.

About the header image

Generated with GPT4 on 2024/03/18, prompt:

Envision a scene where a modern dwarf from the Warhammer universe is sitting inside a cluttered server room, fully immersed in reading the Book of Grudges. This dwarf is casually dressed in a black hoodie and blue jeans, with no armor in sight, reflecting a blend of fantasy and contemporary styles. Beside him on the floor, a laptop is open, its screen glowing softly amidst the chaos. The server room itself is a mess of technology, with disconnected cables littering the floor, draped over furniture, and tangled around server racks. The juxtaposition of the ancient book in the dwarf's hands against the backdrop of modern technology and casual attire creates a unique and captivating image that bridges the gap between fantasy lore and the digital age.