I’ve noticed over the years a lot of articles discussing leadership over management. For many of those years I did not understand what people were talking about. So, this article is based upon my personal experience of developing software and teams over the last 40 years.
My background is that of a software engineer. So, when I found myself in a management position, due to rapid growth within my first startup, I did not know what management was. So, I started by looking up the definition in a Collins dictionary, I don’t have that but online I found this which is probably broadly what I read before:
1. The process of dealing with or controlling things or people.
2. Trickery, deceit.
Oxford Languages
So, then I bought the “Ladybird book of Management” (honestly I really did). That did not make me much wiser so I asked a colleague.
Get a Room
Then I asked what is the definition of a good manager. He said “a good manager is one who can die in their office and not be discovered for 2 weeks !” (honestly , he really did say that). I think the idea is that the team would be so well organised that they would never need to consult with the manager.
Being very wet behind the ears I assumed that a good manager had an office. I was based in an open plan office in Hillington, Glasgow (best city in the universe) but there was a wee office in the corner. So, in I went there to revolutionise the performance of my team.
After about 6 weeks I realised that I had no idea at all what was happening in the business. When I was in the open plan area, I could overhear the general chat and ‘felt’ the atmosphere in the business. From that perspective I could tell if an issue was brewing or one of the team members were struggling etc. In my office (even with its open door policy) I had no idea what was happening. Also, as I had put a physical barrier up between myself and my team, I had unconsciously sent a message of dont bother me I’m busy and the information flow lessened because of that.
It was a good lesson and I’ve never had an office since that day 35 years ago.
Don’t get a Room
So, now I’m starting to get an idea of what management is about.
It’s about people.
“No shit Sherlock”, I hear you say, but I had to learn. Now I’m starting to get a bit more savvy and start to read Drucker, Maslow, Collins, Lazier, Kaplan, Norton and even Dale Carnegie.
I start to dig into some of the theories of management from Scientific management (Taylorism), TQM and Six Sigma. None of these worked particularly well for software development teams.
I had also read ‘The Mythical Man-Month’ which postulated that adding more human resources to a late software project will only make it later. That I believed as I has seen it happen lots of times. They also specified that communication was essential to reduce interpretation errors.
Around this time Agile development project started to arrive to displace cumbersome ‘Waterfall’ based builds. At this point I think software development had really found a structure that could deliver software better and quicker.
So what ?
This article is about management versus leadership so why does ‘Agile’ make any difference and why am I bringing it up. Well if I go back to that Office I mentioned previously and the management theories surrounding it at the time we can see some real differences between ‘managing’ an agile team and leading one.
However, before I get into that it might be useful to explain how a development team often sees how the business operates. Ideally they would like to get a clearly defined set of requirements from the business, an understanding of what it is for and what affects the timescales. What they normally see is more akin to the observations of Billy Connelly.
‘We want this! And that! We demand a share in that, and most of that, some of this, and f**king all of that! Less of that, and more of this, and f**king plenty of this! And another thing, we want it now! I want it yesterday, I want f**king more tomorrow, and the demands will all be changed then so f**king stay awake!’
Billy Connelly
This is actually the state of most software projects as the fields move so fast and the competition is so fierce. The net result is often a complex, poorly defined, mission critical set of requirements. Therefore, what the development team requires most is a feeling that ‘we are all in this together‘. In fact, more than that, they would like to say ‘trust us, If we all stick together, we are the best , we will deliver !‘. And then do exactly that.
So what the development team needs is a leader who trusts them and can be trusted. They will keep them informed about everything that is happening. That means they will tell them about the project, the companies strategy, what the marketing team are doing, what the customer is saying, what the financial position is, why what they are being asked to do is important, what matters. They will also spend time with the team to work out what is impeding them. They will try to remove any roadblocks. They will in fact report to the team, not the other way around.
They will understand that leadership is more of a responsibility to the team than a statement of rank. They will praise the team when they can, will criticise them when it is required (but never in public).
They will not only ask what they can do to help, they will actually do things that help the team. They will ask the team for their ideas on how to solve a problem and offer their own suggestions. In the longer run the whole business should strive towards Agile Management but I cover that in another paper .
On the other hand ‘managers’ will probably approach this in a different way. Firstly, they will mistakenly think that they are the ‘Boss’ and ask for a plan. They will establish a hierarchy and ask the team to report to them regularly. They will bake the plan into some kind of tracking mechanism, ask the team to estimate how long it will take and start to monitor progress.
Whilst this looks OK on the surface, and quite a lot of this would also be present in a leadership situation, they will tend towards a more ‘scientific management’ approach to track the project.
They may be inclined to use a communications product like Jira and they may also be inclined to use story points as an estimate of work required.
Story points were defined to give some measure of task complexity but now they tend to get misused by management as time estimates. I’m going to write a whole other article about why story points are bad but for now let’s just leave it as a measurement method. Effectively they will now use burn up/down graphs based on story points to manage the project.
Now we have a sizeable gap between the management and the team they are managing. With story points at least, they will have gone back to 1920 and have become Taylorist’s.
This means there is a real possibility of there now being a ‘them and us‘ situation. One, where the team probably wont trust the manager and will obfuscate and extend estimates to give themselves some kind of headroom if the project tracked late.
They will probably care more about their salary and stay on the bottom layers of Maslow’s Hierarchy rather than heading for esteem and above. To cut it short, you will never get the best out of your team if you focus on measurement rather than belonging.
It’s more about psychology than arithmetic.
Thats what I think is fundamentally different between managers and leaders.