How to achieve agility (1)

This is a big topic.  Be prepared for installments.  Also sweeping generalisations about large organisations, for which there are a number (small) of very good counter-examples.

Webster’s describes someone who is agile as being: “marked by ready ability to move with quick easy grace; having a quick resourceful and adaptable character”.

The Agile Manifesto offers these priorities for Agile software development:

Individuals and Interactions over processes and tools
Working Software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to Change over following a plan

And Dilbert describes it this way:

That means no more planning and no more documentation.  Just start writing code and complaining.”  and
Agile programming doesn’t just mean doing more work with fewer people.

Webster’s defintion would be a good place to start; the Agile Manifesto offers some very applicable wisdom, and is underpinned by some quality thinking on good principles.  Guess which one of the three definitions is the one you’ll come across most often?

“Doing more work with fewer people, no planning, no documentation” (and often: no requirements, no engagement from the business, but still the expectation that the documentation turns up and you can tell 6 months ahead what you’ll deliver then…)

To understand the reason why this happens, we have to consider what most corporate psyches value.  The vast majority of large organisations you will work for (whether as a permanent worker or a consultant/freelance) are listed on some kind of stock market, and it is important to understand how this influences corporate culture and psychology.  Stock markets value one thing more than its true value, and to the exclusion of valuing at times the more obvious things.  I am not talking of profit.  I am not talking of long-term shareholder value.  I am talking of predictability.

When working in a number of large organisations it has become clear to me that the ability to disrupt expectations – even by delivering value early, or cheaply – is not valued in relation to its contribution to the short or long term value of the business; large organisations complain that they are unable to be truly innovative (which by observation I would say is often true), and instead spend large sums of money investing in, and purchasing, solutions from the truly innovative, smaller organisations; or outright buying those smaller organisations.  Large organisations often have organisational units devoted to innovation (which in itself tells us a lot about the culture they have vis-a-vis innovation), and talk a good talk about disrupting the market; but fail to recognise that it is their own culture which is stifling innovation, and it is apart from anything else this drive for predictability which has its hands firmly clutched around the throat of anything new.

Explicity: I believe a predictable failure is often more palatable than an unexpected success.

To realise the full value of the kind of change which Agile working can bring, there are an army of obstacles which need to be overcome.  The predictability culture is one, and it casts a shadow downwards from the CEO or the CFO across the whole organisation, until it reaches a level where the conscious understanding of the need for it has evaporated, and has been replaced by a cultural, reactive, instinctive mistrust of the unpredictable.  This inflexibility is characterised by the lack of responsiveness to opportunities, as well as the squashing of innovation.  It is most frustrating when exhibited without explanation or conscious knowledge by the low-end of senior management.

So when large organisations talk about becoming more agile, they aren’t always saying what they mean.  They don’t truly believe they can or should become capable of turning around new product development within a shorter period than ever before, truly responsive to the market place, and bringing unexpected new value to their bottom line.  They mean instead an incremental adjustment to average project life cycle with attendant cost benefits.  They mean the same old thing, but a bit slicker.  They mean the Dilbert definition.

The good news for those organisations is that it is almost certainly possible for them to do more with less, and without the difficulties that adopting a truly Agile approach across the whole organisation would bring.  The bad news for them is that sooner or later, another, more disruptive and innovative organisation is going to eat their lunch.  (And to be clear, I don’t think the adoption of Agile development or Agile delivery replacing waterfall project delivery is the key reason why.  It is instead the very wise saying: “Culture eats strategy for breakfast”, attributed to Peter Drucker and Mark Fields variously, hits the nail on the head.)

 

Assurance isn’t our conscience, it’s our coach

A lot of organisations use project or programme assurance as a means of checking people’s homework.  The stance of assurance is something like a particularly robotic teacher marking an exam.  Getting the right answer matters, and the right answer is the answer in the book.  Sometimes there’s flexibility to be interpretive, but often there isn’t; and the people who work in assurance are never going to be rewarded, recognised, or praised for being lenient.  It goes even beyond this into the realm of trap laying in some cases: the assurance function are there to catch you out, to spot the kind of inconsistencies which might be poor practice, or deliberate malpractice, and ensure punishment ensues.

The attitude of change teams towards this kind of assurance is, unsurprisingly, defensive.  If the best outcome you can have from interfacing with assurance is that they don’t give you a kicking, there’s no way the change team can gain anything, and everything assurance require of you is a pure imposition.

What if there was another way, a better way?

