Don’t assume what is production and none production

Back in the old days, we had very strong development to production demarcation rules, and this was very simple, because there was very little integration. In fact, usually the only time that we had blurred lines was the use of email, where if you got a test email wrong, it would escape into the world and cause never ending troubles.

Then along came the cloud. The cloud comes with its ability to spin up multiple instances of the same type of environment to apparently make the lines between Dev and all other environments very clear cut.

But inside a corporation, you’ll find that this is not the case, because underneath all of your nice, neat environments there is the same infrastructure with the same shared services, so you soon find out that when you request something, what you think is a simple and limited development environment request will actually mean weeks of justification and the full change release process.

The most common of these is firewalls. If you want to open a firewall between you and another environment, such as a vendor service. That is actually a change to a production area and will be treated as such. You will find this will be true of most network situations, and particularly with most data transfers to things in the cloud, which will even for simple proof of concepts require sign off by your security services. So if you are planning that, do not assume that a request for dev access will be instantly acted on, you will have to do the same justifications, as if you were dealing with production.

Empowering Tip for Your Tech teams: The Resolver Read Access group

You would think that with so much on the cloud and often nearly all within one ecosystem that de-bugging modern application connectivity and integrations would be a simple thing but you would be very, very wrong.

The huge level of complexity and granularity of control has just meant that de-bugging is now a multi person nightmare in any decent sized Corporation.

Successful debugging usually requires particularly gifted or knowledgeable people, and doing it can become an all consuming part of their jobs.

One of the most unexpectedly difficult parts of the process is the restricted nature of performing tests, running trace routes or even seeing logs and configurations.

This lack of transparency can quite literally cost you months of work trying to get to the right people to do something that should take 60 minutes as you try to get all the right people on one call, To fix this I personally recommend any large scale corporation have a general technical access group with a very good read level, it should span across all infrastructure and be able to see everything that is not implicitly secure (such as human user activity). It should be able to see the configuration to all aspects of your infrastructure: proxies, firewall or cloud objects. Everything that does not contain something that is justifiably secure.

This aids senior technicians in debugging so much it’s untrue. it is embarrassing the difference it can make to the speed of delivery of a feature. It also leads to far less finger pointing, Teflon shouldering and “oh it can’t be our part” excuses as you have log evidence.

Lastly and quite strangely different people can get hot and cross over the group name (I have no idea why) , so I have found the name:
“Resolver Read Access” seems to keep things calm and on point.

Corporate term: “Golden Hour”

Definition:

The corporate Golden hour is the 60 to 90 minute time period where you can have a meeting with attendees from all the Major Time regions: EMEA 1, NA 2 and APAC 3.

Explanation:

Traditionally, the golden hour was when photographers were at their most productive and was the period of the day just before the sun sets or after it rises, when the light is redder and softer than usual so that photographs taken in it have a pleasing quality.

But there is also the golden hour when it comes to corporate meetings. It is a 90 minute window where the three major time regions can all get together for calls, its usually mid afternoon for Europeans, first thing for the Americas and just in time for the final meetings that Asia/Pacific are willing to do.

It’s most commonly between 2:00pm and  3:30pm G.M.T., and for most international companies and projects its packed. I myself have a record of 9 concurrent meetings during this time period.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

 

  1. Which is Europe, Middle East and Africa[]
  2. Which is North America, South America and Canada[]
  3. Which is the Asia Pacific region[]

Management Nugget No 20: Use the Delayed email sending feature

When you’re managing a project or just doing managerial stuff in general and are working with people who are not management and are feeling a bit twitchy 1.


Use the delayed email sending feature, this is available out of the box on all modern email systems, and when you are doing late night/weekend or out of hours emails, its a great way of not being a jerk to those working for you.


Most people in this always-on corporate world or those supporting a 24/7 system will interrupt what they are doing to glance at an email or notification and unless you need a response right then and there for something that will have a serious impact before the beginning of the next working day, this is something you really don’t want to do as it shows you are dismissive of others time.


While you as a manager might think it shows you are dynamic and on the ball to your bosses, it really does not work the other way.
Additionally “the right to disconnect” style laws are spreading and becoming more common and this will help you provide that for your teams.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

  1. mainly support or those that look after production systems in any way[]

Corporate term: “Curry House Flower”

Definition:

A “curry house flower” is an item that was once only an extra to a process, but becomes mandatory to retain the customers satisfaction.

Explanation:

This is a really old one that I hadn’t had cause to dredge up for years.
A “curry house flower” comes from a scenario that was explained to me at General Electric back in the 90s. its a occasional gift to go above and beyond for a customer. But if given too often becomes an entitlement when it has no relevance to the core deliverable.

In this scenario, you go to your favourite curry house and order your favourite curry, you’re walking out perfectly satisfied with the transaction and looking forward to your food when they present you with a flower at the door to take back to your loved one.
You’re really pleased with this gift, it has nothing to do with the curry but it’s nice to have. The next time you go for a curry, the same thing happens, and you come back with both the curry and the flower, this continues two or three more times.

Then they stop giving you the flower, for whatever reason. You come home with only the curry and you’re now dissatisfied with the curry house.
You form a negative opinion on it. You still have an amazing curry and your original purpose in going there is still being achieved, but now you’re unhappy because you didn’t get your freebee.
In the corporate world, this is often seen in terms of large third parties who build gigantic and beautiful weekly PowerPoint status reports, they have dedicated people spending ages on them, and the cost is not seen because its a tiny line item in a gigantic project.
Managers get used to these beautiful, maximum effort presentations on what is a simple status report. but if they stop getting them because they have moved to another vendor or gone internal, or there’s a budget cut.
They become massively dissatisfied with the delivery on the project because they have not received a fancy gift with what is a well running project.

 

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.