As an on-again-off-again software development manager, I have asked this question of myself on more than one occasion..what *are* managers good for anyway?
It’s a great question – and the answer is not entirely intuitive.
Software development managers, and the expectations about their duties have been modeled after earlier times, and different types of work. The measure of the success of a manager is often directly tied to the software within the purview of the team that is managed. Which, even, from the title of the role seems like a patently obvious way to do things. After all – software and manager are both in there – so it seems like the thing one manages should be the thing one is measured by.
But take a second look even at the title – software development manager – what is it that is being managed? Software? No – software development. And while software isn’t a bad proxy to measure to find the potency of our software development, it can often be a misleading one.
The reason for this is due to the nature of software. Recognized and memorialized by the Scrum framework, the duty of organizing and defining the nature of the software to be developed is vested in a member of the development team known as the Product Owner. This role is envisioned as a partner with the other members of the team and not one that controls the specific actions of the team. One that collaborates to find the proper priority of software features to be developed, but leaves specific action to be defined by the team itself.
The “what” question is separated from the “how” question. And both are meant to be collaborations on a team consisting of both types of roles.
Where is management? Where is leadership? The traditionalist that takes their cues from car factories and construction sites might say that someone, somewhere has abdicated their responsibility. We should fire whomever it was, and find someone that can do their job. And by the way – this Agile stuff only works in textbooks.
They’d, of course, be wrong.
If we’re looking closely – there’s a huge need for leadership in this situation. It’s just not with the first-order concerns of the specific software output. It’s with the second-order concerns of the system that the software is being built by. The software development manager – should be managing the development of software – setting up the systems and practices, hiring the right kind of people, and ensuring the cleanest code. Then, they’ll be managing software development, and then the software will practically write itself.
But let’s put this magic aside for a sec, and take a quick step back.
Let’s parse out management and leadership here for a second. Because the difference starts to make a difference.
When we talk about management, we talk about ticking HR checkboxes. For starters, in most organizations, we can’t very well have everyone reporting to the CEO. Training, timesheets, whatever regulatory things that need to be “managed” – that’s the job of the manager. With this comes a certain degree of leverage. This isn’t bad, but it is interesting as we will see in a little bit.
Leadership is about change. If an individual’s or an organization’s inertia will carry them through to whatever thing it is that they want to accomplish, leadership is unnecessary. It’s very similar to physics – acceleration is defined as changing velocity, which is a two-part vector that includes both direction and speed. If either of those change, you’ve accelerated – and more importantly, a force has acted upon you. Leadership is that force – whether applied by someone else, or by yourself – if your velocity – your speed or direction or both – if they change, leadership has been applied to your situation.
I won’t cover the various ways that this force can be applied, or the tools used to generate it. But it is sufficient to say that the organizational leverage that a manager might wield is one of the most obvious though least powerful methods.
So management for a leader is a tool to the end of changing momentum.
Software is an interesting beast, if I hadn’t been clear enough about it earlier. And it is so for several reasons.
Firstly, if left alone there is a natural drag that will decelerate its delivery until it stops entirely. That’s right – if nothing is done to push back against this natural force, an organization that starts to deliver software, given a certain amount of time, will be unable to continue.
Secondly, the problem solving capability of the software team is embodied in the knowledge of the individual team members and in the communication networks within the team. Unless the team is very weak or severely restricted, no single individual would be able to hold enough information to make a better, quicker decision than the team itself.
Following from this second situation, it’s important to recognize that direct manipulation of the team – ordering a specific action – will lead to a reorganization of the team’s collective understanding. It will also create a sense of dependence on the one giving the order — since blindly following a directive is easier, quicker to execute, and necessitates a lower level of responsibility for the results – all of which are pleasant in the short-term.
So hopefully the hole that the software leader can and should fill is becoming obvious. But to pull all of this together…
Our challenge is basically, as a software development manager, what do we do when output isn’t reaching potential.
The answer is that we have two options – the path most taken would be to exercise direct manipulation of the team. That is – we might give specific commands about how to deliver…break out the carrot and the stick, threaten, entice – go directly for the output and work back to specific actions that can get that for you.
This is problematic because it makes the system worse, as we said above, it necessitates a reorganization of the team to accommodate the adhoc input (which will be less optimal than it was prior to the command) and it creates dependency. Both of these make “software development” – the thing we are managing – the system that delivers the software, worse. Which means, next time you will be delivering less well.
The second option is to work on the system itself to make it better.
What is the system? It is all the things that go in to creating software, from hiring the team, to the workflow the team uses to create the software to the delivery methodologies the team has for putting software into production. It includes paring and mobbing, TDD and the taste your team members have to create modular, well-crafted software that’s a snap to understand and change. And probably more that I’ve forgotten to mention.
So – you focus on the system and the next time around your output is better. The only challenge is having the character to not stress out and react incorrectly and too quickly to the pain of disappointed expectations (whether or not they were in any way realistic).
Fantastic – so that’s a win. But it sounds like a one time thing. That’s not exactly a full-time job for a software development manager.
Right – except the whole thing was predicated on the challenge that “the output didn’t meet the potential”. Which, as much as this may hurt to hear, will in fact always be the case. Further, as we said above, software development is funny because it rots – the system itself that is. It becomes slower over time. So even to maintain the momentum we have currently, requires a “force”, requires leadership to overcome.
So – even something as boring as maintaining the status quo in software requires leadership. Certainly to make headway and to become a truly great example of software delivery won’t happen under anything less than heroic exertions by a gallant generation of brilliant software leaders and the brave souls that follow them.
Let’s be them!