“Accept Nothing But All 5s” on Customer Satisfaction Survey?

I recently ran into this situation at my truck dealership after a routine maintenance. I got handed a “How did we do?” customer survey. The service technician looked me in the eye and said in all seriousiness, “Please give us all 5s on our survey. That scoring affects our salary and employment. Anything less than 5 is considered unacceptable.

Sadly, this situation happens far too often. And I would argue hurts performance. The wrong thing is being taught and applied here.

My argument is, if your organization’s goal is for a customer to rate you a 5 every time, you’re actually setting your team up to fail to meet impossible goals.  Why?  Because it’ll be biased.  How do I know?  Experience, doing IT Service Management for 30 years.  Let me explain:

Opinion #1. The minimum acceptable metric should be a 3.   “We met the project requirement, and the engagement was good”.  Most vendors should ask for feedback here as 3 is the “met expectations” rating.  Not a bad rating, but ultimately your wanting to make investments in training and customer service to drive towards a 4.

Opinion #2. When thinking of goal metrics, 4 out of 5-point rating system should be the target.  “We exceeded expectations with the project and the engagement was very good.”

Opinion #3. A 5 should be a rare occurrence.  Heroic-level performance.  “We far exceeded expectations with the project and the engagement was amazing”.  If your people do 5-level work, then reward them with bonus and recognition when it happens.  Handing out 5s should only be rewarded when the team is being exceptional.  Handing out 5s every day diminishes its value.

The way I view CSAT is:

  • 0% = Score 1, Poor  (We failed the customer)
  • 5% = Score 2, Average (We missed the mark, we need to improve)
  • 50% = Score 3, Good (We hit the mark)
  • 40% = Score 4, Very Good (We hit the mark and the customer is very pleased)
  • 5% = Score 5, Excellent (We crushed the mark, the customer loves us, and we are heroes)

If you want people to work harder, incentivize through real feedback and set customers’ expectations appropriately, so you’re driving down the organizations’ desire for bias, such as “We need to be all 5s, all the time”.  I have not encountered a system that expects all five to actually drive human performance, team. Burn out, frustration, and growing distrust of leadership is often accompanied by these expectations.

Do I have this wrong? Let me know where and how.

\\ JMM

Hiring Only Employed Candidates vs. Training New Ones

“CEO has given us strict instructions to not hire people without an existing job, as we have been burned by candidates saying anything to get a position and then become a flight risk later.” – Redacted

That conversation happened many years ago and I’ve witnessed strategy hurting the company more than it helped. The job market for IT talent has been hot for the majority of my career, so, handcuffing HR this way won’t ensure a steady flow of talent. It’s time we think about developing new talent.

Question: Where do people entering into the job market learn basic business skills? IT employers expect the basic skills, like word processing, email, spreadsheet capabilities. But, customer service, how to communicate, performance goals, business acumen, all not taught.

Argument #1. This is what college is for. In my experience, a bachelor’s degree does not guarantee the candidate has any customer service capabilities, is an effective communicator, or has any business acumen. Not a hard rule, but time and time again, I have seen degrees leaned on but frustratingly don’t pay off.

Argument #2. We don’t have cycles or resources to train new people. This is the heart of it. We are busier now more than ever. And frankly, even seasoned people are having to re-learn the mechanics of how a company operates as they move. Again, similarities can be drawn (ie, information technology fundamentals are the same), but not investing cycles disengages the employee.

Argument #3. We can’t afford to train them, they could leave. I thought this was a joke when I first heard this 20+ years ago, but this is a common post on LinkedIn still today. Culture is king. Good culture means engaged employees + tasked with challenges + paid competitevly + constantly learning and growing = less likely to leave.

Many employers will teach the technical skills. Fewer teach leadership skills. Even fewer invest the time to teach employees what the business does. Even fewer teach employees what professional means in the workplace.

This is an interesting problem. Probably easier to hire talented people with experience. On one side, we shouldn’t complain about the lack of talent if, on the other side, business is unwilling to train and grow the next generation of people.

What’s your perspective?

\\ JMM

