What does Environments Management and a spiderweb have in common?

There is a look that you learn to identify in the early stages of taking on an Environments Management role. It’s somewhere between bashful, hopeful and slightly desperate. Occasionally it is preceded by a slightly nervous cough. And without fail it means a project has underestimated their requirements and they need you to magic something up… ideally within the next hour. Tomorrow will do.

One of the biggest challenges facing Environment Managers today is the speed that project environment requirements change. As projects become more agile, so the assumption is, should the environments that support them. However, no cash-conscious IT department will run extra environments ‘just in case’ – it doesn’t matter whether the applications are based on-premise, in the cloud or a hybrid of the two – this is just burning money. Also not every type of environment can be spun up at the drop of a hat – those with multiple integrations and specific connectivity requirements will take time if they are not part of a standard automated rig. At any given time an Environment Manager has to run the leanest ship possible, but remain flexible enough to deal with a certain ‘unspecified amount of changing requirements.’

So what is the best way I have found to handle this?

I will use the analogy of a  spiders web. In order to use the web to best effect the spider has to sit in a place where it can feel any single string vibrating at any time. The same goes for an Environment Manager. Except in our case the strings are radiating lines of communication.

Communication is probably the single biggest asset in an Environment Managers predictive arsenal. If you can build solid working relationships with people at every stage of a Release lifecycle – from the Business Analyst that shapes the projects, to the Project Managers that will run them, to the Technical resources that build them, the Testers that check them and to the Release team that puts the whole package live, you will have a far better chance of hearing or seeing about new or changing requirements before they are formally asked for. Nothing ever comes completely out of the blue.

It does take time to  build up your spiderweb (and you may get some odd looks at first from people who have never even heard of a Environment Manager, let alone spoken to one)- but I assure you -its worth it. The only downside is that after a while you will probably get a bit of a reputation with your Project teams for predicting the future.

Technical Debt – having a vision of what should be

Technical debt is a problem for most IT divisions that have been running for a while. The drive for quick delivery to market forces projects to run as fast as possible in order to meet business expectations – and unless a company is very disciplined from the start- this can sometimes come at a cost of shortcuts or ‘acceptable’ defects being introduced.

On a project by project basis this probably isn’t a huge problem – so long as you are within risk tolerance, some projects can go live with known defects or workarounds – but when you start thinking that a lot of major enterprises will be running hundreds of potential projects in a year, and some applications may be several years old, you could see how this could add up if a strategy isn’t in place to handle it.

One of the sanest ways to combat this is to move to a methodology that bakes quality into the process; agile methodologies are very keen on this. However for those companies that are transitioning to agile methodologies this means they could be facing a mountain of technical debt before they even start.

Where do you even start with something like that?

I read a very entertaining blog by Jergen Moons which makes some solid suggestions about tangible ways to approach handling technical code debt. The biggest take away I got from it is to start small and make consolidated targeted improvements as part of a long term vision that works alongside future development. I recommend having a look.

My kind of Environment Management has no Trees

Its a fairly standard question – so whats do you do as a job?

Outside of very specific circles, the answer I give usually has one of two responses.

          “Oh what – like trees and climate change?” (resigned sigh)

or if I am lucky,

          “Oh that’s something to do with IT right?” (brief start of surprise from me).

Yes that right! I manage test environments for a major retailer… oh you’ve gone.

For those that stick around long enough my favourite analogy is ‘an Air Traffic Controller for IT environments.’ It was a term I first saw mentioned over on the Plutora blog:  The Definitive Hiring Guide for Test Environment Managers 

Think of a test environment manager as an “air traffic controller” for environments and databases required to test and qualify software for release to production. This job is one focused primarily on tracking and scheduling, but it also involves integrating a number of conflicting inputs to support testing across multiple generations of interconnected systems. A test environment manager balances budgets with timelines and other constraints to give developers the systems they need to ensure that software works as designed in production.

NB: This analogy is not intended to belittle actual Air Traffic Controllers (they stop planes crashing into each other and killing a lot of people after all). There are just certain similarities when it comes to the complex interdependencies that both roles have to juggle.

The thing that draws me to the job is the thing that makes it very niche – the sheer breadth of the role. It the ideal job for a candidate that thrives on doing a bit of everything. Project, Release, Change, Configuration, Strategy, Access, Quality and Data Management are all elements of my role. You need to be able to talk to stakeholders at the right levels – enough technical knowledge to talk to an engineer and business savvy enough to be able de-jargonise for business leaders. It’s a role that requires both reductionist (going down to the details) and holistic (the big picture) thought processes. You need to be able to replan on the fly and also plan far into the future – often in the same conversation.