Assurance can be a very different experience indeed.  If you provide Assurance functions and activities with a clear, simple goal: improve the outcomes of our projects/programmes/whatever; and staff them with experienced operators in the field they are assuring; if you give them a direct link to feed back to update the methodology when new things are found, and ensure they share the good things they find liberally, there’s a completely different dynamic available.

You can go to assurance, and come out with suggestions on how to fix things; a fresh perspective on problems you’ve been tackling alone; even a public pat on the back for finding a different way of doing things which isn’t the standard process (yet) but works better.  “Works better” could mean “takes less effort input for the same result output” or maybe “gets to the same result faster” but if you’re really lucky it’s “takes less input, gets better output and faster too”.

At the very least, you’ve made sure that whatever problems you are facing are transparently visible.  This can help to overcome the still-common cultural problem of burying bad news.  Everyone has access to assurance, and that means there’s a route to getting problems aired which doesn’t get blocked by, for instance, an incompetent sponsor.

This depends on what the reason for assurance is.  If you are putting assurance in place because you want to improve project outcomes, or the ratio between inputs and outcomes (cost, effort, time versus benefits), a well constructed and appropriately targeted assurance function is just the thing.

If you’re putting in assurance because a lot of projects are going wrong, and your processes aren’t being followed, well that can help too – but it needs to be backing up and supporting a review of the clarity of your processes, and almost certainly some additional training.

If you’re responding to the discovery – possibly by an audit – that you haven’t got good control over your projects, you’ve come to the wrong place.  Adding assurance isn’t how you get better control; reinforcing control is how you get better control, and while there are many different ways to achieve that, simply forcing people to get better at covering up their mistakes – which is the result of adversarial assurance (as described at the start of this piece) – isn’t going to get you better control; it might well make things worse.

 

 

 

 

Servant Leadership

This is a topic I stumbled across long after I’d established what my values and intentions were in leadership, and I found myself feeling immediately at home with the concept.  Over time, I’ve found this term creeping into sufficiently common use that I can offer it as a description of what kind of leader I choose to, and aspire to be, and I find it is sometimes understood – and often looked up, and then understood.

It’s possible that it’s obvious from my other posts that this is how I prefer to be and act, but it’s also possible that this is a new term to someone reading this blog.

Before I provide a link or two to learned articles on the subject, I’m going to explain what it means for me.

I value myself at least partly based on what I can do for other people.  It makes me happy to help others, and it makes me happy to see others do well.  This doesn’t mean I lack the ability or desire to be competitive – play me at board games and you’ll see some competitiveness – but it does mean that I get a kick out of seeing my team do well, whoever I perceive my team to be.  That sometimes – often, hopefully – includes the leadership of that team above me on an engagement.  I call this heart.

It doesn’t mean that I’m a soft touch.  I want the team to do well; if that means that the best thing for the bulk of the team is that someone within the team leaves, that is what I will attempt to achieve.  I usually try to find a way to turn that person around, repurpose them, or otherwise get a result which is good for them as well, but in the final analysis, I can fire people, and I have.  It’s the hardest thing to do, but leadership isn’t about doing only the easy things.  I call this character.  This is also what I would rely on if someone in my team acted out a prejudiced *-ist attack on anyone to my knowledge.  A team needs a conscience, with sufficient teeth to matter.

Sometimes I have to protect my team.  A leader should shower the praise on their team that he receives from outside, but criticism should stop with the leader.  This does not mean that the team members are immune from criticism, or feedback, but it means that the leader should be the one to pass on that message, in the way which will give most benefit to the individual, and which will cause least avoidable damage; and the leader should be shielding his team from direct attack from outside.  I call this courage.  I’d like a better name for it, but when I want to mentally tick off the list, that’ll do.

I want my team to do well, so when I’m leading a team, I want to find out what things are getting in the way of them doing well, and get them out of the way.  Enabling people at a basic level is a key attribute of any manager: giving people the tools they need to get on with the job, always remembering that tools can be physical, software, intellectual and emotional.  Helping a socially awkward computer programmer (stereotype warning!) find some emotional intelligence and insight into the people around them can improve not just their productivity (as much as getting them a faster computer for compiling code), but it can improve far more that can’t be measured with numbers. Coaching and cajoling people, offering feedback and providing opportunities to learn and grow: these are the ways a leader can transform the effectiveness of their team. What’s getting in their way might be their ability to make decisions within the scope of their job.  Like many other things, making the right decision gets easier with practice and examples.  Empowering people isn’t about giving all of them unlimited sign off authority instantly, but empowering them to make the decisions they need to for a productive and happy working life – *and* – is a great way to get engaged and committed, enthusiastic contributors.  This can take the form of permitting them to flex their start times to something which works better for them.  It can be permitting them to choose to work remotely.  It can be keeping the organisation at arms length while a self-forming Agile team goes through the stages before “performing”.  All of this is still enabling to me, although somewhere in the middle for some people that switches to empowering.  I just view the whole thing as “removing barriers that stop people doing their best”.

