This is extracted from a real, actual conversation from this past week.  Names have been obfuscated to avoid being litigated and imprisonated, er, something like that.  Anyhow, grab your popcorn and enjoy!

Customer: “What are the new Dev and Test environments going to look like?”

Architect: “They will look exactly like the production environment, except that the domain names will end with ‘.dev’ and ‘.test'”

Customer: “But how will it be configured?”

Architect: “Exactly the same as the production environment, except that the domain names will end with ‘.dev’ and ‘.test'”

Customer: “Do you have an architectural diagram for each, so I can get a better idea of how they’re going to be configured?”

Architect: “Did you receive the design document for the production environment?”

Customer: “Yes.”

Architect: “Did you have a chance to look at the diagram in the design document?”

Customer: “Yes.”

Architect: “Dev and Test will be exactly the same.  Including the diagrams.  The only difference will be the domain suffixes.”

Customer: “I would still like to see a diagram to better understand.”

Approximately 30 seconds of complete silence…

Architect: (softly) “I’m not sure what you really need.”

Customer: “I would just feel better having a diagram.”

Architect: “Like the one shown in the production design document?”

Customer: “Yes! Exactly like that!”

Architect: “Dev and Test are identical.  Only the two domain names have different endings.”

Customer: “Ok. I understand.”

Architect: “Ok. That’s good.  Are there any other questions?”

Customer: “So, when do you think you could send me the diagrams for the Dev and Test environments?”

wash. rinse. repeat.

The State of IT Work in America

Disclaimer:  This is scientifically indeterminate information. Statistically unfounded, and somewhat anecdotal.  I would use more adjectives and analogies, but my coffee ran out hours ago and my dog just tried to eat my cat.


What is This?

This article is a summarization of data collected from customer engagements working as an IT consultant over the past calendar year.  The information is taken from notes that are primarily intended to provide scoping around specific IT projects.

After reading so many Forester and Gartner reports, as well as internal assessment emails from various customers, I sometimes wonder if they suffer from the Heisenberg principle, or if they focus on alternative motives, I really don’t know.  I wanted to at least try and put a stick in the ground and point at it while mumbling.

I’ve made every effort to translate my notes into this compilation, but I cannot share the actual names or identifying information due to serious legal risk (there’s a white van circling my house… right…. now…)

Business Types

(just the ones I have personally connected with)

  • 3 municipalities
  • 4 hospitals
  • 4 manufacturing
  • 5 retail corporate offices
  • 3 health insurance corporate offices
  • 2 luxury goods
  • 3 food processing
  • 2 food service retailers
  • 1 railroad company
  • 1 cloud data center hosting company
  • 2 financial services companies
  • 5 banks
  • 2 chemical processing companies
  • 2 engineering firms
  • 10 legal firms
  • 1 household products company
  • 2 defense engineering companies
  • 1 electronic circuitry designer
  • 1 sports franchise marketing firm
  • less than 20% are publicly traded
  • and a partridge in a pear tree

IT Organization Sizes

(just my own personal involvement, not our company as a whole)

  • 50% – 5000 devices/users or less
  • 25% – 500 devices/users or less
  • 20% – More than 5000 devices/users
  • 5% – More than 10,000 devices/users
  • Smallest = 60 devices
  • Largest = 185,000 devices

Infrastructure and Platforms

