Oskar Dudycz

Pragmatic about programming

On the importance of setting boundaries in team management

2022-09-21 oskar dudyczManagement

cover

Paweł Janas is a significant figure in Polish football history. He was a decent defender on his own, then coaching our best clubs and heading the Polish national team. His coaching maxim was: “I don’t fuck around”. Yes, Paweł Janas is a specific person, a glass of whiskey in one hand, a cigar in the other, old school.

For the last several years of my work in the industry, I have worked with people. Most of the time, as a leader. I quickly became a leader (after about a year of experience). I don’t think it was the wisest move by my boss. Yet, that allowed me to learn to manage in the wild. Working with people, especially managing them, is challenging in many ways. There is always something going on; constantly juggling emotions, problems and solutions.

I started like most of us: trying to play the role model. I hoped that team would follow me if I did well and set an example. I thought people would appreciate the commitment. It turned out that some enjoyed it, and some treated it as an opportunity to abuse my goodwill. Everyone is different, and each person requires a different motivation. You can’t treat everyone the same way, and you can’t make everyone happy. One of my employees told me that “Oskar, I know that I wasn’t doing my best recently. It’s good that you straighten me. I need someone to wig me.”. I am not a person who raises his voice or swears too often, especially at someone else. Yet, having to “straighten conversation” is very stressful. Nevertheless, to be an effective leader, I also had to learn to give negative feedback. How to conduct it?

The most important is to focus on the consequences of what happened, not the person. Explain to the person why it was wrong. It isn’t easy because often, people don’t even realize that something has gone wrong. Moreover, such a conversation is not about venting your frustration. The point is to explain what happened, understand what it looked like from the employee’s perspective, and determine what caused the error. If we are annoyed, attacking straight away, the conversation won’t go well. We will put the person in a defensive position. They will close, and will either argue with us or, worse, nod silently. Why is it worse? It means they didn’t understand what we meant, so they will not conclude. Then give particular points of what you expect in the future in a similar situation. The more discussion is focused on the specific topic instead of the personal discussions, the better.

Generally, if we are already in disaster mode, it’s too late anyway. Nerves won’t help. The mistake was made earlier, and the process failed. It is best to prevent issues instead of fixing them in a rush. I believe that being a leader means being available for the team and feeling the pulse. As I wrote in the Architecture Manifesto, technical leaders should code. They should also do the dirty work when the team needs help. That also means being a shield for the team for external issues. Of course, not entirely. If you take everything on yourself, you’re on the highway to burnout. You should protect the team but also teach them responsibility and what you expect from them. Transparency is key.

Here we get back to Paweł Janas and his “not fucking around”. In my opinion, the key to working in a team is to define clear boundaries. They should make it clear what’s expected from the team, what behaviour we allow and what not. Consequences should be equally clear.

It’s crucial to only set the rules that we can verify. If we are not able to do that, then you can be sure that people will learn to go around them. What’s more people will then project this to other, more important rules. So don’t waste time and effort on the rules you cannot enforce. People will have as much respect for us as for mindlessly placed road signs.To build authority, you don’t need to build full codex, but the most important rules around the process.

Okay, but I’m talking about enforcement, and this may sound like a contradiction of Janas’ maxim. Still, that goes pretty well together. If we define a boundaries, they will give people a sense of security. How come? If people know what the requirements are and why they are set, they know how to behave. They know that as long as they stay within the given boundaries, they can do what they think is right. We don’t have to do micro-management; we give people the opportunity to have authority and to make safe mistakes. If people don’t know what we’re expecting from them, they don’t know what’s wrong. This, in turn, may paralyze their initiative. Especially if our enforcement is then illogical and unclear.

Programmers are stubborn and picky; if we push them too hard, they will run away elsewhere. We must find a good balance and give them a chance to prove themselves and develop.

The teacher from my daughter’s nursery told me that “we always have to maneuver Ula in such a way that she thinks that’s her idea, otherwise she will not agree to something”. Paradoxically, this is probably also a good recipe for managing programmers and in line with the Paweł Janas’ maxim.

Cheers!

Oskar

p.s. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.

đź‘‹ If you found this article helpful and want to get notification about the next one, subscribe to Architecture Weekly.

✉️ Join over 5000 subscribers, get the best resources to boost your skills, and stay updated with Software Architecture trends!

Loading...
Event-Driven by Oskar Dudycz
Oskar Dudycz For over 15 years, I have been creating IT systems close to the business. I started my career when StackOverflow didn't exist yet. I am a programmer, technical leader, architect. I like to create well-thought-out systems, tools and frameworks that are used in production and make people's lives easier. I believe Event Sourcing, CQRS, and in general, Event-Driven Architectures are a good foundation by which this can be achieved.