This is the act when giving a presentation of merely reading the slide out verbatim, normally in a flat tone, as if you are just saving the other attendees from actually reading it themselves without bringing anything else to the presentation.
Explanation:
This is caused by people not knowing how to present their slide deck and so just reading from it. If you have been asked to present a slide deck, use your slides as speaker notes rather than a script, add some feeling to them, so you do not bore the hell out of everybody. If people you know ‘drain the slide’ and just read out everything verbatim. Suggest they get involved in any form of community event. Be it business or technical and start to present on their speciality subject, the feedback and experience from actually doing proper presentations will cure this problem quickly.
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.
White glove service, is a service offered unofficially within a corporation or large company for items that are classified as important from a business or process point of view, but don’t have a genuine importance from a hardcore finance or business impact.
An example of this would be if you had an issue that would stop a project release to production. This is very important to a project and to the leadership team, but does not result in an immediate financial or regulatory cost to the business. Therefore, you could not merely raise it as a Severity 1 issue, and let the existing incident processes manage it.
These needs however are important, but not in a traditional sense, and you need what is often called a white glove service to deal with them.
What does a white glove service consist of?
A white glove service consists of a number of allocated, named individuals. These then take responsibility for issues, they will own such issues and work with the stakeholders or people that raised them to ensure that they are completed.
At no point until the issue is resolved can they let go of it, even if it’s beyond their control, they have to hold on to it until It’s completed.
They do this by ensuring departmental walls are breached to reach a solution.
They consistently provide reports to the stakeholders, even if there has been no change to report (often the update period required by a stakeholder is far more frequent than there are updates to provide). Communications, however, must be managed.
They must be effectively on support call. There is no clocking in and out if an issue is raised, regardless of when it is, they must respond. (It is recommended that there are at least 2 named individuals for each of the 3 main global time regions. Asia Pacific, Europe, The Americas to cater to this).
They must maintain trust between the different areas of the corporation , if such a person comes seeking a teams assistance, it will be for a genuine reason.
If the issue is caused by a process or other genuine reason (and not merely poor stakeholder and management planning), they must produce a root cause once it is complete.
Skills needed:
Strong areas of knowledge: it must be at least 2 of the following:
Business process knowledge and what is important to the business.
I.T. knowledge in order to be able to negotiate with the various silos within the corporation
Internal process knowledge, who to go to, where to go to, what processes need to be done in a perfect world,
Things a White Glove service must not do:
Use up the time of valuable subject matter experts: they must not occupy more time than they save for existing resources, and should stand in for technical and business people on calls to actively free up time to complete requests.
They must never be seen as a threat, only as an assist. They must never use words like escalate or name drop, or anything that triggers a defensive reaction.
They must not devalue existing processes and people, to do so will just make the problem worse. They must always be someone who can explain the truth to power.
Just become a status report proxy, they do not ask subject matter experts to do any admin tasks, they take on such activities e.g. ticket raising, and allow experts to complete genuine work.
How do you get people to do this pain in the butt role in a corporation:
For External Staff Members: Money normally does it for both independent contractors and vendors; they are happy to do this function and do it well if the price is right.
For Internal Staff Members: A stint on the ‘white glove’ service grants broad understanding of your company’s needs at a practical level and shows commitment, this can be used on yearly evaluations, and helps to identify people who should be fast tracked.
Three vendors in a trench coat is basically a way of saying that a department or function inside a corporation is merely a front for a bunch of vendors trying to get as much money out of you as possible, rather than being a genuine internal department.
Explanation:
This is a corporate corruption of the classic three raccoons in the trench coat, which basically means a group of slightly deceitful critters pretending to be something greater and better than they are.
In a corporate world with so much outsourcing and so much cost cutting paired with the difficulty in getting and retaining internal resources, often support functions or other areas merely become a thin veneer of managers or permanent members of staff over a huge number of outsourced vendors.
This can mean that simple costs can escalate radically, and even asking for a minor item that should be classed as business as usual, can result in a hefty bill that you are not expecting.
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.
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.
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.
