Monday, June 27, 2016

Servants, not leaders, not managers

Sharp eyed readers of my management mini-series will have noticed I referred to managers doing administration several times, Peter Hilton mailed me to ask me more about this. Let me image such a manager, let me imagine the worst possible scenario…

This manager spends a lot of time involved in admin. Finance forms a lot of this, juggling a budget, allocating “resources” (people to you and me), calculating totals, staying within limits. Some of this is straight admin, it could be done by anyone semi-competent with spreadsheet but some of this work demands knowledge of what the organization is trying to do and, importantly it demands authority. Would you like your team composition to be determined by a finance clerk?

While the manipulation of the spreadsheet could be done by a finance clerk the result would not have the same authority. At the very least the clerk would to work under the direction of someone with authority.

Some of the work requires authority too because the organization has put a number of checks in place which require authority to overcome. Purchase orders need to be raised, but to raise them statement of works need to be raised, and once raised these artefacts require authority to approve them. The approval authority rests several steps up the management chain but it is not possible to jump to the top, the higher levels only give authority when the lower levels have.

And sometimes the machine breaks down and someone needs to use chase, and sometimes chasing requires authority.

In fact it appears the more the organization has tried to streamline its internal processes the more authority is needed to make anything happen. A finance clerk breaking rules and pushing senior staff for authorization wouldn’t get far, they may even be viewed as a fraud problem.

This hypothetical manager spends a chunk of his day in discussing seating plans. Such work could be devolved to teams but why disturb busy programmers and testers with seating plans of little interest too them?

Such work could he given to an office administrator or a personal assistance (if he had one). But who would like their desk decided by a secretary?

And if you have several self-organizing teams who is going to resolve conflicts? Who is going to represent the teams when they need to ask for more space?

Our hypothetical manage spends a lot of time on the phone, to colleagues, some managers, some non-managers who require updates on what is happening. Not just about software progress but about budgets, seating, recruitment and all the rest. Yep anyone could answer the phone but again, who wants to be interrupted? And who wants to speak to the office secretary? How do you know the secretary has the most up to date information?

Sure in an ideal company there would be little or no hierarchy, people would happily ask questions of those with knowledge rather than those with status but you only need a few people who stand on status, on hierarchy, and it spreads. A Director expects to speak to a fellow Director not to an NCO team lead. And if the Director wants to know about several teams who does he call?

Many of those phone calls involve recruitment, in particular recruitment agents, resources, head hunters, call them what you will. Job descriptions go out, CVs (resumes) come in, even if this manager does review them (and he does some) who is going to communicate with the agents?

If you’ve ever tried to hire someone via recruitment agents you will know: these guys don’t let go. If they get a whisper that you are recruiting they will call you. Once you have a CV from them for a candidate they will call you day-and-night until they know whether you will interview them. And if you say No they will try and change your mind.

Sure good personnel, sorry human resources, staff can help, but a) very few IT staff trust HR, b) many HR people do not feel competent to hire IT staff and c) recruitment agents will find a way around HR staff if they possibly can, and they usually can. (If recruiters have the names of multiple people in the same office they will call them all until one gives the decision they want.)

Who wants to be interrupted by these people?

I could go on but my point is made.

Now an organization could seek to remove a lot of this work from such a manager. After all: you could have an office admin person, a finance specialist, a recruitment person, you could move a lot of this work to specialists, but…

In a small company this often doesn’t make sense. You don’t do enough recruitment to have a specialist, you don’t rejig the money often enough to have a clerk.

Sometimes these issues are interlocking: recruitment effects the budget, the budget effects office desk space and so on. There may be a logic to bringing it together.

Then there is the question of authority. If we delegate the office seating plan to an administrator and an Architect doesn’t like it will they go running to the Manager to have it changed? Or maybe they will talk to the Admin directly.

To complicate matters many companies have actually stripped out these supporting roles over the last 20 or 30 years. Secretaries are increasingly rare but they can be the oil that makes things work efficiently.

In stripping these people out they may have been replaced by machines executing business processes. That may be fine when things work but what when things don’t? Like in code exceptions don’t happen very often but they do take up a lot of energy and effort. In a corporation handling such an exception may also require authority.