The last attribute is foresight.  Some people find this easy, but I tend to the view that the ones who are superb at this don’t do a lot of the other things you need to do.  Nevertheless it is a necessary task.  All the enablement you can offer is not going to bring about the changes you need to deliver unless the direction is clear, and that’s especially hard to find in operational teams; when you’re leading change it’s usually a bit easier.  You can do this poorly and the change can still be delivered, but when you do it well you supercharge the team’s ability to deliver.  The larger the change, the bigger the focus on this attribute.  If you have this, but can’t communicate it, you’re going to at least make some good decisions.  If you have this and can communicate it, you can provide people with a vision of the future that can invigorate and even inspire them.

It’s a tall order, and it needs to be worked on every day.

 

 

 

 

JFDI, or the illusion of fast delivery

Every now and then a change is issued as a JFDI.  Blanket exemption from everything, throw resources at it, just get it done.  (If you don’t know what JFDI stands for, ask someone old enough to vote).

In an organisation which has a good level of control over its change, JFDI is the exception.  In a badly run change organisation, JFDI is the norm.  In an organisation which is too rigid, nothing is ever done by JFDI.

Did I just say that no JFDI is a bad sign?  I did, and it can be. For two reasons.  First the less contentious JFDI learnings.

Organisations need to be cautious about doing change via JFDI routes because JFDI destroys value before it delivers anything.

As soon as you do something by a JFDI route, stampeding through process gates and ignoring boundaries of responsibility, you show that the organisation can ignore all those safeguards you’ve been putting in place with the assurance, training, communications, and best practice processes.  That’s a bad precedent to establish.

JFDI tramples on other people’s work.  If you aren’t on the JFDI train, don’t get in its way.  This discourages people from working on anything else, destroys teams already in place (by robbing resources), weakening committment, morale, and initiative, and harming the long-term retention of those thrown under said train.

JFDI ignores strategic considerations – in a software change organisation, it often ignores architecture and design patterns, testing best-practice and planning, stop-to-think time – whether it’s a good idea to continue or not; in a manufacturing organisation (where it’s very rare indeed) JFDI represents shipping a prototype without testing.  In some organisations it’s simply unthinkable.

The aftermath of a JFDI delivery can be wide and long.

Wide: across the organisation which has been afflicted, many projects will have been disrupted.  The cultural impact can also extend beyond the boundaries of those obviously involved – not just the team who delivered the JFDI change, nor even only those who were the recipients of the change, but also the supporting teams – the Finance team, the HR team, the trainers; the PMO or assurance teams; often the testers; IT support (both internal and for external customers).  The negative impact on individuals can, and often does, lead to staff turnover or at least burnout.

Long: change debt.  That whole class of things which are the consequence of having done things the fast way, rather than the right way – technical debt, architectural debt, training debt or process debt, organisational debt.  Technical debt and architectural debt often take years to recover from, and sometimes last the lifetime of the platform which has incurred them – with a knock on effect on many or all changes to that platform.  Training debt results in people being ill-equipped to support the change which has been rushed through, and that in turn demotivates people who are good, provides excuses for failure to all, and reduces the positive impact of whatever change was rushed through.  Process debt is like training debt, but represents the impact of not having designed the right processes in the first place, and no amount of training can fix this if the process people are learning is a bad process.  Organisational debt is a surprisingly common problem which goes unnoticed: when the organisational design has not been updated to allow for the changes which have been brought about, there are gaps in accountabilities and responsibilities – or these have been aligned to a group which doesn’t have a good, organic reason to care about the thing they’ve been given to look at.  I’ve seen an organisation which had absolutely no one accountable for shipping the product to the customer (it was a digital product, but there was still no one, and no organisational unit, which was held accountable for the customer getting the product – the IT department had taken care of it).  Changes cause creeping drift, and every now and then it’s important to realign design and reality (one way or another) and see there aren’t any gaps.

So JFDI comes at a price.