America’s Got Talent, Just Not Enough…

I just got an email from a recruiter with the subject line “America’s Got Talent, Just Not Enough.”

There are volumes of LinkedIn posts about the problems with employers, unrealistic job descriptions, and expectations.  So this post isn’t about that.

I have hired hundreds of people in my career.  While not all of them worked out due to a variety of reasons, most did.  Here are my top 3 observations based on today’s lightening hot IT job market, remote workers, and life with COVID.

#3. Misses Opportunities to Grow.

Granted, 2020 was a barren year. 2021 a few steps better. But so many employed candidates chose to not educate themselves or grow in their existing or desired profession during those years! Top excuses:

  • Covid Anxiety! You hibernated for 24 months?
  • Didn’t Have Resources. Put any effort in to find any? So many free ones out there.
  • Employer Didn’t Tell Me To. Uh, what?

Red Flags:


  • Work On Education. Take some virtual classes . So much free content out there.
  • Work On Labs. Used gear is aplenty these days. Get a lab up at home and a study book and get cracking.
  • Work On Certification. If mastering a skill, why not get the certification to prove it? No excuses. Focus and get it done!

#2. Forgotten How to Interview.

T-Shirts, unshaven, and bad language rise to the top of notable bad behaviors. Here is my advice on getting back to being an ace on interviews:

  • Dress for the job you want to have. Whether virtual or physical, put some effort in your appearance. Personally, I like the shirt and tie look for new IT professionals. Seasoned IT pros can get away with the turtle neck or polo.
  • Cleanup for Interview. Beards are in, yes. But, uncombed hair? Unbrushed teeth? 5’oclock shadow? Just got out of the shower? No. Attention to your personal hygiene often parallels to attention to detail and ability to execute, especially in manager positions.
  • Dropping the F-bomb. Which usually comes an apology right after, but again, how we communicate, verbally and in writing, equates to attention to detail, interpersonal savvy, and culture fit. Profanity should be minimal if not zero.
  • Read Lou Adler’s Book: Hiring & Getting Hired. Off all the books I’ve read, this one rises to the top year after year. $1.44 on Amazon used paperback. $9.99 on Kindle. No excuse.

#1. Undersell You By Submitting a Poorly Written Resume.

Reading resumes does take experience and wisdom. In 2021, I’ve seen an upswing in really bad resumes. Here are the top mistakes I’ve noticed:

  • Lots of Spelling and Grammatical Errors. One or two can slip, but 10+?
  • Poor Formatting. Think really hard before downloading the Microsoft resume template and filling out.
  • No Notable Achievements. Most people just list where they worked and what their job duties were. But what did you achieve while you were there?
  • Lots and Lots of Product Skills. Listing 100+ products you have used once or twice doesn’t mean your a product expert. Or even your experienced. It becomes clear on the physical interview padding is occurring.


  • Hire A Resume Writer. Investing in yourself. Expect to pay as $200, as much as $1500.
  • Read Resume Writer Blogs. There is so much advice out there that can help you.
  • Ask Your Family To Read Your Resume. Mom, dad, brother, or sister have a career? They may be a really good source for consulting.

Unsponsored Plug: Lisa Rangel with Chameleon Resumes is my favorite Resume Blogger who also offers webinars on multiple resume topics. “The Real Deal”.


The Glut of Repetitive “Cyber Security” Webinars

I like to be informed on whats hot in cyber security. Most of the time, it’s in the form of webinars. However, after this week, I realize after attending five “How To Improve Your Cyber” events, exactly the same advise was repackaged and presented:

  1. Patch Your Systems
  2. Backup Your Systems
  3. Harden Your Systems

Let’s Take Colonial Pipeline

Anyone doing a webinar on how exactly Colonial Pipeline got hacked? What tools were they using? What security framework? How big was their security team? Outsourced or SOC? SIEM? EDR? Automation?

“Disclosing these technologies would be a security vulnerability in itself. No company is going disclose security details”

I totally get it. But let me challenge you on this: Are you teaching people how to fish or just telling them to fish?

Most of these cybersecurity webinars are telling people… not teaching.