Coincidentally I saw Mike Burrows talk the other night about Servant-Leaders. It occurs to me that we don’t actually need Servant-Leaders so much as we need a few more Servants, or rather, support staff to help things work efficiently: secretaries, office admin, finance clerks and recruitment people to name a few.

We need these people embedded with the teams were they can address issues first hand. Putting them offshore or outsourced to another company may make them cheaper by the hour but it will increase the number of hours that are needed.

Not all work can be delegated in this way but a lot of it can. If our hypothetical manager was supported by a good assistant a lot of the admin work could be lifted off his shoulders. This would then allow the manager to devote more time to the important things. In time such a change might even remove the need for a manager altogether.

Now I’ve seen teams with embedded support. A company I worked for in California had a development assistant. She was personal assistant to the whole team. If we needed stationary or a white board she’d get it, if we needed lunch brought in she did it, if we had a problem with expenses or accounts she’d have the first shot at addressing it, and so on.

Before we rush for more Servant-Leaders lets get a few more Servants.

Thursday, June 23, 2016

Management - a lesson from BHS

No sooner have I said I’m closing off my management mini-series than things come to light that need saying! Arrh well, I did say it wasn’t my last word on software management, i just didn’t to be revisiting the subject to soon.

The reason for this rapid revisit is the news from BHS, formerly known as British Home Stores, for those who don’t know it, BHS was for about 100 years a standard part of the UK high-street. Growing up we bought as much there as the better known, and more expensive, Marks & Spencer.

For those who don’t know the story (the BBC has lots) a sort introduction to the key points: Entrepreneur retail billionaire Philip Green owned BHS for over a decade (directly and indirectly) before selling it to a completely new venture, Retail Acquisitions Ltd. for £1. Well, BHS was in trouble (it missed e-retailing) and had big debts (largely in the pension plan.) Surprise surprise, the company collapsed leaving angry pensioners and politicians set about investigating.

The executives and owner of BHS were called in to answer questions. This is where my point really begins…

The BHS CEO told that inquiry that a few days before the collapse the new owner told him to transfer £1,500,000 to a Swedish company. The CEO complained saying the UK company needed the money. The Owner then threatened him, told him to stop making trouble and just do it.

To those outside of management discussions it can look really simple. The money is either needed in the UK or not. Managers and Owners are supposed to think alike, indeed all managers are supposed to speak with one voice. Management, and owners, are supposed to act both rationally and consistently.

It may come as a surprise to find that managers are flawed, managers, disagree and sometimes the managers and the owners have conflicts. Indeed, whole volumes of business literature is devoted to the “agency problem”: how to make sure managers do what is in the best interest of the owners and not what is in their own best interest.

Engineers often dismiss all this as “politics.” They assume there is a rational cause of action and if only all parties could work through a rational process everything would be alright.

But this just isn’t so.

Management is fuzzy

There are few, if any, solid rules in management. Even those that have the force of law can and do get broken - think Enron and Anderson Consulting.

Unlike programming there is no machine to pull you up short when you make a syntax error.

And the feedback looks can be long, real long. Decades.

So often management decisions come down to opinion. Sometimes it is the opinion of someone in authority, sometimes its the opinion of someone interpreting authority or someone trying (successfully) to influence authority.

To an engineer all this is ripe for re-engineering, replace these broken systems. However: just because you want management to always be rational it isn’t going to be so, no rational system can operate in such a fuzzy world.

Imposing rules isn’t going to help, they will just get broken.

Systems will get gamed.

This is not a problem with management, these are the problems management exists to address. Removing management does not remove all the problems - it might remove a few, it may also make them worse. If we remove all the management and give all the power to engineers they will wrestle with the same problems.

Tuesday, June 21, 2016

#NoProjects applies to bread machines too

#NoProjects continues to attract an increasing amount of attention. In fact the idea now has its own NoProjects website - many thanks to Evan Leybourn for that.

From time to time I get asked:

“Surely #NoProjects doesn’t apply to embedded software? After all, the software is installed, the device ships, end of story.”