Sometimes organisations make the choice to sacrifice some of the good things that fall by the wayside during a JFDI delivery to achieve something of great value – a takeover (in either direction); hitting a particular deadline for a tremendous opportunity, or to avoid a hideous regulatory hurdle; the sort of disaster or emergency which, for instance, 9/11 represented, and what some organisations did in the aftermath of that.  If they do it conscious of the consequences, and with a recognition of the mess they’ll have to clear up afterwards, they can not only plan for that, but genuinely reduce the impact of these bad things – especially the ones which impact people.  Morale, commitment, initiative, the culture – these all rebound if they recognise that this JFDI thing is an exception, a response to something that happens only rarely, and not the normal way of doing things.

If organisations do JFDI delivery too often, the debts mount up calamitously, much like the stables of Augeas, and it is a labour of Herakles to clear it up.

But…

If there’s no ability to overturn the fences from time to time; if there’s never a situation where you throw caution to the wind and just go for it in a JFDI manner, the organisation you’re looking at may well be suffering from being too hidebound and too cautious.  That doesn’t bode well for the future, and for fending off competitors.  I know there are business domain exceptions – I do not want to be the first to fly on an airliner that’s never been tested, or even which runs software which was produced JFDI; other than in these business domains, the total lack of JFDI can even indicate that the organisation has reached the kind of steady state without change which is the last rattle of a business dying, peacefully, in its sleep.  While a business can rarely recover from this sleep of death, it is typically only with an injection of a very different senior leadership team, and that often comes at this point by aquisition.

And a total absence of JFDI can mean that the organisation has given into the illusion that it controls its market entirely, and can predict everything; and that is also dangerous.  It means that sticking to the plan is more important than pursuing an unexpected turn, which is an environment in which very little (if any) innovation can flourish.  It can happen to organisations at the very peak of their arrogance, and topples large and healthy organisations from their commanding position.

 

Flushing the Matrix

Finishing off the exploitation of this particular line of thought – and the film reference that goes with it (sorry) with some of the slurry at the end.

Bad things come to those who wait.

The worst challenges of Matrix Management are logical progressions of the concept, and probably inadvertent, but they are common enough to be something to watch out for.

Salami!

In the kind of change Wolf Bear are involved with, the primary activity of most of the individual contributors on a given project or programme is one requiring focus, attention, and thought.  It might be cabling a server rack well, or it might be writing code, or identifying what felt wrong about a particular functional test, or making a good consistent set of icons for navigation around an app, or a dozen other things that require attention.

Matrix management is sometimes used to slice people’s time too thinly to properly concentrate on what they are delivering.

The focus required can take quite a lot of time to muster, to reach full effect. This is often referred to as “getting in the zone”.  For a lot of coders (for example) it’s a necessity to have a long run up at solving particularly challenging problems, and that doesn’t make them a bad coder – often quite the opposite.  Understanding and getting into the context of a particular project or activity isn’t something that just happens, at least for most people.  Context shifting comes at an intellectual, energetic, and motivational cost, and it harms the concentration and reduces output.

With matrix management, some organisations think they can spread people out ever more thinly, and receive the same results.  A cariacature of a project manager often repeated is: “A project manager is someone who thinks that if producing a baby takes a woman nine months, putting 8 extra women on the job should produce the baby in a single month.”  Many organisations behave as if they believe that they can equally split a person across 4, 6, or even (the worst I’ve seen) 16 different projects and still receive the same attention, quality, and output.

I notice that in every large organisation I’ve seen adopt this kind of approach they have been careful to avoid doing it to flagship projects (programmes, etc.).  Any time you see a behaviour consciously avoided for flagship projects, you know that the organisation knows it harms delivery, and they choose that compromise for the less important things either because it’s how it’s always done (intellectual apathy), or because it’s a compromise they are willing to make.

The results at the negative end of the spectrum include some that are pretty obvious – slower completion, lower quality, increased rework – but they also include some less obvious results: the consequences of forcing people to work in a way which they know they are less good at destroys motivation, lines them up for the kind of performance review which drives them to leave (and sometimes leave permanent employment entirely), and even if their performance review doesn’t suffer, the constant drudgery of producing something less good than what you know you could if you were just given the chance is debilitating.  This is the illusion of efficiency – it feels cheaper to split people across projects – over effectiveness.  It is often better to focus on doing a few things well and quickly than doing many things at the same time, but taking longer to finish anything.  There are scholarly articles in the canon of psychology exploding the myth of multitasking on an individual level, but organisations as well only have so much focus too – but that’s for another article.  True efficiency is a result of comparing the total inputs with the total outputs, but the perception of efficiency is not always as well thought out.