Be prepared for harsher feedback, because educating cyber leaders and pros with arguments substantiating the same advice is repetitive and making me want to not click “register”.

\\ JMM

Hosting Upgrades 2020

This week, we’ve moved the website from NameSilo hosting over to Greengeeks.com

Deployment of Let’s Encrypt SSL certificates to the website was the big reason for the move. I am very surprised by the web hosting orgs that don’t provide this solution for the one website customer.

\\ JMM

Why Are Some MS SQL DBAs Resistant To RBAC?

A question for education purposes.  Historically, MS SQL DBAs are resistant to RBAC strategies involving integration with Active Directory (AD). In other words, controlling permissions to DBs via a AD role based access control groups is met with considerable resistance by DBAs. And some legacy application owners, to be fair.


Some context:  Microsoft released a video in 2011 during TechDays outlining an RBAC strategy that has worked in previous organizations, both small and large.  Very popular video.  Once decided that is the strategy, getting that philosophy into practice has not been easy.  It usually starts with the on staff seasoned IT pros looking at RBAC with suspicious and doubtful eyes.  “I’ve never done it this way” and “I doubt this will make our jobs any easier”.

Nevertheless, once the concept takes hold RBAC begins to see fulfillment.  Foremost adding predetermined resources to roles accelerates onboarding, easier to audit resources, and scales elegantly as we grow as roles are the focus.  Typically, architects and server teams get on board first.  A standard is born and acceleration begins to be felt, including shifting left where DBAs are doing less security permissions requests as those are now handled by the helpdesk.  In the meantime, slowly and begrudgingly, outliers come on slowly as this strategy does shift stances from caring for the security of their apps like pets to managing access to resources by role.

I posit these reasons, given to me as why DBAs (or application owners) want to go it alone:

5. Microsoft isn’t always right.  “There is more than one way to do it and the “video” isn’t applicable to SQL”.

4. The amount of work to shift to resource-based groups.  “Lots of groups.”

3. The complexity.  “Easier to troubleshoot when I own the DB or application’s security intimately.”

2. Fear what they don’t understand.  “I’ve never done security permissions like this, so it must be wrong.”

1. Territorial control.  “Don’t touch my DBs”.  Uncomfortable shifting left.

This is very much a pets vs. cattle conversation.  I acknowledge and appreciate SQL must be tweaked and tuned to operate at it’s best performance.  However, I disagree that treating ‘access control to resources’ like pets accelerates IT service delivery, provides uniformed information security governance, and ultimately is healthy for the organization.  Especially as organizations’ scale.

What is your opinion?

\\ JMM

PS. More and more companies are using automated access control oversight tools such as Sailpoint. And at a previous company, guess who fought the hardest against that move? DBAs… Why?

Signs of Failed Knowledge Culture

Every now and then I encounter interactions and communications that lend suspicions the team members are not managed from a knowledge culture mindset.  Reactionary behaviors are typical in so many shops to appear to be the norm.  Very similar to the stressful read from the famed novel, The Phoenix Project.

It’s unsettling to witness.  I espouse the necessity of a knowledge driven IT culture.  Equal bits of knowledge worker, knowledge management, and DevOps.  It’s unlearning bad behaviors and replacing with knowledge-based behaviors.  Teams who understand this dynamic see workflow acceleration.  Teams who do not understand…frustratingly do not understand and are friction prone.

This article talks about my top five signs technical teams show symptoms of failed knowledge culture.

#5.  Don’t understand the purpose of Tactical meetings.

“Why do I care what desktop support is doing?” or “I’d rather get an email, this is a waste of my time”.

Death by Meeting is a schematic for managing meetings.  The purpose is to ensure people are communicating together and tactically.  Intentional leadership is necessary to build a values-based culture.  This includes having a meeting.  In the above examples, these comments indicate not just a missing values culture, but missing alignment to IT or business goals and missing identifying their contribution to those goals.

For example, desktop support might want to know what systems engineering is doing that week, especially if it may impact that team.  Proactive knowledge replaces reactive behavior

#4.  Not tracking key performance indicators.  Metrics vs. KPIs.