Maybe, but as in other cases I would argue that the software only stops changing if the product is unsuccessful. If the product is successful one can expect the software to continue changing, sure the device that shipped with version 1.0 of the software might never receive a software update but if the device is successful there will be future devices in the same product line and they will most likely contain enhance software.

For example, one of my favourite kitchen devices is a Panasonic bread machine my wife bought me a about 7 years ago for my birthday. A few months ago we noticed the bread wasn’t coming out right, after a bit of investigation I diagnosed the motor was wearing out. A few days layer I was the owner of a brand new Panasonic bread machine and it was producing great bread again.

The new device shares many similarities to the old it replaced but also has some differences. In particular the user interface is very similar - although this one contains more bread programmes and a modified selection procedure.

Although I don’t know for sure I am happy to bet money that the software inside this one - and lets be honest, there really is a lot of software inside a bread machine - is a later version of the software in the earlier machine. Why wouldn’t it be?

Panasonic produces a range of bread machines, they change from time to time. Would it seriously rewrite from scratch the software each time?

Sure the software in my new bread machine will never change. The project to create the software for my current machine has ended but the software hasn’t. I have but one version that will not change but it is just one release of a living system, an evolving system.

And in seven years time when I need to replace this bread machine, what is the betting Panasonic will be selling Internet connected bread machines that they can update over the Internet of Things?

As the internet of things rolls out fewer and fewer devices will not be capable of update.

The internet of things will drive another nail in the projects coffin.

Wednesday, June 15, 2016

Some things can never be spoken

“Some things can never be spoken

Some things cannot be pronounced

That word does not exist in any language

It will never be uttered by a human mouth”

        Talking Heads, Give me back my name, Little Creates 1985

Some things shouldn’t be spoken. Some things shouldn’t be targeted, some things should be created as a side effect. In Life, the Universe and Everything Douglas Adams explains the secret of flying:

“The Guide says there is an art to flying", said Ford, "or rather a knack. The knack lies in learning how to throw yourself at the ground and miss.”

Throwing yourself at the ground and missing.

Its important not to try to try:

“One problem is that you have to miss the ground accidentally. It's no good deliberately intending to miss the ground because you won’t.”

In business, in software development, there are similar problems. There are some things we should try to hard to achieve. There are some things we shouldn’t speak.

We may want to achieve these things but they should be side effects of something else. Usually the thing we want to achieve is important but to set out to achieve it has nasty side effects. The solution is to do something else which has the nice side effect of creating the thing you want.

Got it?

Following me so far?

Think of it as an anti-dote for Goodhart’s Law: "When a measure becomes a target, it ceases to be a good measure."

Lets try some examples.

Profit is something that shouldn’t be aimed for. Its easy to increase profit, just fiddle the accounting rules, ask Enron, WorldCom (classify expenditure as capital investment) or Lehman Brothers.

Its even easy to reduce costs, just reduce travel allowances, freeze wages.

Another easy way is just to fire people. You will instantly reduce costs - redundancy payments can be made to disappear under “exceptional” items in the accounts - and it will be months if not years before the negative effects cut in.

Its often easy to increase sales: reduce price.

But all of these things will have a counter effect, maybe not today, maybe not tomorrow, or next week but sooner or later. People will become demoralised, people will communicate less, people will leave the company, customers will get dissatisfied and your auditors might catch you out.

The secret to making lots of profit is to not try. Try instead to make for a positive work environment, make your employees happy. Better still try and make your customers happy, make your customers lives better. Do the right thing by your customers and employees and you should expect profit to follow.

And if delivering profit means doing the wrong thing by your customers and employees then ask yourself: should we be in this business? Is this business sustainable?

Its not only profit.

Take another one popular with executives: Culture.

Company Culture is most definitely one of these things. Don’t set out to create a culture. Set out to create the kind of company you want and in the process you will create the right culture. But abstract this to a culture and you have failed.

Who gets up in the morning to go and work in a culture?

Who, for that matter, gets up in the morning and says “Gee, today I’m going to make the company another $10,000”? (OK, sales folk do.)

Rather than set out to create a culture set out to create something else: create a passion for delivery, a fervour for innovation, a zest for pleasing customers.

Don’t call it culture and don’t set out to create a culture which is passionate about delivery. Do the thing itself and the culture will follow.