In short: careful with focus; it is fragile, and if it’s too dilute, it harms progress dramatically.

Matrix Dumps

There’s a consequence from matrix management on the (leadership of the) team from whom the matrix resource is drawn.  Very few people become leaders of teams because they are thrilled by utilisation spreadsheets.  (I would like to think it is none, but a variation on Rule 34 probably applies).  If you take their team away on a regular basis and largely divorce them from what the team are doing, what do you expect their response will be?

The team leader might stay.  All organisations have a degree of turnover in staff, but the fastest to leave are seldom the ones you want to leave.  A team leader who knows he has little to do with the way his team work may not take the care and attention a motivated one would in recruitment of replacements.  This snowballs rapidly: if people work in a team where they know the manager no longer cares, they also lose their interest.  That fuels a drop in engagement, which in turn often increases staff turnover, and the problem accelerates.

As a change leader, this can rob you of the tools you need to deliver change – effective, engaged contributors.  The short term solution is to bypass the more irritating consequences of matrix management and, especially on large, demanding changes, adopt resources wholesale.  Longer term, the changes needed to resolve this issue are more pervasive, and harder to achieve.

 

This is the disconnect is what lies at the heart of my problem with matrix management: the disconnect between the host organisation and the change vehicle. It is the underlying cause of most of the problems I’ve laid out here, and it is hard to resolve systemically.  Recognising the organisation’s true priorities and focusing on those is an organisational approach with a lot of merit; but it’s hard to get the different competing areas within a big organisation to be patient while other areas get their changes carried out.

This is mostly a problem with waterfall organisations.  Agile’s resourcing is for another time.

 

Deeper into the Matrix

light green characters on a black background

Continuing on the theme of Matrix Management … and hoping this sequel doesn’t suffer the same fate.

Developing the Matrix

When your organisation is working hard, and trying to get the most change done there’s a common casualty: Personal development.  Some line managers try to align their resources to the projects which will provide them inherent opportunities to develop, but a lot seem to either lack the time, or are not permitted the chance to flex resources to reflect their hopes, aspirations, and interests.

This isn’t a responsibility you’ll find in any project brief, but remembering that the intent of all projects is either to build, or to protect, the value in the business, and recognising that the combination of motivating and directing your team is not always easy in a matrix environment, it is in your interests and the project/programme’s interest to get involved.  Approach the team members you’ve been assigned and who you can get around to (that’s not going to be everyone in a 200+ person, 2 year, 3 continent programme), but as a minimum those you directly manage within the change organisation, and find out what they want to learn next.  See if you can angle a way for that to be baked into their role on your project.  If they want cross-training into another skill, see if you can facilitate an introduction to someone within the project who can help them out.  This isn’t your main activity; this isn’t the purpose of the project or their engagement with it – but it’s a way of giving them something which in many cases they aren’t getting any other way, and it pays you back greatly.

Considering the time they spend working on your project, you’ll be seeing more of them than their line manager does.  Invest time in them and how you can help them, and you’ll find a team who do give a lot more of their best for you.

Matrix: Because I choose to

Which brings me to the question of motivation.  Matrix management doesn’t inherently provide good motivation to the members of your team to do their best, or even their second-best, for you.  With the combination of the remote performance punishment reward cycle (often annual; as discussed above usually by a line manager who knows very little about the project contribution); the lack of personal investment in the outcome of most changes for the individuals in this environment; and particularly if there’s the salami-slicing of splitting people across multiple things at once (more of that anon), the motivation of those who work under a matrix manager can be very thin.

If you need the best out of the people on your change, and that’s the case if it’s demanding for them or you as a change leader, you need to motivate them.  When they are working for your change all day, every day, if you’re not taking care of their motivation, ask yourself: who is?  Self starters are great, but not everyone is one, and if your team is going to produce something excellent, you need the best out of a lot of them, not just a few.

For a large proportion of their working day, those individual project contributors, or for larger projects or programmes, even those managers, are going to be your vehicle for carrying out your job, so spend some of your focus on them.  One of the best ways is to engineer opportunities for some personal development for them. Another, simple one, is feedback – again, already discussed.  Offering them some flexibility that they don’t otherwise have – like a later start in the morning, provided that doesn’t harm the needs of the team and the delivery – it’s often surprising what will make a difference.  Remembering always that for a lot of people: motivation isn’t money.

If they are getting all they need from their existing management, you’re not trying to take over, so leave well enough alone.  If they are the kind of self starter who doesn’t need any help like that, again, leave them in peace.  For the others, remember that while they are working on your change, they are your team.

 

 

