Management Isn't What You Think It Is
Management isn't what you think it is. Allan shows you what management work is, and why you need to pay attention to it.
Join the DZone community and get the full member experience.Join For Free
Continuing my discussion of management, broadly speaking my argument is:
There is management work to do — the same as there is coding, testing, and customer relations. 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
- 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 hubs?
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, and 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.), the information hub is redundant. After all, messages can be communicated nearly instantly to everyone. But this cuts both ways. If messages 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 with, and quite possibly expanding, the new world.
Some would even suggest that to 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! This is just a selection of the type of work I would expect to see managers doing.
What all these things have in common is that 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. Doing much of this work would move from the management space into the engineering space and maybe 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. 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 and 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 for another blog.
Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.