(very approximated numbers)

  • 100% are Windows Server Active Directory environments
  • 50% are using cloud services currently (AWS or Azure)
  • 90% are using VMware datacenter products
  • 75% are using MDT or SCCM
  • 40% of “new” SCCM customers are on current branch
    • 50% of the rest are preparing to upgrade
    • 50% of the rest are scared to death for no reason
  • 90% are still using Windows 7
  • 80% are actively deploying Windows 10
  • 10% are actively deploying Windows Server 2016
  • 30% are actively deploying EMS/Intune, Azure AD Premium
  • 95% are actively deploying Office 365 and Azure AD
  • 50% still don’t understand Group Policy
  • 90% still assess configuration controls via a product-centric perspective (bad)
  • 80% still don’t document Group Policy changes
  • 90% have switched from Batch or VBScript to PowerShell
  • 95% are using Symantec or McAfee antimalware products
  • 35% are using, or trying to use, disk encryption (e.g. BitLocker)
  • 5% using other endpoint management tools (e.g. LANDesk)
  • 80% of SCCM owners still don’t understand ADR’s
  • 99% of System Center owners still don’t know what Orchestrator does
  • 75% of SCCM owners still don’t understand thin, thick or hybrid image concepts
  • Observations:
    • Most are excited to get to Windows 10 as soon as possible
    • Most are excited to upgrade SCCM when they learn how it can help them get to (and support) Windows 10
    • Most are frustrated with the gaps in Cloud technologies, but mostly (always) due to assuming it’s a “done” technology, rather than an evolving one.  Examples: SCCM/Intune integration, Azure ADDS.
    • Not implying these are deficient or faulty products.  Just that many customers expected everything is available to “switch over” right now, when many of the expected features are not quite ready.

Roles and Functions

  • Breakdown of those I’ve worked with:
    • 60% mid-level operations
    • 30% senior-level operations / architecture
    • 9% executive management
    • 1% whoever answered the phone
  • Observations
    • Vast majority would state they are providing two or more distinct job functions, many stating 3 or 4.  In most cases, each role would have been a distinct job position five years ago.
    • Most of the role-compression has been the result of passive attrition, small percentage from active attrition.
    • Almost all (actually only 1 exception) stated they are expected to respond to business requests after normal business hours.
    • Most of the preceding group still don’t know how they got tricked into doing that
    • Almost all (3 exceptions) are salaried, rather than hourly.
    • None were compensated for overtime hours, but were allowed flex/comp time as make-up.
    • 75% received a small raise in the last three years.
    • 25% had no raise in over a year (usually department or company wide)
    • Only 3 or 4 had received any monetary bonus payouts in the last three years.
    • 75% stated that they feel IT is a reactive, not a controlling, force within the organization.
    • 10% of SCCM owners still have managers that are afraid SCCM will automatically reimage every computer in the organization one day without notice.  Because they heard from a friend of a friend how it can “just happen”

Job Tiers

  • Almost all organizations use a seniority-based model for assigning job titles, rather than a functional or role-based model
    • Most engineers are doing administrator work
    • Most architects are doing engineer work
    • Most technicians are doing administrator work
    • Most Administrators are asking WTF?
  • Lower-paying roles are difficult to staff to meet customer SLA expectations due to ability-versus-upward-mobility challenges. (e.g. top-performers rarely want to remain in help desk or call center roles longer than they feel necessary)
    • The exception to this seems to be tech-focused businesses, like datacenters, software development, etc.  Roles and functions didn’t seem to be as caste-oriented as non-tech-focused businesses.
  • The quality and aesthetic appeal of the work spaces seem to relate to the overall “happiness factor” as far as I’ve seen.
    • Offices with play rooms, sofas, cafeterias, free vending machines, etc., often have more workers walking around in a good mood.
    • Offices with a roach infestation, dead bodies, and yellow-ribbon across doorways, tend to have fewer smiling workers walking around.
    • Very very very few unhappy telecommute workers.  But that may be due to encountering very very very few telecommute workers.

Work Patterns

  • Just read “The Phoenix Project” up to chapter 23, and that’s pretty much how most organizations seem to operate.  Continuous effort to maintain.
  • Most have said that proactive, innovation-oriented work is considered a luxury.
  • Company-paid training is noticeably less available than it was 5 years ago.
  • Reimbursement for certifications continues to be available at most organizations


  • If you like getting prostate or cervical exams with a garden shovel, you are probably a good fit for working in IT as of 2017.  If a work-life balance of 90:10 is your thing, you’re probably going to excel.  If you thought “do more with less” only applied to home improvement projects, well, think again.
  • Are there still rewarding careers in IT?  Sure.  Based on this, obviously anecdotal, mini-slice of the world, I would subjectively propose that, in general, it’s heading towards a more rigorous environment than a more-creative environment.
  • Somewhere, somehow, it seems (to me, anyway) that there’s a growing disconnect between the IT staff layers, and executive management.  This varies widely based on the nature of the business, and the scale of the organization.  But regardless, it seems that the CIO and CTO roles are increasingly difficult to fit into the divide between business and technology.  Their roles are often aligned more closely to one or the other.  When aligned too close to non-tech, the technical side seems to suffer more.  But when aligned too close to purely technical, the executive layer (cultural) support seems to suffer.
  • Again, this is all subjective, anecdotal, non-empirical, non-deterministic, kerfluffery stuff.  Whatever that is.  I just needed to vent.  Been on 20 hours of phone calls dealing with everything from SCCM site problems to cats fornicating outside people’s hotel windows at 2am.  It’s been an interesting day.
  • Cheers!

