This is Agile’s answer to old-school leadership
By: A Product Owner With A Pen
Tags: Leadership, Project Management, Software Development, Agile, Scrum

Once I had to work for a big company’s daughter company as an external and I found myself in a giant pit with a bloodthirsty dinosaur, a relic from the 80s–90s IT industry. We had conflicts from the very first day, not just on a personal level but about how teams should be lead and how software should be developed on the first place. His leadership style, which made so many IT companies great in the last centuries was obsolete. Let me share you this story to show the main differences between agile and the good old days.

There are many animals in God’s zoo and this guy was one of the most remarkable ones. He was tall, obese but his passion was dancing. You always knew when he was nearby from the loud dad-noises he made. I believe that it is unfair to judge people by their looks, but the contrast between him and the rest of the office was so big that it can’t be ignored. If you had no business with him, he seemed to be a lovable creature, talkative and friendly like an old bear but also a bit grumpy when you stepped into his cave too much. I never saw his CV but he seemed to be around 50, working since the 90s, he was born and living in a western English-speaking country and he flew every week to our country only for this one particular project.

Before he got to this company, he was an architect at one of the largest and oldest US IT companies. First of all to be honest I’ve seen many architects promoted into leadership positions and all of them were a disaster. The same skills which made them brilliant architects were making these guys terrible leaders. There is a difference between possible and feasible, and this concept is unknown to them. A team is not a system of different components hacked together through interfaces and black magic. A team is not a machine which generates the desired output when you hit it hard enough with a hammer. I don’t say that all architects are the same, but there are people who have social skills, people who are aware of that they lack social skills, and people who are unaware of lacking social skills, and the IT industry for a reason is mostly staffed from the third group. I’ve been working with many brilliant, beautiful minds through my career, sharp-minded geniuses completely lacking self-awareness, social and emotional intelligence. So a guy like this had been promoted to be in charge of a team of 10. Abroad. I guess as it used to happen at big companies, he had been promoted to this position to be the problem of someone else.

Lacking social skills is not an issue if you are smart enough and have a genuinely good leadership style, but this guy didn’t have it. He was very proud where he came from, and he made us known very often how big sacrifice it was from his side that he came to our poor country of Switzerland, to the land of cavemen in order to teach us about software development and in order to bring us into the heavenly green fields of Anglo-Saxon company culture. He loved anecdotes, he had many, not only about his intellectual superiority but generally about how he believes the universe should work and how people should do their job according to his ideas and values. In fact 90% of our meetings were about someone saying something and then came a 20 minutes lecture about a completely unrelated topic. I felt like that I’m back in university where the teacher just won’t shut up about politics in a math class. Needless to say a lesson can be learned here already. I don’t think that this guy was an a-hole, I started to suspect that this is the way he learned to lead.

Lesson 1: In agile software development the leader serves the team.

Having a teacher-student relationship between the leader and the team members is not just undesirable but also counterproductive. When you are a Scrum Master or Product Owner, you are not doing a favor. You are not a teacher, you are there to serve and support others. Scrum calls it Servant Leadership. If you want a flexible, self-organizing team, then you can’t put yourself above anyone else, because if you do it, you are not just limiting the authority and taking the responsibility away from the team members, but you also assume ownership above their work. Yes you might be a Product Owner but you own the product and not the work. If I’m a developer in a Scrum team and you constantly interfere with me, overrule me and you give me lectures about how to do my work, I’ll say that I’ll deliver what you want but I don’t really care and I don’t feel responsible for it at at all. Now who makes a better, faster job, a developer who is in charge of his own work and who is self-motivated, or someone who was micro-managed?

OK let’s move on, he had these anecdotes and lectures but we managed to work and deliver. At least we tried. The schedule was very tight from day one and it was quite clear that we will miss all milestones and deadlines. And our the team leader did nothing. It was a fixed-deadline project, a working software had to be delivered in time or we would have lost the funding of the entire project including the hours spent. It’s fine, there are projects like this, I have no problem with it. The issue was that however the team leader was well aware that the deadlines can’t be met with the agreed scope, and hiring additional developers wouldn’t have solved anything, he did not renegotiate the scope, he kept on the pressure. The only time he renegotiated the scope was when we missed a deadline, and usually it was always the fault of one of us, because we were unable to deliver according to his plan. There are two lessons to be learned here.

Lesson 2: In agile software development deadlines are not a tool of control.