Communities of Practice, CoPs, is another one.

CoPs periodically become fashionable, I’ve founded and run a few CoPs in my time and I’ve studied, them, heck I think I even wrote about them in Changing Software Development. But… whenever I’ve seen someone set out to create a community of practice they fail.

The trick is not to call it a CoP. Call it a group, a study group, a tech group, a community, just about anything but a community of practice. A community of practice is semi-academic term to describe an observed phenomenon. Decide one what you really want not an abstract idea.

In fact, teamwork, is probably be another of these things. Don’t set out to create good teamwork. Set out to make your team better at what they do.

Create a purpose to your work not teamwork, not culture and not profit.

Servant-Leadership is most definitely another - talk about it in your Manager Anonymous sessions but don’t use it in the office. I know one company where the Project managers got very confused when they were told they were now Servant-Leaders.

Don’t tell people you are now a Servant-Leader. Change your behaviour, become the servant leader you wish to be. It will take the team time to notice the change but it will take you time to change. Simply announcing you are now a Servant-Leader will not make it happen, it will only confuse people - and perhaps make you look arrogant.

My own #NoProjects is another. As Joshua Arnold said recently: The first rule of #NoProjects is don’t talk about #NoProjects. The corollary is: don’t talk about Projects. Don’t talk about them. Talk instead about product, talk about teams, or stream teams, or amoeba teams. Just don’t talk about No Projects.

This isn’t an exhaustive list, these are just things I’ve noticed again and again, I’ve seen others - and I hope you will too.

Think, if you like, of these things as attributes - teamwork, culture, profit, community - or better still qualities, qualities that should remain nameless, naming them kills them. The trick to all of them is not to try too hard, focus on something else, focus on something more concrete and let the abstract notion follow.

Qualities without a name.

Monday, June 13, 2016

Management - what are we left with?

Over the last four months I have written a dozen blogs concerning management of software development. I will write more, but I’d also like to draw a line under this mini-series for now - there are other things I want to blog about.

Management in and of software development is an important topic, simply abolishing it is simplistic. Although as I said earlier: sometimes the management is so bad getting rid of it is an improvement.

Right now I’d like pull together some of the key arguments I have made in this mini-series. And I’d like to start with the words of Fred Brooks:

“the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take.” Brooks, Mythical Man Month, 1995.

Perhaps the key argument I'm trying to make in this series is: There is “management” work to do - the same as there is coding, testing and customer understanding.

Such work is legitimate, just because it isn’t coding, testing or requirements analysis/gathering doesn’t make it irrelevant or trivial. Manager-less teams might well reduce the amount of work (which is good) or might redistribute but there is always a some to do.

A lot, if not most of this work involves decision making. Such decision making usually requires authority and may require making decisions with less than perfect information. Sometimes the missing information is unknowable, or is only knowable at a prohibitive costs (which might be time, money or something else.)

Consequently doing management work requires skills of its own, but even more than skills it requires intuition. So it takes an engineer to manage engineering, non-engineers managing engineering work usually lack intuition in engineering decisions.

Once you recognise managing as a skill in its own right the question then becomes: is it better to spread the work around (in which case everyone needs time and skills to do the managing) or centralise it in one place?

Other things to consider are:

Wednesday, June 08, 2016

Advice for conference submissions (Agile on the Beach feedback)

For Agile on the Beach 2016 we had over 240 submissions. Thank you to everyone who submitted, I’m sorry we could have so few of you - 41 sessions if I remember correctly.

I find sending the “Sorry you weren’t accepted” mails the hardest part of organising Agile on the Beach. That is especially true when I know the speaker personally, or I want the topic, or I’ve seen the talk before and think it would be great. But in the end I only have the same voting power as the other five committee members.

And in the end, knowing that the decision on who to accept, and who not to, was not mine alone helps me get through the “Sorries.”

Each year I tell potential speakers: “If you would like feedback on why your session was not accepted please email me, I can’t promise detail feedback, or promise to do it promptly but I’ll do my best.”

After all Agile is about Feedback so why wouldn’t we do this?