And Now for a Word About Statistics

“Figures don’t lie, but liars often figure.” – Carol D. Wright


As a testament to how twisted my brain is, I LOVED statistics courses in college. I still do.  I had a 4.0 average (as I recall anyway), and immediately began applying it to everything around me.  Yes.  I’m that messed up.

So, why bring this up now?  Because statistical references play into everything around us.  From politics, to marketing, to work, to budgeting, to well, everything.  In this instance, because so many tech vendors use statistical claims to bolster their marketing charms, I decided to call them out.

Case 1 = “Fastest Growing ____!” claims

When someone says “such-and-such is the fastest growing __ on the planet!” what does that really mean?  Here’s what it means:

Divide the delta (value that denotes the change from state 1 to state 2 for the given time period) by the total number of state 1.  For example, going from 500 to 800 denotes a 62.5% change.  The rate aspect relates to the time period.  For example, if you said you were traveling at 80 MPH, but left off the H (hour) it wouldn’t mean very much.

In the same realm as velocity, a “fastest” claim denotes a velocity.  It implies “rate of change” or “relative change over a given time period”.

So, by itself, without a quantifier, it means very little.  In fact, it’s very often intentionally misleading.  That’s right.  Liars figure.

If a vendor says “Our product is the fastest growing on the market today!“, ask what the total counts (before/after) are.  If their product went from 1 license sold, to 2, that’s a 100% increase.  If their competition went from 100,000 to 150,000, that’s only a pitiful 66% increase.  Obviously their product is better than that pathetic 150,000-seat competitor, right?

Case 2 = Margin of Error

Another area that seems to get little attention (okay, zero attention) is the margin of error.  Often shortened to just “margin” or “MOE”.  This is the score that denotes uncertainty in the findings.  Put another way, the MOE denotes how far “off” the numbers can be, without violating the overall result.

This matters when the comparison between two or more items differs by less than the MOE.  In that case, it means the comparison is a wash.  That’s right.  The difference is so little that it should be considered meaningless (unless you’re aiming to prove indifferentiation).

For example: “Product A is favored by 52 to 48 over Product B” and MOE is 6.  That means it could be anywhere withing each being 6 units/votes/people/etc. higher or lower than the numbers stated. Pay attention to this when you see news or marketing (okay, typically the same thing) pitching something at you.

And now you know.

PS. Statistically, this article could be off by as much as 50% (MOE) 🙂

Windows 10 Landmines?

I’m on customer scoping call number 102 for Windows 10 and/or Office 365/2016 migration.  The pattern is solidifying as to where the the potholes, pitfalls, wormholes and landmines are typically found.


First off, it’s rarely a Windows 10 issue that causes the biggest challenges.  It’s more often that Windows 10 is the light that shines on hardware shifts and crappy coding practices.  In other cases it’s a matter of the project itself bringing attention to areas of the business that were neglected for a long time.

Landmine No. 5 – Plugins and Extensions

Office add-ins, IE plugins, extensions to Chrome and Firefox, and other parasites that suck the blood from their host applications.  Sometimes it’s more specialized than the wider-known products, for example, extensions to Adobe, Autodesk, and other vendor’s products.  The base product may be fine, but the overlooked extensions can jump up and bite the customer in the ass later on.

Landmine No. 4 – Local Admin Rights

