Management work: Strategy and Planning?

In my list of management work last week I left what some people will think of as a major omission: strategy and planning.

There is a school of thought that says that managers spend, or at least should spend, a lot of their time engaged in thinking big thoughts, having big discussions, creating company and product strategy. Sure thats why they need those big offices? Where else can they think deep and plan?

This school of thought would acknowledge that not all managers create strategy but since all managers think big thoughts those that don’t spend their time creating strategy are planning. Specifically they are planning how to implement the strategy set by more senior managers who do set strategy.

And since managers spend so much time planning they must also spend a lot of time communicating those plans - communicating downward that is. How else can you roll-out a strategy? How else do you implement a plan?

This school of thought is particularly powerful with people who aspire to be managers, people who want to be managers so they can think big thoughts, so they can step back and play a small part in the running of the world. Those who are fans of Michael Porter’s work on Strategy often subscribe, Porter sees strategy as conscious, inherently a top-down activity.

For those who hold this view is also follows that managers need authority: authority to decide the strategy, authority to tell others the strategy, authority to plan and authority to tell others to implement the plan they just made.

So why did I omit this important, and time consuming, aspect of management work?

I omitted it because this view of management is fantasy. It doesn’t exist.

Managers don’t spend their time planning and even fewer spend their time strategising. Sure many managers say they want to do this but very few ever find time. Thats why they feel compelled to create “offsite days” to plan and create strategy because day to day they are caught up in firefighting.

If you don’t believe me do and read the work of Henry Mintzberg, specifically read his book Managing, or the short version of the same book, Simply Managing. In these books he details his findings from following actual managers around and looking at what they do. He find they do very little planning and strategy.

Which is hardly surprising because in his earlier book Mintzberg demolished the idea of strategic planning: The Rise and Fall of Strategic Planning.

For software developers the story this book tells is oddly familiar, it starts with the idea that a strategic objective can be decided, that having decided the objective people (managers) can rationally decide what needs to be done to achieve the objective. They can then rationally allocate resources. The resources can then move them towards the objective. Sound familiar?

While Mintzberg agrees that organizations can have strategic objectives, and may even put in place plans to achieve them he shows that achieving the objectives is far from a rational planned activity. And, perhaps more important, strategy is not just a forward looking process (“We want to be the world leader in widgets!”) but an iterative process (“How can we increase our widget sales today?”) and backward looking, sense making (“Hay, our widgets are selling well, what did we do?”).

Most management work is far from planning and strategy creation. Most managers spend their days on administration, on working out problems, on applying their knowledge of a problem - a domain, solutions, history - to the problems they face today.

And if managers are spending their time engaged in strategy, planning and deep thinking then it follows that there is a lot less for them to communicate. And since the plans don’t exist there are no plans to deploy and no need for authority to order people implement plans.

Mintzberg also demolishes the idea that manager work hierarchically, that they need authority to do things. He shows how managers work without authority, they cut across hierarchy, and they work with their staff more than they direct their staff. Management is at least as much about persuasion as it is commanding.

Once you start to see managers as co-operative problem solvers they look much more like any other team member. Albeit one with some elevated status.

In fact, I’d go as far as to say: any manager who tries to work purely through authority is a) not going to be popular and b) find it hard to get things done.

Take away strategy formation, planning and roll-out from the work managers do and an awful lot of the power managers supposed have goes too.

In a software development teams an awful lot of this work can be push down to teams and the NCOs that work with the teams. Authority can be distributed to the people who closer to the problems, who need the authority.

Now perhaps it becomes easier to see managers as team members too.

It just so happens that their skills are a little different form other team members, their skills are more in administration, firefighting, working in ambiguous areas with limited knowledge and yes, to some degree organizing.

What is management work?

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.

Thoughts on the nature of management work