Well, its a lot of work - about five hours I think. Because its a lot of work this year it has taken me nearly three months to find the time to do it but I have just sent the last feedback. Sometimes there isn’t much I can tell potential speakers, reviewers can add comments with their score but they don’t have to.

(If you submitted something to Agile on the Beach 2016 and I’ve missed your request, or only know decided you would like feedback then please e-mail me.)

Many of the reasons why sessions didn’t score highly crop up again and again so I thought it would be worth capturing them here in a blog. For anyone thinking of submitting to Agile on the Beach 2017, or another conference, these reasons might be useful.

By the way, I have another blog post about the Agile on the Beach voting process which should be read together with this one - or better still, before this one!

So, the common themes in the feedback I’m giving submitters are:

  1. A lot of session were simply out competed: reviewers liked them but they liked other sessions more.
  2. Some synopsis were to short, light on detail, little to engage the audience - and certainly the reviewer.
  3. Some synopsis were too long, too much detail - indeed I remember some that went on and on. Clearly there is an art to getting something long enough to give detail but not so long the reader gets fed up reading it. (Remember reviewers may have 240 of these to read.)
  4. Multiple submissions by one person is a high-risk strategy. If you are Adrian Howard or Seb Rose this is a high reward strategy, both of these speakers have in the past submitted strong proposals and the committee is left agonising about which one, or perhaps two, of the submissions we will have. Seb and Adrian changed the debate. But for most submitters reviewers notice multiple submissions and actively score one higher than the other. Unfortunately if another reviewer makes the opposite choice multiple submissions effectively split the speakers vote. So it is better to limit your number of submissions and play to your strengths.
  5. Multiple submissions of the same synopsis with different travel expense expectations or co-speakers really annoyed the reviewers. For example, a couple of people submitted a talk with expenses set to “Worldwide” i.e. a long haul flight, and then submitted the same with “Local” or “Will pay my own long haul.” Reviewers felt these people were trying to game the system and marked them down.
  6. Indeed, Worldwide travel, long-haul flights, always presents us with a problem because such speakers are more expensive for us. We can usually find the money for one or two such speakers but thats the limit. This year we provided the option for speakers who were prepared to pay their own long-haul flights and we have a couple of speakers doing this. While I accept this might not be fare it is hard to see how we can be completely fare given our economics.
  7. Paid speakers: we don’t pay speaker for Agile on the Beach. We pay travel expenses but not speaking fees. If you are looking for a fee then please don’t submit.
  8. Keynotes: we don’t do an open call for keynotes. We select the keynotes and invite them before we even open the call for papers usually.
  9. Double sessions need to be twice as good: accepting a double displaces two single sessions which means we need to be convinced. Despite making extra space for doubles this feels like an inevitable problem because it is about timing. It isn’t really fair - some topics genuinely deserve more time, especially if they are interactive. Perhaps the best advice is: only submit a double if you have been the to conference before and committee members are likely to remember you as a good speaker. Giving a double to an unknown speaker is a big risk.
  10. This year we had what seemed like a lot of submissions along the lines of “What Hiking taught me about Agile” or “Why paragliding is like software development.” While these are interesting metaphors none of the scored highly. In general I think such metaphors only work if the field is well know. And this year I for one got a bit fed up of reading yet another “Lessons from arctic exploration for Agilistas.”
  11. ThoughtWorks: this is one of those “nice to have” problems but still a problem. We have a great relationship with ThoughtWorks - largely thanks to Jim Barritt and James Lewis who put us on the TW map and encourage a lot of TW people to attend. So we get a lot of strong proposals from Thought-Workers - after all TW only hire the best so we don’t get weak proposals from them. In 2015 we could have populated entire tracks with only TW consultants. They would be strong tracks but we don’t think that is good for conference variety. As a result submissions from TW consultants have to compete against each other in addition to competing with everyone else. Sorry guys.

By the way, we don’t do anonymous submissions, we, certainly myself, tend to believe the speaker, their background, name and experience is important. If we have been fortunate (or unfortunate) enough to see someone speak at a conference we take that into account. We also know there are many speakers we like to see return - and one or two who we don’t want to see again!