Applications that *expect* users to have local Administrator rights are f-ing stupid.  Stupider than dumb.  Dumber than stupid.  In fact, any vendor that argues that their product “requires” the user to be a local administrator, on a typical desktop or laptop device, should be (get ready….) beaten with a pepper spray can, whipped with a chain made of razor wire, doused in white phosphorus and gasoline, ignited with a blow torch and stomped out by an angry, drunken rugby team wearing ice climbing boots.

And then re-ignited and repeat the whole process again.

If they refuse to comply with common sense development practices, find another vendor.   If no other products exist, hire some developers and make them yourself, the right way.  I’ve actually seen quite a few companies do just that.  When making the shift to “best practices” at the desktop level, this is when some of those shitforbrains applications pop up like wack-a-mole.

All I can suggest is this:  If you’re going to spend the time and money to make a major shift in the area of operating systems, don’t get lazy and drag along a bunch of bad habits as well.  You’ll never truly get the benefits of the upgrade unless you adopt the right habits along with it.

Landmine No. 3 – Office-Dependent Apps

The evilest of evil beasts lives in this dark cave: Microsoft Access Database “Applications” (yes, they call them “applications”).  They shackle you to the Access version, which means your Office migration plans now run into a forest of thorns and landmines.  The more you have, the uglier it gets.  Migrate them to “real” applications: SQL Server and some sort of decoupled UI/UX like VS project or a web app.

If your business depends on this “critical” beast, treat it like it’s really “critical” and put some work into it.  A business-critical application is like a house: build it to live in and live onward.  Toss out the plastic toy hammers, and buy a real hammer.  Access is a well-crafted, mature application, but it’s not a multi-user, business critical application unless you’re high on methanol and pig tranquilizers.

Landmine No. 2 – Hardware / Device Drivers

Applications that involve hardware peripherals or interfaces to hardware, are often the cause of Windows 10 migration hold-ups.  These are often found in specialized industries where the applications are very unique and specific to the business function, and not produced by big-name vendors.

For example, in a food processing business, the app that controls the old, rusty, belt-driven machine that grinds the rotting animal carcass scraps into a thick slurry of liquids with the label that says “high-protein supplement”.  That one.  The driver app or console, was written when Jimmy Carter was apologizing for the Iran mess, on a Commodore 64.

So you get a wet rag and wipe off the machine cover to get the phone number to “Jimmy Tech Inc.”.  You call and Jimmy answers surprised, as if nobody has spoken to him in decades and he thought humans had been wiped out in a nuclear Armageddon.  After he repeatedly asks for your name, you ask about Windows 10 compatibility.  He replies “Windows 10?  (long pause) Is this a prank?  Did Bill put you up to this?”  You try to continue talking, but his cats are stepping on his keyboard and he keeps stopping to talk to them using their individual names.  Then one of them starts eating his cold cup of ramen noodles and he drops the phone to chase her away.

Hang up.  Find a new product, or hire a hungry coder.

Landmine No. 1 – 32 bit to 64 bit

This has been the most common challenge to applications and drivers getting in the way of a smooth Windows 10 migration effort. In most of the cases I’ve seen, it’s really just basic application development issues such as hard-coded file system paths, registry keys, and even hard-coded component references (rather than installation or runtime referencing).  Organizations which migrated to 64-bit on Windows 7 or 8.x almost always skip right past this one, which is a good thing.

Outside of those lucky places that shifted to 64-bit earlier, the biggest portion of application compatibility issues I’ve seen thus far has been 32-bit apps and trying to move to a 64-bit environment.  Of all 5 landmine types described thus far, this one takes about 80% of the pie

Honorable Mentions

Other issues that can jump out in front of a Windows 10 migration like a deer on a late night highway drive:

  • Poorly written and poorly maintained in-house applications
  • Lack of consistent standards for desktop configurations
  • Lack of documentation
  • Lack of public brutal beatings for insubordinate users
  • Lack of political backing from upper management
  • Poor prioritization of IT projects
  • Squirrels fighting outside the window
  • Election campaigns and ensuing office arguments
  • Lack of motivation / low morale
  • Weather turns really nice after a few weeks of being really crappy