“These reports mean nothing to me” and “Just another TPS report…”

There is a stark difference between generating metrics and the purpose of a key performance indicator (KPI).  Tools are usually great a cranking out metrics of every kind, useful and otherwise.  However, KPI’s tie to goals.  And if you’re not measuring team performance against KPIs, then you’re not measuring performance.

For example, I argue total tickets closed by technician is a KPI.  I challenge better KPIs measuring performance are average time a ticket is closed, ticket aging, and authored knowledge article reads, preventing the ticket from being opened in the first place.  Performance is often more important to measure velocity of success versus quantity of success.

And if you’re not surfacing team KPI performance in tactical, leaders are missing epic opportunities to cohere the team.

#3.  Argumentative as to medium of how KPI’s should be consumed in Tactical.

“Why do I care how much CPU the PROD environment consumed last week?” or “How many laptops are in inventory” and “We need to eliminate the noise”

Couple of key points to make.  First, I recommend teams starting out that getting members in the habit of measuring by reviewing metrics is a first key step.  Metrics quickly replaced with KPIs tied to IT and/or business goals.  Leadership is responsible for developing KPI targets.

Second, there is no right or wrong way to approach the consummation of KPIs.  That building phase usually manifests as PowerPoint slides or a reporting website from the tool.  I lean slides as I like to treat as a meeting with minutes and keep for historic purposes.

Third, cadence and tone of the meeting being set, there will always be overlap or measures, arguably, less valuable to few people.  As teams cohere to common KPI, it’s not horrible waste of time to spend a few seconds listening to KPI from follow teammates.  Use to recognize the work and appreciate milestones.  Moving the team in the same direction often requires acknowledging.  Nevertheless, leaders should ensure it’s being done reliably and consistently.

#2.  Doesn’t understand the knowledge culture fundamentals or values.

Lessening fire fights by lowering reliance on technical constraints is a key point made in the Phoenix Project.  There are two team member behaviors that I’ve witnessed that hinder lifting burdens from constraints:

Behavior #1, “Don’t want to do it”.  Shifting left, or moving towards self-service knowledgebase, is a cultural shift.  Some team members won’t get aboard the train to promote knowledge cultures.  They don’t want to write, they don’t want to share, and shifting left is met with skepticism.  Come to work and go home and/or “been doing it this way (unhealthy) for XY years” is the key behavior trait.

Behavior #2, “Don’t have the time”.  Expectations continue to heap on IT pros, true.  But, leveraging as a crutch to get out of their responsibility is a nasty behavior.  Often citing, “too busy” to embrace new policies and processes.  Too busy to write standards and knowledge articles.  Too busy!  Yet, first off to lunch, first to leave for early weekend.  First to waste time is the key behavior trait.

Leaders need to coach with expectations defined.  Else, release the team member.  Caustic cultures catch on like wildfire.  So, its critical team members have the right attitude, so to focus on goals and not the bad culture.

#1.  Leadership not aligned; how can employees be?

Be skeptical of the unread IT leader.  If Phoenix Project, DevOps Handbook, or Measure What Matters wasn’t on their read list, how can knowledge culture take root?

In my experience, I’ve been told culture is nice, but not as important as revenue, customer needs, senior leader desires, or what ever the fire of the week is.  In other words, leadership conditions itself based on treatment amongst the peer group or top-down treatment.  Culture does start at “the top” and if leaders do not embrace, there is no chance.

Looking at most successful companies, “culture” is king influences revenue, customer needs, and how leadership treats itself and direct reports.  Few companies realize good working cultures due to leadership not aligned to knowledge values and the consistency to stick with it.

What are you doing to drive knowledge culture?  Are you pushing positive proactive knowledge behaviors with your team?

\\ JMM

If you look good, you play good. If you play good, you will get paid good…

“If you look good, you play good.  If you play good, you will get paid good.”

Cam Newton, Panthers

Grabbed from Amazon’s “All or Nothing”, 2018 Season… Yet, this post isn’t about the challenges Cam is facing health and performance wise. Watching the show, Cam seems to have an acute understanding about the importance of performance and delivering.

