Your boss asks you to run the 'cloud project': Ever-changing wish lists, packs of 'ideas'... and 1 deadline

Learn from 'Bob'. RUN! As fast as your £$% legs will take you

Sure, the future is cloud. But it’s not that simple. The days where you could "just swipe a credit card and go" never existed – not at enterprise scale. Legacy applications and data need to be lifted and shifted, new services instantiated, virtual infrastructures architected, networks bolstered, and security scrutinised, adapted and reinforced for the new way of working.

Competent cloud-wranglers are not plentiful. Competent cloud-wranglers come at a premium price. That puts a heck of a burden on the rest of us. That burden can produce cloud burnout, the result of workload and undefined or unrealistic goals.

Let’s talk cases and an engineer I’ll call “Bob”. Bob was more than happy to be selected for the company’s new cloud project. Indeed, Bob was the right choice to be selected because he had years of experience with major projects for blue-chip companies that are now big cloud players. It was the natural choice.

In an ideal world, we have experienced practitioners and architects, a proficient choice of cloud provider, tools, integration points and so on. But this is the real world.

You want me to 'utilise our resources to leverage the actioning of the process-driven outcome'? Um, what?

The cloud project was defined as one of those make-or-break scenarios. Bob was a good engineer with impeccable background who really understood his stuff. There was, however, one thing Bob was not informed about: business indecision and an addiction to buzzword bingo meant the dreaded ever-changing requirements presented a moving target that was never pinned down and documented correctly.

Shortly after the project kick-off, the issue of resources began to loom large. Most IT administrators are familiar with sales people promising the Earth to make that fat commission cheque, but with cloud the scenario is different. It isn’t a case of just one customer. It can be tens of customers. Tens of customers want product X, Y and Z by some artificial business deadline.

Suddenly, all the problems become cloud-orientated. The old adage of failing to plan is planning to fail loomed large, but this is outside the hands of the cloud point guy.

Bob was now working late into the night, trying to incorporate changes that were forced into the design last minute – despite his protestations. Those changes were even changed further down the road.

Compromise after compromise after compromise...

Some of the design compromises were just mind-boggling. One peach was that all the data from the cloud had to come back through site to go through box “X” before going back out to the internet at large. Because, security, obvs. The performance in some cases was abysmal. It got to the point of compromise on top of compromise.

Meetings became fraught and Bob just took it. What else could he do? Frequently, if it was seen to be a high-friction meeting, Bob just wouldn’t attend. Saying: “Do you want this solution working or do you just want to talk about it, AGAIN?” to senior people did Bob no favours.

Bob’s family were openly calling the company all sorts of unsavoury names. It transpired Bob was starting to push his family away too. Bob’s wife eventually gave him an ultimatum. “Us or the job.” Bob approached his management. Extra cloud people required. As with most businesses of a certain size, the request fell on deaf ears. Do “more with less,” he was told, the phrase so beloved by most PHBs.

Fast-forward several months, and Bob was showing visible signs of distress. Management interceded and did allow Bob another cloud engineer to work with. But the old adage that you can’t make a pregnancy shorter by throwing extra resources at it came true and, unfortunately for Bob, the new cloud guy fell far short of what was expected and he was summarily ejected from the company.

Bob was now back at square one, with too much work and not enough time. The predictable human response, according to psychologists, is to find a way of self-preservation or a solution to the problem.

Exodus

Then something happened, overnight Bob was, well, Bob again. The snappiness and short-temperedness had gone. The company jungle drums went into overdrive. What had happened?

What Bob didn’t tell anyone (until he had it confirmed in writing) was that one of the big three cloud vendors had offered him a job. More high profile, better pay and - from Bob’s point of view - better customers!

The management crisis exploded like a North Korean warhead over Guam. There followed closed-doors meetings between Bob and his managers - no one in a Mega Corp has only one boss, ever). Massive salary increases were offered, additional bodies. Pretty much anything short of hookers and blow.

Bob admitted off the record he’d played along, just to see just how high they would go. He had no intention of ever staying. After news of Bob’s plans came to light there were other resignations and the cloud project started to stutter. No one wanted to be left holding the parcel when the music stopped.

The cloud project had become a poisoned chalice. The company, unintentionally, had burned Bob so badly there were no conditions under which he could be persuaded to stay.

Cloud was eventually implemented at this organisation, but it delivered just a fraction of what had been promised while the fall out and recriminations continue to this day.

This is not a fictional account, which is why I am writing anonymously. I’m writing to share these experiences as a lesson to others.

Management: Avoid this happening to you

The path to cloud is manifest, it seems, and delivery can be a pressure-cooker atmosphere if – as is typical in tech projects – there’s a lack of pragmatism and realism. Speaking from the trenches, what are my words to management to avoid cloud burn out taking down your key staff and scuppering your cloud project?

It is all too easy to get swept up in the whole: “Everything, everywhere, cloud, now!” scenario. Bosses must take a long hard look at what they are trying to achieve and why. Despite what a lot of sales people and companies will tell you, cloud is not the answer to every problem.

Once you have properly documented the goals, look at what is realistic. Can your organisation afford to do what it desires? Large scale, well-architected cloud solutions are not in any way cheap and like IT projects of yore, come with cost and complexity. Not everyone needs “web scale”.

What a workable cloud project looks like

There is nothing inherently wrong with big cloud projects, but the ones that succeed have smart, reasonable and achievable goals for each stage. Boiled down, it comes to do your cloud one step at a time. The most fatal step in cloud architecture is the infamous: “Can we just...?” mentality. Ever-changing goals meant Bob on a daily basis didn’t know which way was up. People who can’t see the their goals frequently lose focus and passion. A solid set of goals, managed by a proficient project manager is crucial. Bosses and techies both must be realistic about what can be achieved.

Let me expand on that. It’s OK to point the finger at management, but all those Bobs have a part to play in this game. You have to ask yourself: “Is what I am being asked to do reasonable?” “Do I have the time, resources and political will to do what is being asked of me?” and “Can I ingest cloud learning at the required speed to provide what is being sought?”

If the answer to all these questions is “no”, you’ve got a problem and need to feed that up.

And here’s where you need a good project manager. Their job is to deliver the project, yes, but that doesn’t involve operating as a traffic policeman would, by simply directing traffic. Their role is to also act as a skilled voice of reason, as a buffer between desire and reality, to parse what is wanted and is reasonable between those paying the bills and those putting cloud in to practice.

Done right, everybody can be a winner when it comes to implementing cloud and burnout can be avoided. Done wrong, well... ®