What is a Software Manager?

Most large software programmes will employ a software manager and a software architect.  It is wrong to assume that these roles are anything but wholly interdependent.  In fact it is foolhardy to believe that you can be a manager without being an architect or an architect without being a manager.  How can a manager define work packages, estimate development costs or plan a development schedule without understanding how the pieces fit together?  How can an architect design a solution without understanding the constraints of time, budget and human resources?  In fact, in my experience, the success of software development programme relies on a strong relationship between manager and architect, to the extent that they are largely interchangeable.  You must never rely on one person with all the answers.  When your manager’s on leave who’s going to keep the team in check?  When the architect is offsite who’s going to answer design queries?  Maybe against the perceived wisdom of organisation hierarchies, I have found that running a programme with two people at the top of roughly equal seniority, and largely overlapping responsibilities, produces the most effective results.  Personally, I need someone to bounce ideas off and to validate (or rubbish) my decisions.  Some people (like all the contestants on The Apprentice), will see this as weak leadership.  But seeing this as a weakness is a weakness in itself, because being responsive to other people's views is a fundamental strength of a good leader.

On the last three major programmes I have worked on, there has been a natural manager/architect pairing, and it worked extremely well in all cases.  In this regard it's worth considering the parallels that can be drawn with the practice of Pair Programming and the flat management structure suggested by the agile development method, Extreme Programming, and the benefits thereof.  Of course, you don't have to set up your structure like this to be successful, and indeed the size of your team may only warrant one person to perform both roles.  But for anyone who argues that pair leadership can never work then just consider Page/Brin or Gates/Allen.  They did okay.

Turning more specifically to the role of the Software Manager - this will change over the lifecycle of a programme as depicted in the graph below (very roughly).

There are a few things to note.  Firstly, yes, you will be overloaded at the start of the programme.  There is virtually nothing you can do about it - there are just so many things to get started that you will need a hand in.  But if you get those first couple of months right then you will afford yourself time to put your feet up at the end.  (Of course, this is when senior management will start calling on your time for other programmes, so keep your head down).

The second point to note is that if you are the kind of software manager who knows his/her stuff then you will spend much of your effort – say up to 80% – in the early phase involved in the architectural design.  During this phase the team size will be small – architects and team leads.  Coordination of them should be minimal but you must get involved in as many design discussions as possible.  Remember, if you are going to be held accountable for the development of this system, you sure as hell should want to be involved in major architectural aspects of its design.

Towards the end of the programme you will mostly be just keeping developers in check, tracking work packages and allocating bugs to be fixed.  But don’t believe for a minute that you won’t be involved in architectural decisions right up to the end.  During system integration and testing things will crop up that no one ever thought about that you will have to make a decision on in quick time.  So you must have the system in your head.

The intention for this blog is to be more about the What than the How.  About what to do when and not how to do it.  But as it is about software managers it will encroach more into the how for the managerial aspects than the architectural.  That is, it may go into some detail regarding how to perform a work-package estimation but not how to do UML modelling.  (Lots has been written on the latter already).

What to do in week one will follow in future posts, but the point to take away now is: just because you have the word 'manager' in your title do not think you can distance yourself from the architecture.