We have in the past been criticised for not including enough variety in our speakers, specifically: having too many men. Perhaps one reason for doing anonymous submissions would be to guard against this but actually, we don’t see this our problem. Or rather: yes we would like a better gender balance but when we’ve looked at the male/female ratio of other - comparable - conferences we’ve found we our balance is better than most. That is not a reason to rest on our laurels but it does imply its not a problem to us specifically.

Monday, June 06, 2016

Managers as information hubs

One of the arguments that is made for manager-less teams runs something like this:

“Managers were useful when they were information hubs, when they heard company information, policy, direction, etc. and cascaded it down to their staff.

But in a world with e-mail, web, slack and a myriad of information systems there is no need for the role. Information can be directly communicated via modern tools to staff.”

This doesn’t actually hold up when you examine it:

  1. Modern tools might allow mass communication but they also allow mass interruption. To communicate everything to everyone increases the information processing load on everyone. True, the information may be public but this has the cost of demanding everyone reads it.
  2. Much information does not need communicating to everyone, to communicate it to everyone interrupts everyone.
  3. Communicating a common message to everyone means that context is lost; information requires interpretation within local environment.
  4. Without a common, shared, understanding of information then each individual can interpret the same information differently within their context. Remember: the meaning of any message is decided by the reader, not the writer.
  5. Because modern tools lower the barriers - specifically cost - of communicating to many people more communication happens, but this increases the cost of receiving information because more people read the information and have to interpret it.

I could go on but you get the picture.

Let me suggest, that rather than removing the need for information hubs modern tools actually increase the need for information hubs. Far better for one person to read all the information, interpret it and pass on the useful stuff - within a context and perhaps in a timely but not disrupting fashion - than for everyone to undertake the same work and pay the price.

Such an information hub could be anyone, or at least, anyone who likes reading and communicating. But let me further suggest that this work, the information hub, is an example of management work.

Whether a commissioned manager or someone else does the work is another question.

But let me suggest further, than having someone with slightly elevated authority act in this capacity also makes sense. It makes sense because such a person can be privy to more information - yes I know we shouldn’t have secrets inside the company but they exist, some are even legally mandated.

Because such people have more authority they are also able to seek out - i.e. ask questions - which are missing from information.

In summary:

  • Just because modern tools allow us to remove information hubs it may not make sense to.
  • If there is going to be an information hub it may well make sense to give this person additional authority to go with their additional responsibility.

Friday, May 27, 2016

Managers, change and strategy

In response to one of my posts on management Sergey Timanin ‏tweeted:

“the work [of managers includes] steering the organisation in times of change might be the most invisible to tech people and most under appreciated”

I agree completely with Sergey, many of the changes in and around organizations are invisible to those doing the work. Indeed much, if not most, management work is invisible to those outside the management circle. Does that make it worthless?

Programmers often just want to get on with programming, nothing wrong with that. But sometimes there are changes swirling around, left unmanaged these changes have the potential to sow uncertainty, diminish trust and disrupt work.

In my nature of management post I noted that part of the management role is to interfaced the fuzzy, unknown, unpredicted (unpredictable) world to the very predictable world of machines. This is where Sergey’s observation fits in: the world out that is in a constant state of flux, allow too much of that flux into the work environment and well… you won’t get too much work done!

Managers are sometimes described as “Firewalls”. That is, they shield workers from interruptions and uncertainties that will disrupt their work. This can certainly be true.

But, for every programmer who values their manager as a firewall there is another who believes the manager is unnecessarily filtering - perhaps even controlling or hiding - the information which reaches them and that managers should get out the way and let the information flow direct. These people see managers not as Firewalls but as Gatekeepers who (unnecessarily) restrict the flow of information.

Its easy to see how these two points of view can be simultaneously held by two individual programmers about the same manager in the same company at the same time. One man’s protecting is another man’s hiding, the distinction between Firewall and Gatekeeper is subjective. This is where managers require skills and intuition, both to know what information to hide and what to share and how to communicate with different people with different expectations.

Sergey’s tweet also hints at something another responsibility which is often laid at managers door: that of bringing about change. Particularly being about change in the work environment.

Certainly I would see this as part of a managers role but actually, I would see this as part of everyones role. A good manager should encourage the change ideas of others and help them bring about changes they want to see.