It’s something many technology people do not seem to understand. Still.

As a long time leader of teams, this personality pops up either through inherited hires or the “transformer” hire (great interview, bad performer — you’ve been there, right?)

I’ve witnessed it as early as this past week. The typical scapegoat is “culture” or “leadership”. Reasons their career is in jeopardy and the hand that was dealt was somehow unfair. “Bad leaders!” Quite the contrary.

Not surprisingly, businesses and leaders put up with a lot to deliver excellent service. The best companies seem to put up with less overall, but I digress. In the majority of these cases, the why is conveniently left out.

Here are the top 5 issues I see routinely from low to mid performers:

5. Begrudging participation. Barring critical incidents, the reception getting the team together for team meetings, cross trains, or the occasional after hours events is either good or not good. This includes things like knowledge culture and documentation too! Usually a first sign of an iceberg ahead.

4. Poor execution > good execution. Catch that? Not superior or perfect execution. Just good, folks. Poor execution being the norm is donkey behavior, not thoroughbred behavior. Superior preparation. Knowledge builds confidence.

3. Not life long learning. Does not include Google search alone. If your in the support and engineering fields, what are you doing to keep yourself educated on technology? On the job and reading blogs is not enough for the big money. Certifications demonstrate mastery in lieu of decades of experience.

2. Not Understanding the business. Do you know how the business works? What we sell? How your role impacts customers?

1. Attitude Problems. Negativity doesn’t sell. It paints not just you badly, but your team members. And your boss. Blaming the company, the management, your peer group, your family life, the government… not thoroughbred behavior.

There are many excellent information technology people out there. I would argue the majority of this career field leans par to above par on performance. It’s the below par people we are talking about — you know who you are.

Let’s try coaching and correct the course. Talk to your leaders and determine if it’s truly a bad fit versus “you”. Find a mentor. Need feedback. Stand out!

Because if you play good… You will get paid good.

PS. When I wrote this blog, I immediately thought of the above episode, Picard getting a performance eval from Riker and Troy. “Stand Out. Take Risks.” I feel it’s important to underscore taking the right risks versus any risks.

\\ JMM

Turbonomic, Economic Theory, and Disaster Recovery…

A big fan of Turbonomic. From the mailbag:

From: Jonathan Merrill
Sent: Wednesday, March 18, 2020 9:19 AM
Subject: RE: Lanvera & Turbonomic – VMware discussion and Turbo Instance check

Good morning, guys.  I lurked on yesterdays’ call as I felt Sonny did a great job working through LANVERA’s positions.  I say Turbo has been a win for our organization.

One argument to leave you with.  As you may know, Turbonomic smartly trains ACE in economic terms, specifically the idea of markets, desired configuration state, utilization buying from the lowest provider.  Based on our conversation yesterday, a conclusion was reached that Turbo isn’t the right product for unplanned disaster recovery, this is what Veeam, Zerto, and SRM does.  Economically speaking, you’re saying the product isn’t poised to correct for sudden market volatility, a change of market conditions.  I say, rubbish.  Apply economic theory:  Keynesian vs. Friedman.

I would reason Turbonomic should be able to apply Keynesian theories, as I control the markets’ foundation and worth by submitting an economic plan.  For better or for worse, if I want one market to look less appetizing than the other, I submit a plan and the markets react, utilization buying to the lowest provider.  Which essentially is what LANVERA is looking for.  I want to move workloads from one data center to another.  I want to be able to control all workloads in one DC to shift to the other side through “an economic plan”.  I should be able to define market strategy to meet a planned economic market outcome.  I see this as a basic Turbonomic function.

I also contend Turbonomic should be able to support Friedman’s theory, which is best poised to handle market volatility.  If a host goes down (ie, consumers stop buying), the market adjusts by triggering economic stimulus (disaster recovery hosts or moving workloads to the DR side).  This reactionary economic plan ensures desired configuration state in tough economic times, and could include cloud (foreign) markets (not in our case).  Alarms should go out when market volatility occurs and adjustments should be made at the workload level (consumer).  Essentially what LANVERA is looking for.  I should be able to define disaster (market) recovery plan which basically outlines where workloads go during unplanned events.

