My Style of Leading Teams
I had a chance to build and lead software teams over a few past years and in this post, I’m going to describe my way of doing it including what I want from the people in the team.
Vision
In personal life, it is good to have goals and dreams. In the manager’s work, it is a must. No matter if you run a company or build a small team, you should have a vision where you want to go and possibly get one day.
In the software development context, everyone wants to build great products with great business values and that is absolutely fine. But I see that as the operative part. To be a good manager, you should have some sort of strategy on how to achieve that over and over again. It is similar to football or any other collective sport. Everyone wants to win matches but to be successful in the long-term, you should set and practice some tactics with players (holding the ball or counter-attacks?).
My strategy for building and “running” a software development team as a team leader is:
I want (myself) to be completely redundant.
I know that this sounds way too generic, so below I’m going to describe my ways to achieve that. The actions of good leaders should be exemplary, that’s why I try to apply all of the following not only to my team members but mainly to myself.
Trust
I already mentioned it in my previous post about hiring developers that I build my teams on mutual trust. If someone joins my team, it simply means I trust that person already (otherwise I would not hire the guy). From that moment until the person leaves the team, I trust them in a way that:
The work is being done with the best of consciousness and conscience.
It does not mean working hard all the time, it means “doing my best in my situation”. And especially for software development and similar creative jobs, the best is often born when there is a good balance between work and resting. So yes, it is absolutely OK to take a break from time to time (e.g. read a book or watch YouTube).
Mutual trust has another implication: I can let my team make their own decisions thanks to the fact that I trust them. If someone needs something asking me: “How would you do this?”, most of the time I respond: “How would you do it?”. If the person describes what I would recommend or even a better solution, I let them do it. If their solution is worse, I usually let them do it as well. The “usually” depends on what the risks and impacts are. With a high risk or huge impacts, there is no surprise I must interfere and alter the solution to a more suitable one. On the other hand, with a low impact, I let the people experience “a controlled failure”. Controlled in this context means that I’m monitoring the progress and when the failure comes, I’m already prepared so we can fix things together. The experience is the best form of learning, even if it hurts sometimes.
Proactivity
A kind of well-known joke says that a problem that does not solve itself on its own is not worth taking care of. I encourage people in my team to do exactly the opposite. If there is an issue, I want them to be proactive in solving it and not expecting that anyone else will take care of it (as it almost never happens).
One of my colleagues says:
A bad solution is usually better than no solution.
I agree and advise people on my team to go by this rule. Even bad solutions are good in a way that they may help people learn from their mistakes.
Flow
Software development is a very creative process that requires strong concentration, a so-called flow. Regarding that topic, I love the “trying to fall asleep” analogy from EpsilonVector in the StackOverflow answer. I always encourage people to help others as much as possible, but not necessarily immediately at all times. They need to learn to protect their own flow, typically by saying “not now” or finding any other way of protection according to the company culture.
Protecting your own flow is one thing but it is equally important to respect the flow of others. This is quite hard for newcomers as they need to ask the most. What worked the best for me is to assign a mentor (or myself) to a newcomer for some time whose primary task is to help with onboarding. But even a mentor may want to do some other work — that’s why I always recommend this to newcomers:
Give a task at least 15 minutes before asking anyone else.
This ensures that they have tried to exhaust their options before disturbing someone else. If your culture and situation allow it, you may also use LMGFY :-).
Communication
I respect different styles of communication but when it comes to working, I believe it needs to be altered to effectiveness. For that, I want people to adapt to these three simple rules:
1. Filter what you say according to the people who are listening to you.
This one is very tricky and actually very hard! That is because it requires empathy and deeper thinking about what my listener needs and wants to hear. Usually, less is more. Empathy is hard to gain but I believe that it can be improved over time. I can recommend watching Sam Richard’s TED talk to learn something about empathy.
2. Verify that you understood well (don’t make assumptions).
Assumptions are very dangerous, especially in software development. I strongly advise not to make any and verify understandings instead by rephrasing what the speaker has just said — especially if it is a definition of a task or something important.
3. Communicate any risks ASAP.
People are usually unwilling to present any bad news. However, communicating bad news and risks is very important and most valued by the managers. That is why I reward people for telling them to me or to the team.
Tasks Understanding
One of the first things that most new leaders are taught is SMART criteria. I have found very useful to teach this mnemonic to basically everyone I’m working with. From my experience, people very often omit [M]easurable and [T]ime-Bound from this acronym, so I always put a strong accent to these two letters by explaining:
All your goals should have measurable criteria of success and a deadline.
Understanding what means done may be very tricky though. Mainly because it takes time and experience to understand all the parts that are related to the truly finished unit of work. I explain all the parts of the big picture over and over again. Before people come to an enlightenment, I remind them:
Always add a context what is done when you say “done”.
For example, if an implementation task has just been finished, you should say that you have finished only that part and ideally inform about any future tasks or stages that also need to be done (e.g. testing, UX verification, deployment…) before the whole task is truly done.
Recapitulation
I have presented a few important areas for teams I like to work in. As you may have found out, I don’t like and don’t want to do micro-management. Sometimes it is inevitable but the more self-organized the team is the better as it helps to reach my ultimate goal of being redundant.
To summarize the most vital points, I want team members to:
- know that everything is based on mutual trust
- be proactive (nothing will solve itself on its own)
- rest from time to time
- protect their own flow and respect the flow of others
- filter what they say according to their listeners
- verify that they have understood a topic (no assumptions)
- communicate risks ASAP
- have their tasks SMART
- understand what it means done (see the big picture)
Note that I haven’t mentioned all areas I find important for a software engineer’s job like programming-related skills, will for self-improvement and many more. This is because I’m planning to describe competencies and their growth in a separate post in the near future. Hope that it helped or inspired anyone, have a good day :-)