In old-school projects and in ancient leadership styles deadlines and milestones are not goals to be achieved, they are the edge of the sword, the end of the whip. They weren’t meant to be used that way but deadlines started to become nightmares when managers realized that they don’t need to reflect reality. Deadlines at big companies are used to be underestimated. The customer knows that you won’t be ready, you know you won’t be ready, the developers know it. But you still do it. Why? Lying about the deadline is good for the customer, because if you miss the deadline, they don’t need to pay you for the extra hours, you work for free. Your loss becomes their profit and they know it. Lying about the deadline is also good for you, because it makes you win the business in the first place. And who’s fault is it when you can’t deliver? It’s the fault of the lazy developers and they shall be punished. Besides this these old-school leaders believe that tight deadlines are good for the morale, otherwise nobody would work. In old-school management, employees are considered to be dumb and lazy, thus they need to be kept on a short leash to keep them busy, and deadlines are the perfect tool for it.

As an example in Scrum there are almost no big deadlines or milestones or they are rather used as a status indicator. As each sprint can be considered as a subproject, you have a small deadline at the end of every sprint instead of few big deadlines. In other words the big deadlines, the risk and the pressure is distributed between the sprints, so it can’t be used as a tool or weapon. Of course not delivering things will have consequences, but in a completely different way.

Lesson 3: In agile software development the responsibility is shared.

The other thing is that in old-school management you set up a plan then execute it and if things don’t go according to the plan, then someone is held responsible and accountable. And somehow, magically if things won’t get messed up really bad, it’s never the team leader or project manager who failed. I remember countless retrospectives where the end result was that however the management did everything right, somehow the project failed and it was never discussed further.

There is a reason while agile believes in shared responsibility and it’s not to escape consequences but to have a shared ownership. We are responsible for each other and we are responsible for each other’s work. We act as a team, as one unit. If someone messes up something, we all messed it up, because we did not provide this person the necessary support or we did not recognize an issue in time. There is no place for pointing fingers, or if there is really an issue which needs external resolution, there are supportive and not punitive tools and roles for them, for example that’s why we have a Scrum Master in Scrum.

Lesson 4: In agile software development people shouldn’t be kept under constant pressure.

Besides keeping the team on short leash with tight deadlines what this guy also did was constantly telling us that he can send us home any time he wants to and find somebody else. Lovely, isn’t it? Plot twist: at the end I was to be blamed for not keeping the deadline and I was the one who got fired. And I can’t be more grateful for it, I learned so much. This guy was completely the opposite of what I stand for, he represented everything what I find wrong in the IT industry. I’m convinced that he thinks the same about me until this day. I have no bad feeling about him because that’s the leadership style he learned. On the first day we started, we had a short talk about what should we do and how should we start, and a colleague of mine, who was also an external asked a simple question I don’t even remember and this guy started to rage that if this is the mindset we have then we don’t even need to pack our stuff out, we can go back where we came from right now. I was pretty sure that it’s just a matter of weeks and he will do it. I lasted 3 months. The thing is that he did not only do this with us, he did it with internals too, and if you know German companies you also know that it’s almost impossible to fire someone without very specific and very heavy reasons. So his weapons were the deadlines and threats that he will fire us or simply quit. I heard months later that on a meeting he had a tantrum that he will quit if people won’t work as he says and people told him to do it then. I don’t know if he still works there.

I made the story round here but I did not talk about the lesson yet. The point is that if you constantly hold a knife at the neck of your team members, they might perform better than average for a while but then the stress takes over, people start to collapse under the pressure and speed and quality will drop. As you based your authority on fear and total control, you put yourself outside of the team, nobody will cry for you and no one will be loyal to you. When your ship sinks, nobody will give his helping hand to save you from the frozen water. With this kind of leadership style which was very common in the 80s and 90s, to squeeze out as much as you can as fast as you can from the people by force is not sustainable and can’t provide the quality, speed and flexibility what today’s markets require. Slaves won’t build your pyramid faster if you hit them harder, and I wish you good luck for finding new slaves on today’s job market.

The base of every agile methodology is the recognition that people can deliver more, better and faster than you give them freedom and authority and not just responsibilities. Your task is to provide support, a framework so that your team members can act autonomously within it. And you won’t need a leash at all. People will deliver because they will enjoy what they do.

If you enjoyed reading this article, please support me with a few claps. Thank you!