Continuing my discuss of management, broadly speaking my argument is:
There is management work to do – the same as there is coding, testing and customer understanding. To pretend there isn’t such work to do, that all software development might be reduced to rational engineering is naive.
Much of management work may be administration, we might be able reduce the amount of work, we might be able to delegate it or disperse it but there is still a rump of work to do.
A lot of management work involves decision making, and a lot of those decisions require authority.
So what is this work?
Here are some examples which I think are legitimate, possibly intrinsically, management work:
- Managing the client-supplier relationship: whether you sell your software product directly to customers or not your company will have suppliers (paper-clip vendors maybe) and customers/clients (well I hope you do, a few companies may have none but that is another problem).
- Managing expectations of stakeholders (with BAs, POs, etc.)
- Coaching staff
- Governance of work
- Information hub and firewall: information aggregation, filtering, dissemination
- Organizational structure: creating the environment for success
- Dealing with higher authority: for negotiation, for leveraging (unblocking)
- Finances: even in companies which have gone beyond-budgets there are still finances to “manage”, if anything a beyond-budgets approach will increase the amount of attention paid to finances
- and various administration issues
You do NOT have to have “manager” in your title to deal with these issues, these are examples of management work. You are a “manager” then you are more likely to deal with them – you might even attract such work.
This is not an exhaustive list — how can it be? – feel free to expand the list in the comments section below!
Some of these might be not be agreed by everyone. For example: should managers be information hub?
I’ve spoken to many developers who complain that their managers don’t tell them the full story, they selectively filter information, perhaps to retain their own power. But I’ve spoken to many, probably just as many, developers, who complain that their managers tell them too much, call them to pointless meetings to hear pointless messages.
And there are many who would argue that with modern technology (e-mail, mobile phones, etc.) that the information hub is redundant, after all messages can be communicated nearly instantly to everyone. But this cuts both ways. If message can be communicated instantly at very low cost it may well lead to more pointless messages and information overload.
So before anyone complains that they are not being told enough please check your mailbox, and mail filters, and ensure that you are not receiving too much communication.
Some of these items may be a sign of organizations in transitions from one organization style (maybe called traditional, top-down or hierarchical) to another (maybe called agile, self-organized, or holacracy). Such transitions don’t happen instantly or just because the CEO says “Lets be a holacracy”. And some organizations might simply want a little bit of “agile” in the software development teams in the basement but they don’t want self-organization anywhere else.
In any of these cases there will be management work dealing with the old-world and interfacing it to the new, and quite possibly expanding the new-world.
Some would even suggest that bring about such changes is itself management work and I don’t think I’d disagree.
Few managers will do all of the things I have listed and even fewer should do all these things! These are just a selection of the type of work I would expect to see managers doing.
What all these things have in common is they are nebulous, they deal with unknowns and unknown unknowns, they require working with incomplete information and they require a degree of intuition, some a little some a lot.
If these things weren’t ambiguous and nebulous then they could be formulated as a set of rational decisions, with known inputs and knowable options – as I described last time, lots of management work is about the fuzzy world out there. In so doing much of this work would move from the management space into the engineering space and might even, one day, be automated.
As time goes by we are finding ways to reformulate some of these issues so they can be tackled by engineers. And we are finding ways to reduce the ambiguity – the test driven techniques in Lean Startup are great examples.
Big data is another tool we are using to move decisions from the ambiguous space to the engineering/rational space. But, big data has a soft underbelly.
While this work rests in the ambiguous space then intuition is required to make decisions.
Keen eyed readers will have noted two omissions from the list and the discussion which followed. One I’ve ducked before: Leadership, the question of management leadership deserves a blog all of its own.
The second also deserves a blog all of its own: strategy. Many people have argued that one of the primary roles of management is to provide strategy, I’m not so sure. The full discussion will need to wait another blog.
| Reference: | What is management work? from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog. |