While on occasion a manager may need to discourage - or even prohibit a proposed change - managers should have a role to play in bring about change for the better. However change is usually best when it is bottom-up rather than top-down. I would see a managers role more as fanning the flames of positive change and building momentum more than rolling-out a series of changes decided on in closed rooms.

Traditionally management’s role has been seen as one creating change below in order to satisfy the requests from above: top-down change with the manager as the instrument of delivery. Certainly that is sometimes true. Those who subscribe to view that strategy is planning, that strategy is decided at the top by big brains and passed down the organization would subscribe to that view.

But I don’t.

I believe some strategy is certainly decided at the top and “deployed” or “rolled out” down the organization but, actually, much strategy is bottom-up, it is emergent, it is the result of what happens on the ground, learning at the coal-face, and how this information is interpreted higher up.

Strategy is both emergent and in many cases retrospective. That is to say, strategy is a story we tell afterwards to make sense of what happened and to align future actions. In this case manager’s role is as much about telling stories and passing strategy up the hierarchy as down.

Tuesday, May 24, 2016

Advice for managing software development?

When I started writing my management blog series one reader expressed their hope that I would give advice on how to manage software development. I’m sorry, but this series has contained very little advice on how to manage software development.

There is a good reason for that: It is hard to give specific advice to managers.

You can’t say “If X happens then do Y”, you can’t even say “If you find yourself in situation A and then B happens then do C.” You can say such things in code, and you can say such things about coding. You can say such things about testing, you can often say such things about product management. But you can’t give such rules to managers, and if you did they would cause more harm than good.

There is a branch of philosophy and logic called contingency theory which talks of such situations. When a set of pre-conditions are satisfied then a certain action is “the right” thing to do.

The problem with managing is that it is difficult to give hard and fast rules, management is not contingent. What managers do, and what decisions they make - and don’t make - is very very dependent on context.

If you were to try and codify all the management actions and decisions you would need an incredible amount of detail and an incredible number of rules. Now computers are getting more powerful and the application of artificial intelligence may render some management decisions subject to contingency theory but for most humans such an approach to decision making is not possible.

And to complicate matters, even if you did have a decision making system much of the information managers have is incomplete or fuzzy, indeed, part of their job, their reason for existing, if to manage in when information is uncertain and the world is changing. (These same factors mean attempts at contingent management, like PRINCE2, are fundamentally misconceived.)

Hence intuition and understanding of context are important. Let me repeat a quote I used a couple of weeks back from Professor Henry Mintzberg:

“Put together a good deal of craft with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context. There is no ‘one best way’ to manage; it depends on the situation.” Mintzberg, Simply Managing

Management is contextual not contingent, there are few, if any, hard rules.

Consequently I think the best advice I can give to managers, and soon to be managers, is:

  • Understand your management philosophy. Understand what you believe, understand how you believe the world works. Your philosophy will inform your decision making.
  • It is not enough to just understand ones own philosophy, one needs to continually reflect and build on ones own experiences.

Hence I have very little advice for managers. Well, actually… I do… my “failed” book, Xanpan 2, set out to try and decode many of the problems managers face in software development and build a practical guide to software managers. I was, perhaps, too ambitions. Xanpan 2 is available, as it stands it forms a wonderful appendix to Xanpan.

Saturday, May 14, 2016

Management for the masses?

This is an important post. This is the ninth blog post in my mini-series on management, it is the blog post all the others have been building up to, let me recap some key points:

  • When creating software there there is coding work, testing work, requirements work and some unavoidable management work
  • Removing managers may remove some work (because managers make work for other managers) but there is still a residual amount of management work to do
  • Management itself is a skill and requires intuition
  • It takes an engineer to manage engineering; people without experience of doing software development are going to struggle
  • Management decisions can make a big difference
  • All who are called “Manager” are not managers, some are specialists
  • There are many non-commissioned managers (NCO managers), those who manage without the title of “Manager”, frequently these people manage with minimal or little management
  • Management work may be done by specific people, commissioned or non-commissioned managers, it may also be shared among team members