Maybe that means trigger SRM or Veeam Orchestration.  But you see the problem with that right?  Unless your hooking into those tools and pulling the strings, the response time still requires human intervention.  Not ideal.

Food for thought.

Anyone else think Turbonomic could replace SRM? This is what watching YouTube financial video watching does..

\\ JMM

Managing involves measurement, doesn’t it…?

“We wouldn’t even know how to measure what healthy looks like. When we have a problem, we just know it’s resources.”

A Developer, Collaborating a slow application issue.

I immediately perked up at the man’s comment. It’s one any seasoned IT pro with server and storage background can identify with. And it annoys today no different than when I heard it years ago.

The relationship between development and infrastructure teams have historically been… professionally difficult. Nevertheless, in the age of DevOps, agile, and automation, this problem of developers vs. infrastructure still exists at some levels. And, in my experience, the root cause is typically the same: a lack of understanding how and what to measure.

Let’s take a common sample: An in house developed business application begins to get slow after load. The application works well under artifical testing workload. Passes quality and security testing. It’s released into production, but as the business grew, the application’s workload exponentionally grew despite no changes to the application.

Through the lens of the five stages of grief:

LevelThe Business Says…Developers Say…IT Says…
The business is growing. Keep the application healthy as we grow.Nothing wrong with the application. Application just needs more resources.Somthing is wrong. Resources are finite and can’t infinitely scale. As demand goes up, soft argue requests.
Clients impacted randomly, jeopardizes revenue. “This is unacceptable!” Sales and Executive team anger palatable.“Just give it more resources!” demands development. IT is at fault because they are slow to react, although recognize applications limits and technical debt growth. Will fix one day…“Iceberg ahead!” Technical debt grows. Business and development are at fault because they don’t understand workload vs. timing of resource vs. limits vs. financial realities.
“3” BargainingIf only the technical teams worked better together. Blame development and IT leadership for failures. Deny technical debt reality, priortize features over scale.If only the business recognized earlier the technical debt so developers could improve the application to scale. If only IT would be more supportative so development didn’t have to perform support.If only leaders would recongize the effort IT is trying to keep the application working, which is turning into a support nightmare. Morale low. People leaving.
Impacts on top of slow sales cycle lead to short tempers and broad opinions based on perception / feelings. Not data.Developers take a beating as primary causes for failure. Morale low. Talented developers begin to leave. Technical debt begins to be worked, slowly.Culture isn’t sustainable as we grow. People and process ignored as blame and fingerpointing ensure. Nothing based on data.
Option 1. Things Stay The Same. Culture, processes, and people remain unrecongizable or admitted problem areas. Status quo.Option 2. Things must change. Recongition to change, but how to change? Confusion and lack of alignment ensues.Option 3. Things do change. Leaders commit to mission and vision, collectively. Measuring and alignment replace confused culture.
I stole this table from a college class, which the professor underscored not just the business disfunction, but the importance of data making business decisions.

The point here is managing things, including developed applications, based on perception and/or reaction is not managing. It’s guessing. And when it works out where the thing is not a problem — the guess paid off — everyone enjoys feeling good. The “avoided bullet”.

But what about when it doesn’t work out? Take the quote at the top: “We wouldn’t even know how to measure what healthy looks like.” That is a serious flag on the field. If you don’t measure health, you can’t manage the patients’ health care. As we all know, unmanaged health care means shorter lifespans. Despite ownership.

Calls to action are:

#3. Every single piece of technology deployed must be (1) measurable, (2) being measured, and (3) react “able”. What does healthy and unhealthy look like.

#2. Every development project must have requirements outlining measurements of health, particularly what success and failure looks like. Evaluate peridoically to adjust to business climate and workload change.

#1. Leaders must commit to the culture of quantification by measuring business performance. Start with key performance indicators (KPIs) tied to business mission, goals, and initiaitves. Start with departments that don’t (won’t) measure will be instantly assumed to be failing.

\\ JMM