A couple of days ago I had a long and deep discussion with a good friend around how to be best possible leader in a software development team. Throughout the discussions we identified many types of leaders we both had in addition to our own leadership styles. The conclusion was: The best leaders are the ones who really add value and not count successes. Maybe you wonder how you can add value without succeeding? Well, the answer to this is very easy: If you are doing whatever it takes to reach the goals of your projects without paying attention to the team or the organization you are working with, you are actually damaging on the longer term. Adding value on the other side, is when you contribute to the base line. Your efforts, ideas, work and impact will last forever and spread throughout pyramid.

When we give the introduction above a deeper thought, we may end up identifying that the best form of leadership for a software development team is «servant leadership». If we look at different theories contributing to the methodologies and frameworks we are utilizing in the IT industry today like, System Thinking, Lean and Lean startup, Agile Principles, LeSS, SAFe, Modern Agile etc., we see clearly the unity around self organization and how the leader is expected to remove impediments, bring clarity, mentor employees, organize training, helping colleagues get unstuck and not at least making the team feel happy about their work.

You need to move down to help others up

How to be a good servant leading a software development team (e.g. Scrum Master):

• First thing you need to do is to plan for growth. Make sure that you understand what kind of skills each team member has and how you can serve this person to grow
• Care about the team health, listen to all team members and do not leave anybody behind. Often you will meet at least one person who does not like to speak in public, make sure this person is also heard.
• Bring clarity into the requirements! The less uncertainty the better software quality and higher team velocity you get. Do not expect developers to understand the requirements if you do not understand it yourself! try to be a tester and challenge the truths that come from the business side!
• Listen actively during standups and retrospectives! use that knowledge to remove impediments, make things simpler and help reducing the risk in your project!
• Do not reduce the estimates created by developers, but challenge them in a positive way by reflecting on different aspects of the requirements. If the estimates are high, then you need to do more work on breaking them down into more understandable/doable chunks of work

At the start of everyday, look for what is going on in the team, is there anyone who is less happy, confused or just feel lost? If so, use time on bringing them to a level where you guarantee they will have a happy and productive day. most people will need only one word, one smile or just a supportive sentence or two. Others may need you to sit down, talk and analyze more. Use, the time! This is really what makes you a great leader.

If you are able to mix some of the ingredients above and try them in your teams, I am sure you will be bringing more predictability and less complexity to your projects and teams.

PS: As usual, if you think you need to discuss this more in depth with me, you are welcome to contact me!