I’ve deliberately avoided discussion of self-organising or self-managing teams because these subjects deserve posts to themselves. The key point for me is:

  • When decisions need to be taken they are best taken close to the point where they are needed
  • When decisions are needed those who are staring directly at the decision are often the ones with the most knowledge about what is needed
  • Taking decisions at the point the decision is needed also makes for a rapid decision
  • It may make sense to get a second opinion, to talk through a decision with another person or in a team, and if the decision effects several people it probably makes sense to consult with them

One way to address these points is to use a self-managing/self-organising team and there are reasons why you might want to do that. But, that is not the only organization structure for satisfying these needs. The underlying principle is:

Devolve authority, pushing authority downwards, decentralise decision making

Whether you devolve to a team as a whole - as in the self-organizing/self-managing model - or to individuals, perhaps to NCOs the aim is to move the decision closer to the work.

Note: I’m avoiding the work empowerment, see my Stop empowering people - End disempowerment! post form last year.

Either way you do it, if you push authority down something else happens:

More people engage in management work

Yes, suddenly coders, testers and analysts who do not think of themselves as managers now need to make management decisions. Even if this is done in the setting of a self-managing/self-organising team management decisions are still being made. Indeed, if the whole team makes the decision they whole team is engaging in a little bit of management.

Everyone in the team starts to take on management attributes.

More importantly, More people need management skills, the whole team need some management skills and the intuition that makes a good manager a good manager.

Think about this for a moment.

Do team members want to go to meetings about management issues?

Do you C++ programmers want to engage in management?

If your Java programmers are now engaging in management where do they learn their management skills?

If your Testers are making on management decisions how do they develop their intuition?

If you accept that management work is a skill set in its own right, and you believe that more people should be involved in managing then you have to ask: how are these people going to learn management skills?

Then there is another side to this…

Talk to any manager about what they actually do, not what they would think they should do, or what they like to be doing but what they actually spend their days doing. You will hear them say things like:

  • “I’m constantly fire fighting”
  • “I’ve got tons of e-mail to answer”, “My phone is ringing all the time”
  • “I never get to do strategy”, “I never get time to think or plan”

One of the characteristics of management work is that it is inherently interrupt driven. (If you don’t believe me go read Henry Mintzberg’s Simply Managing book I mentioned last time.)

So, by involving programmers, testers, analysts, etc. in management we are also opening these people up to interruptions. People will interrupt… well, potentially any team member!

Now if you are a programmer, tester, analysts or what-not please ask yourself: do I want to be interrupted? Am I willing to take the downside of management?

I’ve known plenty of programmers who would definitely answer “No!”

(There is a twist here, Mintzberg also suggests that managers choose to be interrupted. Which could imply that teams could choose not to inflict interruptions on team members but that is not entirely in the team’s gift. What Mintzberg doesn’t say how many of the interruptions would be avoidable? Do managers choose to be managers because they are interrupt driven in nature? - but we digress).

Lean folk will spot that there is a question of variance analysis here: management work has a greater variance than programming or testing and therefore needs to operate on a different cadence. The queues are different. From a lean point of view it makes sense to separate these two types of work because they have different variance and cadence.

Now here is a question.

If management requires skills and intuition (both of which need to be built in a person), and if doing management results in an interrupt driven work pattern then is management better:

a) Centralised in a few people who can be trained in the skills, who develop their intuition and who are tasked to handle interruptions, thereby leaving the majority of the team to focus on technical skills and un-interupted work (hopefully achieving flow)

b) Dispersed with everyone having some management skills (at the cost of technical skills) and some interruptions (at the cost of flow)

c) Other, please specify

For me the answer is (a) but…

If management is centralised it then becomes a question of how centralised? Over centralisation results in the model we see all too often with decisions delayed and taken by people with too little knowledge. The result is depressing and demotivating for those at the code-face.

But if management is organised as a hierarchy of managers then they make work for one another and some decisions end up traversing the hierarchy. So answer (a) is not perfect - this might be another example of dis-economies of scale.

Which brings me back to Non-commissioned managers: I would like to see more people with more management skills embedded closer to the work and working co-operatively within a team. An impure self-organising model if you like.

Any which way, there is no perfect answer. It is about balancing forces.