Returning to my Management, my mini-series of blog… (Non-Commissioned Managers, Analysts aren't managers and Managers who are not managers)

Lots of Agile advocates have a real downer on Management. I think (like myself) they dislike the authority conferred on “managers”. This may be dressed up as a rational dislike of top-down reasoning - and they have a point - but this also throws the baby out with the bath water.

Look, I dislike authority as much as the next person, actually, I probably dislike is a heck of a lot more than the next person, its probably one of the reasons I find it hard to stay in the same organization for a long period. But in order to reason about management work we need to divorce management work from authority and consider such work in its own right.

At its heart management work is administration. Thats why the most prominent management degree is not a “Management” degree, sure there are “business studies” for undergraduate degrees and Master of Management degrees but the most prominent management degree is actually an “Administration” masters degree.

To an engineer much of this administration looks pointless, or needless, or counter productive. An engineer looks at administration and sees a things which can be engineered away by a rational process with rational decisions by rational people.

But… Not all activities are rational.

Not all processes can be decomposed in an analytical fashion and rebuilt.

And since there are people in these “systems” rationality often goes out the window. What is rational to ME is not always rational to YOU.

Sure, as the knowledge in society increases, as engineers understanding increases, and as our computational power increases, more an more processes and activities can be examined rationally and subjected to rational, engineered, solutions but the devil is in the detail.

During the late 1980s and into the 1990s the Business Process Reengineering movement thought it could reengineer businesses along rational, engineering lines. It was an abysmal failure. Yet remnants of this movement still exist, perhaps most clearly seen in the ERP and CRM space.

The problem is: the world is messy.

More specifically, people are messy.

A lot of what we call “management” is about interfacing the messy world to the rational engineering world. But even the rational world isn’t what we think it is. The rise of the behavioural economics has done much to debunk economists faith in homo economicus.

For me management work sits at that point where the logical world meets the fuzzy world, where binary meets analogue, where Turning machines meet non-deterministic processes, and where homo economicus and Robert Lucas meet homo reciprocans and friends The Undercover Economist, Gerd Gigerenzer, Kahneman and Tversky, Mullainathan and Shafir and a bunch utility-deniers.

“Managers” aren’t the only people in this space. By the way, Business Analysts and Product Managers inhabit the same space but their aims are different. All these roles work to make the messy, fuzzy, emotional and irrational world interpolate with the logical, rational, emotionless world of machines and deterministic processes.

Perhaps more interestingly Scrum Masters and Agile Coaches operate in this space too, that’s why I consider them managers, or at least non-commissioned managers.

I pushed authority to one side before. Many coaches and Scrum Masters - as originally defined but not always implemented - deliberately leave authority at the door. They attempt to fill a management like role but without using authority.

In some ways this is good, it brings a different approach, sometimes better but sometimes worse.

Personally I learnt a lot of my management philosophy in similar position: Branch secretary of a political party. I had very little authority - its a community of volunteers, while I did control much of the administration I could also be ordered about by the massed ranks of comrades.

And there in lies the point.

In many environments those who control the levers of administration have power, and conversely, some leavers of administration require authority to be used properly. There is some work which can be done by manipulating administration (no authority needed) but there is some work which requires authority to control administration.

Administration may decay into bureaucracy, and we all dislike bureaucracy don’t we? Except some bureaucracy may be necessary to smooth running of organizations. I recently came across this quote:

"One person’s bureaucracy is another’s empowerment." Andrew Mullinger, co-founder Funding Circle

Authority, administration, bureaucracy and management aren’t automatically bad, a little of each might be helpful to smooth operations but take too far they can be counter productive.

Now depending on the organization in question - the culture, the systems, the history - exercising administration may require more or less authority, ultimately it is not possible to administer without authority, so administration begets authority. It becomes difficult to disentangle administration from authority.

Notice I’ve said nothing about Leadership here, that is another - but related - topic.

Agile Project Manager/Scrum Master - Wrong, so, so wrong

I shouldn’t do this, it raises my blood pressure, I have better things to do, I have better things to blog about but I can’t help myself….

I made the mistake of opening a mail from a recruitment agent, the title: “Agile Project Manager/Scrum Master”, let me dissect it for you…

“My client based in the West Midlands are looking for an Agile Project Manager/Scrum Master for a long term project opportunity starting in May.”

Agile Project Manager/Scrum Master? - this is a pretty confused role, it is one thing or another, its one thing for a good project manager to act as a facilitator or for a Scrum Master to take on project responsibilities but to start out like this, well is just messed up.

Long term project? - there is no such thing, projects are temporary!

“The successful Agile Project Manager will be responsible for the planning, organising and managing of IT projects within this matrix resource environment. My client is looking for a technical Project Manager with strong experience in leading and managing multiple complex projects in agile environments. To be suitable you MUST have strong process and project management skills with experience in SCRUM.”

Planning, organising and managing of IT projects…? - what happened to self-organizing, empirical control?

And note “projects” not project (as it was before). Multiple project is a bad sign.

Matrix resource environment? - Matrix management, this organization has shot itself in the foot already.

Technical Project Manager? - so this person is a Scrum Master, a Project Manager and Technical, do they also make the tea and wash up?

And why all the SHOUTING? - Scrum is spelt Scrum, as in Rugby, it is not S.C.R.U.M. or SCRUM.

“As the Agile Project Manager/Agile Coach you will have ownership of the full life cycle project process, including the Software development lifecycle.”

Coach too? - as well as a Scrum Master, Project Manager and Technical? I’m not even complaining about the use of Agile and Scrum as if they a synonymous.

Ownership of the full life cycle… including the software development lifecycle, really? - except for the fact that the contract is for 6 months, the company is matrix managed, there are multiple projects and that some bastard hotchpotch process of SCRUM and traditional project management has been mandated.

In other words: you have as much ownership as a homeowner who’s house has just been repossessed by the bank.

Anyone taking this job would have their hands ties behind their back on day one.

“Key requirements:

• Demonstrable experience managing complex Projects in fully Agile environments
• SCRUM Master with previous experience of running Agile project teams
• Excellent presentation skills & competence in project management tools
• Full life cycle delivery experience
• Ensure all SCRUM ceremonies are adhered to throughout project lifecycle
• Collaborate with project teams (both on and offshore), create and maintain project plans and schedules”

Fully Agile environments don’t have projects, Scrum Masters don’t run Agile teams and “maintain project plans and schedules” sounds distinctly Gantt chart-ish.

Saying “all SCRUM ceremonies” sounds like the people doing the asking don’t actually know what the ceremonies are, just they must be “adhered to”. Anyway, Scrum isn’t a full lifecycle model so good luck here!

What is interesting here is what is not said:

• No mention of facilitation, unblocking, coaching
• No mention of technical skills (TDD, ATDD, BDD, refectoring, etc); this is supposed to be a “technical project manager”
• No mention of empirical process control or forecasting
• No mention of value
• No mention of prioritisation
• No mention of the Product Owner/BA/Product Manager

Normally I would be pleased that the recruiter wasn’t asking for a Scrum Master Certification, a Prince 2 certificate, or, heaven forbid, a “Agile Project Manager” qualification but on this occasion I read it more as a sign that the company doing the recruiting don’t actually know what they want.

Similarly, no mention of tools or technologies - Agile in PHP is very different Agile in embedded C, let alone the ERP Agile I’m working on now.

Finally,

“If you are interested to find out more, please reply…”

Should read:

If you are a traditional project manager (who used to code in the dim and distant past) but can’t get work now the world has gone agile, but think you know what agile is (mini-waterfalls) then please give me a ring, you probably know more than the people doing the interviewing anyway.

Bottom line:

1. Unfortunately this is the state of our industry, it is what many organization do and want. But it is far far from what the best teams do.
2. Don’t blame the recruiter, their industry is based on failure, most recruitment agents are failed real estate agents.
3. The organization requesting this role have such a poor understanding of what they need they shouldn’t actually be allowed to hire anyone.