I’ll be on travel for the next few days.  If you’re in Boston, I’m sorry. It wasn’t my decision, but I’ll try to not ruin it.

My Feedback Batting Average

Since around 1998, I’ve tried to remain active with various beta/preview programs.  I never really stopped to qualify the reason, but I suspect it’s a bit of a rush to be on the ‘cutting edge’.  At times it’s been painful, such as when the product crashes in the middle of doing “real” work (or a customer-facing demo, always fun).

So, I was having a discussion with a friend about my experiences and he asked something along the lines of “how’s your batting average when it comes to making a dent?”  That was a good question.  I can’t share all of the vendor names due to NDA restrictions, even though I’ve left some of their programs long ago.  Nonetheless, I decided to obfuscate all of their names to be fair.  So it ends up being something like this…


This is gathered from notes, emails, web reports, etc. going back about 5 years. From the looks of it, I’d say G***** has/had the best responsiveness score.  And to put this in proper context, the nature of the product(s) involved don’t really compare across these columns.  Some are web services, some are client apps, and some are mobile apps.

As a personal challenge, I pulled notes from my last 4 app-dev projects and compiled the results as best as I could.  It looks something like this…


Project 3 was a rush job and forced me to lower standards to meet some deadlines, so the bug rep count was pretty high.  Project 4 seemed to make up for that I think.  Is this a meaningful comparison?  No.  Not at all.  For the following reasons:

  • I’m a single developer, not a corporate entity with divisions of departments of teams of people.
  • I was supporting one customer and one well-defined set of requirements.
  • My user-base base much, much smaller
  • I shared the office space with three of these customers, so communication was infinitely more efficient.
  • My SLA terms were nowhere near as stringent as the other vendors’
  • Given I was the only developer, AND the customer support interface, I was better-positioned to provide immediate responses to questions and concerns.  No having to report across departmental lines and wait for internal responses.

FWIW.  And now, I return to bothering my dogs.

Dear IT Recruiters…


Like most IT folks, I get a fair amount of contact from IT business recruiters.  On average, about 10% speak legible English (American-style, bastardized, beaten and bruised English), while the remainder speak various dialects of Indian, Pakistani, and various places across the Middle East, Central and Southeast Asia.  Most are very polite.  Some are in a hurry and don’t have time to be overly courteous, no worries.  But I have a few tips to share with you, if I may…

5 Rambunctious Recruiter Recommendations

  1. Read the resume first

    When you say “I read your resume and you seem to be a good fit…” for a position that has absolutely nothing to do with anything even remotely mentioned on the resume, the first reaction is to delete your email without reading further.

    For example, you happily fire off that email “Dear Anita Drinkrightnow!  Good news!  After reading your resume, I have a position where you would be a great fit!  The job is Junior Java Developer in Bowlscrubber, TX.”  Anita’s resume clearly shows she is a “Senior DBA”, and at no point in her resume is the word “Java” or “JRE” ever mentioned.  Guess who’s email just got deleted.

    You have time to talk on a phone, you have time to skim the experience section for just the position titles and locations.  And let me tell you, the really good recruiters know how to weave that into the first minute of a discussion.  “Hey Dave.  I see you’re working Fudgepackers LLC in Nowhereville, MT.  I have a fantastic opportunity at Unpackers Inc. in Nobodycaresville, MT, which is only 20 miles away from you!

  2. Check the locations.

    When you ask someone to consider a job that requires being “on site” and it’s thousands of miles away, you’d better be prepared to discuss relocation costs.  If not, then your message is deleted.

    If you’re going to lie about claiming to have read our resume, at least try to fake that you read the location of the most recent position.  Then use Google Maps (or whatever you prefer) to pinpoint that place in contrast to wherever the advertised position is located.  If it’s a few hundred miles away, you should hear a “ding! ding!” sound in your head.  That’s the “Tell them about the exciting relocation package, Jim!” alert.  If there isn’t such a package, at least play up the pay rate.

  3. Check the position level.

    If the resume shows “Senior” or “Sr.” in the most-recent position title, be cautious about shoving a “Hey! Check this out!” email in front of me with a “Junior” or “Jr.” in the title.  And if you do this and ignore the two previous suggestions, I delete your email and block you as spam forever.

  4. Rates are Important

    Do not bother to ask someone to contact you if you can’t discuss the pay rate.  Period.  And if you’re not up-front with regards to who has to pay for benefits (employer or employee) you add 50 GTFO points to the score card and a deleted email.

    If you’re a “serious” recruiter, you should take an hour to search Google for regional pay rates and costs of living.  For example, you call John Phistedtodeath about a job at Hydraulic Tampon and Incendiaries Research.  John lives in Oppressedville, VA where labor rates are lower than US average.  The position is in New York City.  You enthusiastically tell John that the pay rate is $55 per hour, without benefits and no relocation costs.  John is making $75 per hour in Oppressedville, as an FTE, with benefits and a lease.  I’ll leave the rest to your imagination.

  5. Do Not Dragnet

    If you send out job offers with key words “Systems Administrator” when the position is “Insurance agent” you not only suck, but you should be beaten with a pepper spray can, and whipped with a chain made of razor wire.  You are what make spam filters necessary.