The Matrix? Do you want to know what it is?

light green characters on a black background

Another movie quote, from The Matrix (1999).

Matrix management is a common affliction.  It is adopted as a way of managing multiple people across an organisation into different temporary organisations (i.e. projects or programmes) without formally transferring them out of their original organisations.  That’s the simple version.  The more intricate version, often adopted in larger organisations in the hope it creates efficiencies (cost savings), is where people are not only loaned out to projects/programmes, but to multiple such temporary organisations at one time.

I’ve given away my position on this in the first line of the previous paragraph.  It’s not that the idea is utterly terrible – in fact it can be done well, and have some really surprisingly good results – but the execution is usually so dreadful that I use the term “affliction” deliberately.  Let’s look at some of the worst sins.

Matrix Performance Desserts

Within the world of work we all get managed towards better performance, at least in theory.  The fact that some contractors (freelancers for those across the sea) cite annual appraisals as the strongest motivator for going that route – rather than the increased financial rewards – speaks volumes about how well that entire process is handled in many organisations.  Nevertheless, in theory we receive coaching on how to improve our performance from our line manager, who has pastoral care responsibilities for us; and in theory in many organisations they are also supposed to support our career development.

So what if all the work we do as individuals, or the vast majority of it, is done for projects via matrix management?

Time and time again line managers are divorced from the quality of their staff’s work.  Matrices are a very good place for poor performers to hide.  It makes me question the point of having any line management in the traditional sense when people within that line are spending all their productive time working in projects away from the perception of the person.

I didn’t say simply “how bad their staff’s work is”.  The lack of visibility cuts both ways. It’s demoralising to work hard for a project/programme, make a real contribution, and then discover that in your end of year review your performance has been marked as mediocre.

Some organisations have the good sense to put in place a means of recognising and rewarding good performance in a more tactical way.  I have yet to encounter an organisation which has a good way of giving just desserts to non-performers in a similar manner – if there’s anybody out there with suggestions, please pass them on!  Neither of these two are a substitute for the performance review goodies – in typical organisations your individual, performance related pay does not necessarily reflect tactical rewards at all, and permanent pay rises are more a question of the line manager’s perception than the value delivered to the company.

I have an odd habit.  I like to collect ways of saying thank you (in different languages for instance).  Last time I counted, I got to around 50 different languages I could communicate thank you in, including some very peculiar ones.  This – albeit not in different languages – is a habit I strongly commend to anyone who has to deal with Matrix Management as part of their role.  Certainly not every week for every contributor, and there will be times when it’s a lot less often, or only a subset, but cultivate a habit of feeding back about good performance to both the contributor and their line manager as a regular part of what you do as a matrix manager.

When it comes to poor performance, the same principle applies.  You don’t have to write a foul-mouthed rant about someone’s unlikely parentage and personal habits, but you should feedback, again to both the contributor and their line manager, if you can see development areas that the person needs to focus on improving.

A bit of coaching to the contributor is useful here too: encourage them to set aside that feedback, from any such matrix engagements, and use it with their line manager during the review process if such a thing happens.  (And since you’re going to be constructive if you’re giving “please improve” feedback – always – you can encourage them to consider for themselves how they can act on that feedback.).

This approach could be shocking for the line manager, so it’s worth letting them know that you will be doing this.  Make sure that they understand that if you’re going to them for an escalation, or for them to take action, you will explicitly say so to them in your communication.  Otherwise every time you do this you may be getting more and more demoralised resources.

I will be jacking back into the Matrix again soon…

A beginning is a very delicate time

“A beginning is the time for taking the most delicate care…” – Frank Herbert, Dune.

The title of this is taken from the 1984 film version of a book I enjoy tremendously, and both quotes are good observations, particularly reflecting the natural world.  New born creatures are delicate, and vulnerable.

With changes, you could be forgiven for thinking the same is true.  Certainly the behaviour around them in many large organisations would lead you to believe that.  The start of projects is often the time when bad news and negative thoughts are hidden, or manipulated.  Risks, downsides, recognised areas of doubt or uncertainty: these are not shared with the decision makers who decide which projects get to continue, and which need to wait.  People treat new projects, programmes, workstreams, unbuilt products as if they were newborn babies, gently, quietly, and with care.

The result is that far more projects (etc.) get attempted than should be; and both the inputs and outcomes of those projects are sometimes very different from what was expected.

