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 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.