I realize that much of this disconnect comes from the constraints of whatever shitty software application is used to track position openings and potential candidates.  But still.

Preposterous Profile Propagation Perils


Question:  “Is it advisable to migrate Windows user data when refreshing or replacing their computer?”  This was asked in the context of two scenarios:

  1. Migrating an existing Windows 7 machine to Windows 10
  2. Refreshing a hosed-up Windows 10 machine to a known state

For scenario 2, I recommend the “Reset this PC” feature in Windows 10 1607.

For scenario 1, here’s my long-winded response:  Avoid allowing your environment to get into this scenario in the first place.

I compare this with how I treat my phone.  My photos, contacts, emails, bookmarks, apps list and settings are all stored in the cloud. The only items I’d lose if my phone were lost or stolen would be SMS threads.  Not a concern.  My phone, to me, is 100% disposable.  I don’t sweat losing anything valuable if my phone were crushed under a truck wheel, dropped in a bathtub, or doused in gasoline and ignited with a blow torch (although, that would be kind of cool, hmmm).

Desktops and laptops should be no different.  Now, I’m not saying “the cloud” is the primary solution here.  ANY centralized repository will suffice as an “off-device” storage point.


Because of the following potential faults:

  • Migrating data and settings is costly.  It takes time to design, build, test and maintain for an organization.  The more variations in the environment, the more work is often required on the back end.  Even when a process/system has been in place for a long time, that doesn’t justify it’s existence (i.e. “because that’s the way we’ve always done it” = space shuttle O-ring maintenance processes too)
  • Having data stored locally is a liability.  Period.  Ask any attorney.
  • Having data stored locally is a security risk. Ask your InfoSec person (drink additional coffee first)
  • Having data stored locally adds need for disk encryption, RMS and DLP controls (more time and cost).
  • Having data stored locally incurs additional storage capacity and performance requirements on each device (depending upon the nature of data formats)

If a device is lost, destroyed, or stolen, you will need to address…

  • the potential lost of a vital copy/version of each document on the device.
  • the potential leak of private/sensitive information on the device.
  • the additional downtime incurred from replacing the user’s device as compared with providing them a “vanilla” device which immediately restores their access to all documents they need to do their job.

Is it always possible to implement this client-centric data model?  No.  There are a variety of reasons, one classic example is local processing requirements, such as CAD, media authoring, music production, etc. (high-bandwidth or high CPU demand, particularly when extensive graphic performance are a concern).

However, over the last ten (10) years of consulting and FTE work where I’ve been involved with deployment processes, I’ve only seen a few that really needed it (mentioned above).  The majority don’t really need to support local storage of business data.

The reason I bring this up is that I often see a lot of hand-wringing, project investment, and focused effort on applying a “solution” to the wrong problem.  This is just one example.  I have plenty of others to share if you’d like me to.