The beginning of an endeavour like a project is not a time to be delicate.  It is a time to blow the bloody doors off.  It is a time to thrash around with the idea and see whether it really will hold water.  It’s a time to examine, to question, to try different ideas.  In a healthy, mature change organisation, a lot of changes will stumble at this hurdle.  Some will fall entirely, others will take time to be rethought and approached differently.  Some are already just right, and will go ahead with a confident step knowing that they have already been through a testing time and stood their ground.

Aside from the well known adages about the proportion of effort spent in design versus build, there are other important effects of getting things a bit more right early on, and its opposite.  Right: better-set expectations, the right support early on, well identified stakeholders and supporters.  Wrong: constant political firefighting, distracting detractors, the wrong stakeholders (see earlier comments about Decision Weakness).  Right: A good proportion of the right people in the team to start with.  Wrong: Hammers, where you needed screwdrivers.  Right: time to fight the battles that really need fighting.  Wrong: doing things you know are wrong for the business because a deadline is approaching but you can’t take the time to fix it.

This speaks to the culture of an organisation in general.  If there is a good culture of openness and transparency, the decision makers will know whether ideas are being presented to them having been through a challenging filter, and be better able to trust them; they will also know that a rejection now is not a rejection automatically forever.  If there is a culture of spin and misdirection, projects (and sometimes even programmes) will be started with the gatekeepers having one idea of what will be the outcome, when, and how, and the people in the change vehicle being launched either having a different idea or no idea at all.  “No idea at all” is absolutely fine when the people signing the cheque know that they are backing something entirely exploratory.  Indeed they should be reserving a portion of their change budget (organisation-wide) for just that sort of investment because that’s where the unexpectedly good returns and innovation come from.  It is never fine, however, when they have been sold a different expectation, and it will cause trouble for everyone involved, often particularly those least to blame for it.

One real world example I can think of involves a programme which was started with a very open idea within the culture of that programme – a “let’s see what we can achieve” kind of idea; however the parent organisation was under a much more concrete impression.  If there was a tacit agreement that it would be presented as concrete but continue as blue sky, that tacit agreement fell by the wayside when there was a change of executive management.  Suddenly the open money pit became far less open.  Expectations morphed into demands.  Before very long after the executive change, in my judgement after a generous period of time nonetheless, this programme was stopped.

In the process, the careers of the individual contributors at that institution were blighted.  They had spent a year, or several, working in a culture which was at odds with the parent company culture, acquiring a way of working alien to the parent company.  Their old positions were filled, permanently.  They were looked at, on returning, with a bit of suspicion.  By the end they had been directly disadvantaged financially – as they were deprived of performance bonuses because their programme had (abjectly) failed to achieve the targets it had been set.  If they were completely honest on their CVs when they left that organisation – many did, shortly after – they couldn’t point to the thing they’d worked really hard on being any kind of success, so perhaps even their post-company careers were blighted also.  I can think of dozens of people caught in this particular situation who had nothing to do with the failure of this particular programme.  Most of those I could see being to blame seem to be doing very well for themselves now, although I do know they too had to endure some tough days when things were evidently going badly while the programme was still being run.

Imagine instead a known, arm’s length more risk-oriented investment vehicle, created to attack innovation directly, with a properly understood acceptance of failure, and a deliberate attempt to bring things to a head appropriately quickly… no tarnishing of careers, no great surprise when it isn’t a raging success for any particular line of development, and everyone knows what they are getting into at the start.  (Incidentally, that’s what that company have now set up).

So, in summary: at the beginning, don’t handle the idea with kid gloves, beat the snot out of it.  If it’s still risky, make that really clear to the decision makers.  Changes are best beaten up early, if they are to avoid being beaten up often.

 

 

Expansion is still non-linear

Last time I blogged, I mentioned that adding extra creatives to a project is one area where extra people can make a disproportionately good difference.  Well I implied that.

As with all things, it depends; but if what you need are many creative assets created in line with a brief, I do find that adding extra creatives to the team doesn’t just result in an expanded throughput, it ups the quality.  There’s a synergy in creative activities which seems to result from creatives talking about, and sharing inspiration from, their own and each other’s art.  I’ve seen this work best for graphical creatives, but I’ve also seen this work for wordsmiths as well.

I find it interesting, and I also find it inexplicable.  It ought to work for other intellectually-driven activities too, but somehow.. it doesn’t.  The complex interdependencies of coding make that kind of inspirational collaboration something you only see on rare, beautiful occasions, and you can’t plan for it.  The nature of testing isn’t something where someone else’s results help inspire you to .. find more bugs.  Infrastructure engineers sometimes work in pairs the way programmers often do, and with a similar improvement on quality of outcome as pair programmers get – but seldom, and not reliably.  It’s only creatives who seem to really boost each other’s performance in this way.

Or perhaps I’ve just been consistently spoiled in the creatives I’ve worked with?

(In the interests of balance I should add that I can’t imagine getting a gang of creatives to collaborate on a single individual deliverable together and that having the same magical effect)

It does make me wonder whether there’s a way to get the same effect with extra coders, but without the inherent additional complexity you usually get from independent code generation.

 

Expansion is non-linear

One of the first thoughts when you have a change where you have more money than you can currently spend, but less time than you currently need, is often to expand the team.

This can be a big mistake.

If the current team aren’t performing as well as they ought to be, adding more people will seldom fix the problem.  Quite a lot of reasons for poor performance by a team of contributors will only be worsened by additional people.  I’m most familiar with technology-enabled changes, so let’s take a few examples from that space.

If you’re having trouble getting the build to be stable, adding more developers – and letting them code new code – will not make the build more stable.  You’ll get more new code through, perhaps, with a proportion of mistakes – Erasse humanum est (Seneca?).  If you aren’t using automated testing (why not?), adding additional testers will increase the complexity of coordination between them, eat up time while they become familiar with the product and test scripts, and differing judgements may well alter the things identified as bugs (often: upwards).  More architects do not result in a quicker architecture (quite the reverse).  More designers do not result in faster design results.  More creatives … well actually, sometimes more creatives really does improve things – and I’ll come back to that in a bit.  If your team just isn’t performing with the velocity you expect (whether on Agile or waterfall or some other variation), adding extra people isn’t going to fix anything by itself.

You have to understand the problem you are solving by bringing in extra people.  If those people can start work without interrupting those who are already working, be productive entirely independently of the existing people, and deliver product to at least the same quality, extra people can help.  So many things we do in technology changes – and in many other spaces – are strongly interdependent, however, that many hands do NOT make light work, and it is rather a case of too many cooks spoil the broth.

Sometimes, the problem of speed is better solved by taking people away.

Now I know there are times when the person everyone wants to take away is the change leader – project manager, programme manager, scrummaster, whatever.  If they are serving the team/project/programme/organisation well, they aren’t harassing for pointless updates.  Sometimes, the only thing has been to go and get the coffees, teas, doughnuts or whatever, and if that’s all I can do: good enough.  Sometimes the thing I do which helps the team to get things done is intercept all the people who are trying to find out when the widget will be finished, and lead them away.  That’s definitely a valuable service.

Sometimes, though, it’s not as nice a job as that; because sometimes the right thing to do to allow the team to speed up is to remove someone from the team.

I’ve liked a lot of people I’ve worked with; and not all of them have been good at their job.  One of the difficult tasks in Change Leadership is spotting when someone is having a negative impact on the Change you need to bring about, and removing them from the position where they are able to cause a problem.

I had a pair of programmers pair-programming in a series of sprints.  One of the programmers was a rock star – not a prima donna – but extremely quick, very accurate, very effective.  (He’s also my go-to example for why asking for a number of years of experience is a bad metric of quality – after 9 months of Java programming he was without doubt the finest Java programmer I’ve ever come across.  He still is, years later).  The programmer he was paired with had, nominally, more experience.  He was also Mr Slow.  He was not stupid, and I don’t think he was lazy; but he had no drive for programming, and his attention wandered constantly.  Adding an extra pair of programmers would have meant slowing down while they got up to speed, and wouldn’t have solved the real problem.

The urgent problem wasn’t even the velocity of the project.  I could handle the customers well enough that we were fine with that, as it happened.  The real problem was the velocity of the rock star programmer.  It was painful to watch him have to shift mental gears to try to keep coaching the other programming, bringing him on board, helping him understand what had been coded, and then letting him have a contribution.  It was even MORE painful to watch the frustration and itchy fingers when Mr Slow ‘drove’ the keyboard.  I needed to resolve this problem so that I didn’t lose an outstanding programmer for the sake of being merciful to a far less exciting one.  Or to prevent a murder.

If you’re kind, you can often find something for the person who isn’t working out to do which is more to their skillset and preferences, and makes better use of them – which, after all, is good for them and good for the company.  He made a perfectly acceptable project manager in the end.

If you’re leading a change, and there’s money on the table to help you speed up, think hard about whether extra people will give you what you need, or whether there’s another underlying problem.  Remember that just because someone is offering you what they think will help you doesn’t mean you have to take it.