All your data is garbage

Storage is cheap, especially in the cloud where you can pay pennies per geo-redundant gigabyte. For someone who once paid $200+ to replace their 400 megabyte drive with a 1000 megabyte drive, that’s almost unbelievable.

No more expensive tape libraries. No more hiring couriers to ship data to an offsite vault. No more budget-busting SANs. No more uninstalling 1001 Amazing Fonts to free up space for Warcraft: Orcs vs. Humans.

Cheap led to less worry and it changed the way businesses approached data. Keep it all. Keep it forever. We might need it later.

Oh, what a terrible idea.

Building a liability factory

“We’re keeping everything to protect ourselves.” is a flawed approach to data retention. Even if your business is 100% ethical, the idea that “We’ve got nothing to hide and all this data will only help.” is misguided and naive.

  1. No one has complete control of their narrative. Sliced one way (your way), all that data may prove you’re in the right. But the other side’s lawyer(s) is incentivized to bring their own narrative and context to the data. It’s often better to have the legal minimum data rather than a rich data set that someone can twist, re-shuffle, and turn against you.
  2. If you have it, you’ve got to provide it. This isn’t an issue because you’ve got something to hide, but it does become costly and unwieldily. Storage is cheap, but managing it is not. Every retention and recovery process you put in place takes time and adds a burden on IT staff. If you’re trying to keep IT cheap, having 10 FTEs just to process data requests from Legal is not a good place to start.
  3. If you have it, you’ve got to protect it. Consumer facing businesses are terrible with this one. It might be really awesome to know the hair color of all your customers, but every bit of data you collect related to your customers, employees, and business partners needs to be stored as securely as possible at significant cost and risk. Less data, less risk.

Caveat: I’m no lawyer, but I used to watch a lot of Law & Order and know several words in Latin. Habeas Corpus Callosum.

99% of your data is completely worthless

Unless you measure your corporate data in petabytes and employ your own data scientists, Big Data isn’t a thing for your business.

On the other hand, Business Intelligence might be, and a lot of businesses get great insight from analyzing their data and building dashboards. But the successful ones all have one thing in common – they know what questions they want to ask before they start collecting data.

The answers to those questions may lead to new questions that require more data to be collected and retained, but it’s better to start with the goal of “Here’s what we need to know.” instead of “Gee, I wonder what all this data could tell us.” The first is a path to making practical decisions, the other leads to pretty, but useless charts.

The pitfall, even with BI, is making the assumption that you are gaining predictive power. Gaining insight into What Has Happened doesn’t necessarily unlock the ability to accurately predict What Will Happen (although it is generally helpful). It all depends on the data model, and good models are ridiculously hard to create and maintain.

There are instances where massive data sets make prediction even more difficult, especially when you don’t have the right people in place who understand statistical baselining and the effects of specificity.  A smaller, intelligently analyzed data set may be far more useful to you.

Ask “Why?” and push back

Just because you can do something, doesn’t mean you should and there are only a few good reasons for businesses to retain data. Three, in particular, serve as a good sniff test.

  1. Regulation & Compliance – There is a specific legal requirement to store a specific data set for a specific amount of time.
  2. Real Need – The business literally needs the data to function – think payroll and financials.
  3. Quantitative Value – You already have a set of questions you want to ask your data.

Requests for data retention that don’t pass the sniff test tend to lead down non-sensical rabbit holes. Unless your business is, literally, data – you should be keeping as little data as possible.

Cheap as storage might be, between liability, opportunity cost, and management cost, all the data you’re storing could wind up being very expensive for your business.

Image Credit: United Nations

Saying goodbye to my CISSP

Part of growing up is figuring out that your time and attention are 1.) your most valuable resources, and 2.) finite. To paraphrase Gollum, they are your “preciouses”.

So it helps to be thoughtful and deliberate about how you spend them. You need to figure out where to focus to get the most from your investment.

As an IT person, some of that investment tends to be in studying and professional certifications. We have to make choices about what we’re going to pursue (what’s most interesting and what will help in the future), and what we’re going to leave behind (what’s uninteresting and least helpful).

The yearly renewal for my CISSP is due in a few days. I’m going to let it lapse.

Checking all the boxes

I got my (Certified Informations Systems Security Professional) CISSP cert while working for a firm that does IT audit – it was important to them to have a CISSP on their staff. I had done quite a bit of security work as part of my IT jobs, so I bought the study guide, registered for the test, and drove to a hotel in Dallas to sit for it.

I was the only IT person in the room. Everyone else was an auditor. They glared at me when I finished first and walked out of the room- they had been at the hotel for two weeks for a CISSP bootcamp. I had shown up the night before and flipped through the study guide. It was the difference between an IT person approaching security and a security auditor approaching IT.

My pass note came in the mail. I had checked the CISSP box. Over the next few months I took part in some audits and checked a lot more boxes.

And I quickly became convinced that IT audit is where dreams, happiness, and prarie dogs go to die. Be kind to your auditors, you may be the only thing keeping them from throwing themselves in front of a train.

From pride to apologies

Of my certs, the CISSP is the one that gets the most comments. At first it was exciting – it was the first management level cert I acquired and it felt nice to have  recruiters calling.

But over the years I’ve found myself becoming defensive.

“Oh, you have your CISSP?!”

*Look around* “Yes, but I promise I’m really down to earth and practical.”

My defensiveness was a response to the culture I was getting exposed to – security group meetups, forums, fights with auditors. In the past couple of years I found myself really not enjoying IT security.

The thing is, I love IT security. There are interesting problems to solve and an element of Sherlock Holmes-style mystery that’s a lot of fun.

But the curriculum and culture of CISSP (and much of IT security) isn’t really geared toward problem solving – it’s geared towards writing policy to deflect liability, even though many technically focused jobs ask for it.

As I went to events and gobbled up continuing education, I became less certain about who would be able to get the most value from the cert.

An Information Security Officer? It probably is a foundational cert if you want to blab about vague, misguided attempts at corporate risk mitigation. I guess that works. I bet the CISO in charge when Target got hacked had his CISSP.

It’s not really a good cert for auditors either, as it just gives them confidence to ask the wrong questions. It’s definitely the wrong cert for someone technical – I don’t think its creators would argue too strongly with that.

I know for sure that, right now, it’s the wrong cert for me. It may have helped me get a job or two, but I have to put my time and attention elsewhere to focus on more interesting and valuable things. I’ll still bake security into everything I do, I’ll just do it without the extra letters at the end of my name.

Image Credit: Ken Caruso

VMWorld 2015: Sessions, Swag, and a Broken Promise

When Satya Nadella took charge of Microsoft and said they were going “cloud first” I had a hard time believing him – given the previous CEO’s tendency for hyperbole and marketing double-speak. But they proved me wrong. Their continuous delivery of new features and services in Azure and Office365 over the last year has been impressive. It’s changed the way many IT departments approach service delivery.

At last year’s VMWorld, VMWare made the same promises. “We’re making the shift. We’re going cloud first with all of our products.”

A year later, I’m at VMWorld again and am unsure if they didn’t know what they were committing to or just changed their minds.

Tied to the point release

I love a lot of what VMWare is doing right now, especially in the end-user compute space. They’ve enabled some really interesting opportunities with all the integration work that’s been done from NSX in the datacenter down to the device with Airwatch and Horizon – things that are going to make security and device management a lot easier.

They’ve been a good partner to work with and they have a clear, unique vision of where they want to go with EUC and hybrid cloud, which is exciting.

But for a company that committed to “cloud first”, they sure talk a lot about “the next release”.

“You can already do this in the on-prem product. It’ll be coming to the hosted service later this year.”

“We’re planning at least three releases for our hybrid cloud next year.”

“All the features you’re asking for will be available in the next release.”

That’s not cloud first. That’s not continuous delivery or devops (ideas that VMWare has been speaking to heavily). It’s waterfall development with a focus on boxed product. It’s shoehorning on-premise into the cloud.

It’s a strategy that isn’t going to work if VMWare really wants to appeal to anyone outside of their most traditional enterprise customers. It’s certainly not going to get them out of playing catch-up to Microsoft and AWS.

Culture clash

There seem to be lots of people at VMWare who see the problem, but they are butting up against the internal politics and culture of “Don’t make our legacy customers uncomfortable or my division may lose sales and I won’t get my boat.”

The same battle is happening at all of the vendors making the shift to cloud. Bring up Meraki to someone in Cisco route/switch internal sales and watch their face melt. Everywhere you look you’ll see the old guard fighting a losing battle for relevance.

Maybe it takes a dictatorial leader to resolve that. “Shut up. This is what we’re doing. Get on board or get out.” I’m not sure I’d want to work for that person though.

I do know that shifting from point releases to continuous delivery takes a massive shift in mindset across the entire business that isn’t easy, but it’s not unprecedented. Microsoft and IBM are doing it and they’ve got much bigger ships to steer.

They’re leading with cloud and carving out boxed products for the customers that lag behind – prioritizing the future over the past. I’m not sure there is a “right” way to pull this stuff off, but what they’re doing sure looks “right”.

Promising progressive customers “cloud first” and then not executing is certainly the wrong approach. Unless your goal is to alienate them and get them looking for solutions elsewhere.

Image Credit: VMWare PR

Accelerating Change: Adapt or be eaten

I was fascinated with animals when I was a kid. Whenever there was an animal documentary on PBS, I was glued to it.

My favorites were the predator and prey hunts – big savannah cats sneaking up on gazelles, chameleons popping out of camouflage to grab insects with their tongues – that sort of thing.

Mimicking the animals, my friends and I would play hide and seek in the woods – hunting each other with pellet guns (I’m really not sure how none of us ended up blind.).

Between reading, watching those shows, and getting pelted with lead, one thing stuck with me:

When you get comfortable and stop paying attention to what’s going on around you, you get eaten.

Or at least hit in the back of the head with a pellet.

Unable to adapt

Humans are terrible at anticipating change. It’s hard for us to get out of our day-to-day and our local scene. We’re busy, we’re distracted, we’re worried about surviving office warfare for the next 8 hours.

But we live in an age of rapidly-accelerating, Kurzweilian change. To keep one’s head down and assume everything is going to be a.) OK and b.) the same, is a form of intellectual and career suicide.

You know those people. You see them in the hall at work. You pass them on the highway.

They say things like “We’ll never do that…” and “It’ll be at least ten years until…” and “I’ll worry about that later.”

When it comes to technology they make the mistake of thinking that the next five years will resemble the last five. They look at continuous delivery, or BYO, or containerization and think “That’s fancy, but I’ll never have to deal with it.”

It is one thing to disagree about the nature of a change – this is healthy and necessary, but another to claim that something will not change.

Keep moving

We’re living through a major technological transition driven by pervasive compute and connectivity. It’s a big enough step that not everyone is going to make it – especially those who can’t or choose not to re-tool. Many people are going to find themselves pushed into lesser-paying roles or different careers.

It’s heartbreaking talking to those folks, trying to convince them that what’s headed their way is real – that the future is coming and it will be radically different than the present, even though we might all be wrong about the details.

“If you would move literally two steps to the right I think you’ll be OK.”

“Nope, ain’t gonna do it. You’re wrong, dummy. YOU’LL NEVER TAKE ME TO THE CLOUD!”

But I’m going to keep trying because the world is in constant flux and the future is coming. In fact (in the words of William Gibson), it’s already here, it’s just not evenly distributed.

Image Credit: Shutter Fotos

SCCM for device management is a dead end

I have always done my best to avoid Microsoft System Center, especially Config Manager. I don’t hate the product (It’s fine, whatever.), but I loath the culture and business decisions that SCCM enables and in many ways represents – turn every knob, customize every widget, control ALL the things.

SCCM is the embodiment of big, ponderous IT driven by big, nonsensical bureaucracy. It’s not the tool’s fault, it’s just how everyone ended up using it.

“We built a task sequence to swap out all the standard Windows icons with ones the CEO likes better. Your CD drive icon is now a portrait of Grover Cleveland.”

“The auditors said we need to index all the .ini files on everyone’s laptop. Then they asked what an .ini was.”

“Oracle wants us to show them a software report so they can charge us more.”

SCCM made it easy for IT departments to do stupid, expensive things and create unsustainable processes. I have rarely come across a business, that after spending thousands (if not millions) of dollars implementing and customizing, didn’t view SCCM as a grotesque monster – especially when they were trying to find people to maintain it.

Goodbye, Mr. Dinosaur

The unwieldy IT that SCCM supported is dying. Businesses are shifting to lean, cloud-based IT with less customization and little, if any, on-site server infrastructure.

SCCM doesn’t fit that model. Cloud-based MDM does and Microsoft seems to realize this despite their messaging on the topic being confused and noncommittal.

“More SCCM features are coming to Intune.”

“More Intune features are coming to SCCM.”

“SCCM isn’t part of System Center 2016.”


Rebooting device management

Starting with Windows 8, Microsoft began baking in a new management API that could be controlled independently of domain-based solutions like SCCM. Windows 10 includes enhancements to the API and adds a Linux-like package manager for software installs as well as runtime provisioning, removing the need for traditional imaging.

These are technologies for an MDM like Airwatch or Intune to plug into. It’s BYO and cloud-tech. Tech that lets businesses move fast and light. WMI and the standard SCCM tech is still there, but only as a bridging solution.

Given Microsoft’s focus on the cloud and enablement of technologies like Azure Active Directory (and being able to cloud-domain-join Windows 10 computers), I doubt they’ll continue investing in SCCM in its current form. If SCCM is your core skill set, I’d say you have 2-3 years of runway ahead of you.

My current money is on this scenario:

SCCM gets split and “goes away”. The device-focused tech gets rolled into the Intune platform and everything else gets shoved into the cloud-based Operations Management Suite, which is more server focused.

No more SCCM distribution points, no more impossible-to-find specialists, no more turning every dial. Oh, happy day.

Alternatively, SCCM winds up sitting in some weird middle ground where no one understands what it does or if they need it or not and Microsoft’s device management portfolio becomes an even more confusing mess than it currently is. This will incite an IT admin mob that chases SCCM through the village before cornering it and killing it with torches and pitchforks.

That, or the first thing. I’m fine with either.

Image Credit: Andee Duncan

When cloud isn’t cloud

“Your service is entirely cloud-based, right?”

“Yep. Absolutely.”

“So there’s no on-premise hardware? Nothing we have to build, deploy, or manage?”


I don’t know how many conversations I’ve had like this with OEMs and VARs selling cloud products that are only “cloud” in the loosest sense.  When they say “cloud” what they really mean is “hosted” or, in select instances – “hybrid”, either of which are OK, if that’s what you want.

Past the normal software connectors and API integrations you might expect in a cloud product, they have requirements for servers, internal network changes, and myriad other infrastructure items and config changes.

“You need to deploy this SSL certificate to every device.”

“You need to stand up 10 servers attached to your SAN.”

“You need to add these 35 records to your internal DNS.”

“Everyone needs to run IE 8 with Flash version 7 and JRE 2.”

“It only works on Windows… and Blackberry.”

Nope. Not gonna do it. You can take your product and go die in a fire.

Hybrid-cloud – I can get behind. There are some technologies and use-cases that require an on-premise component for at least a portion of their functionality. The client side of things, though, is where most integrators, OEMs, and VARs seem to fall off the rails entirely.

A big part of cloud is providing access to any device, anywhere – without reliance on a very narrow infrastructure config. If your product only works with one browser, requires five plugins, and four internal DNS records – it’s not cloud, but it is terrible. Before you say your service is a cloud service, be sure you know what that means.

Caveat emptor

If you’re on the buying side, it’s important to dive in to product functionality as much as you can before buying, especially if you’re trying to move away from on-prem and toward cloud and/or BYOD.

You need to go past asking “Does your product do X?” and ask “How does your product do X and what does it require to do that?” so you can gain the full picture of what you’re in for.

I’m not cynical enough to think that everyone selling a non-cloud “Cloud” product is trying to pull one over on their customers. In most cases, I think they’re just playing catch-up.

It’s surprising how common it is to find companies selling non-cloud “cloud” products and also doing something silly like selling white-box PCs. They seem to misunderstand scale, commodity, and technology agnosticism across a broad spectrum.

As much as you want to pat their salespeople on the head and say “Awww…who’s a big boy? You’re a big boy!”, it’s better to walk the other way.

Don’t ruin your vendors, dummy.

You did it. You rejected the status quo and took a chance with a startup instead of the established safe bet. Now you’re working with that new company to gear their product toward what your company needs.

Be very careful what you ask for.

Growing up

Companies, like people, are always challenged by who they want to be when they grow up. You can see this in startups as well as established companies like Microsoft and Cisco. You can watch those same companies flop around like dying fish when they’re struggling to define that vision. (Look at Microsoft over the past decade.)

Even single product companies have a lot of trouble defining themselves.

“Do we push for feature parity with our competition?”

“Do we throw a wide net or focus on a niche? Which niche?”

“Do we focus on growth and expansion or stabilize and boost margins?”

So on and so on.

Your responsibility

When you’re working with a vendor that’s trying to find itself, it’s important to keep these things in mind, especially when you start sending them your wish-list items. There are a few reasons this is worthwhile.

  1. You picked them for a reason. You made your pick because you liked that the new solution was simpler, smarter, faster, cheaper, etc. There was something you liked about them that you didn’t like about the safe bet. When you provide a laundry list of requested features and make comments like “Well, the other guys have that functionality.”, you risk turning that special startup into the monster you were running from.
  2. Your processes suck. Everyone has crappy processes, some more than others. When you start making hyper-specific requests based on an existing process, be cautious. You may be propping up your vendor to enable you to keep doing something stupid. Before you ask for something in this vein, really consider what you’re trying to accomplish.
  3. Constraints can be valuable. See above. Having a well defined box to work within drives creativity and innovation. Pushing your vendor to create an infinite sandbox will bog you down in ambiguity and choice paralysis. (*cough* SAP *cough*). Don’t believe me? Turn to your significant other and ask them “We can go anywhere in town for dinner. Where do you want to go?”
  4. You want your vendor to stay in business. When their product becomes bloated with features and they lose direction on what they want it to be, their marketing will become muddled and they’ll have a hard time making sales. Your random requests may be killing your darling.
  5. You’re scattering their resources. Three years from now when you’re asking your self “Their support really sucks now. I wonder what happened?”, the answer might be “you”. Every one of your implemented requests has to be built, integrated, documented, and supported.

You may be thinking “Well, isn’t it the vendor’s job to define their product?” Yep, it is. But if you want them to be around and be the awesome partner you hired them to be, you need to help. Very few companies have leadership who can maintain the laser-like focus they’re going to need to successfully mature, especially when every customer is asking them for the world. (There are very few 37Signals.)

This doesn’t mean you shouldn’t ask for improvements or features, it just means you need to be thoughtful about what you ask for. Each feature request has consequences that (you, and) your vendor might not be considering in their eagerness to please you.

Think of all the stupid things you were willing to do when you were young and really wanted people to like you. The startup you picked is just like your younger self. Help them to not be stupid.

Image Credit: James Provost

Infrastructure People – Learn to code or GTFO

Although it’s not always apparent to those I’m mentoring (Asking me for answers should not be your first step.), I like teaching. I like helping people work through problems and figure out how different components fit together holistically.

Lately, there’s been a particular point I’ve been trying to hammer home in almost every conversation I have – with junior sysadmins, college kids entering the field, and anyone else who will listen.

Regardless of your infrastructure specialty – networking, servers, storage, whatever – you need to learn to code.

Or you need to consider another line of work.

Batch script wizard

Part of gaining expertise is learning the scope of what you don’t know. I remember feeling like a fancy wizard when I started my career in tech – that I knew sooooo much. I could build computers from junk parts and troubleshoot through any problem set in front of me.

Then I met systems and network admins who knew how to script. They could craft batch and bash magic to effect change across the network. The scale of the world they worked within was so much larger than mine.

Suddenly, I felt like a caveman (Not even a smart caveman. More like Flurp, the slow, butterfly-chasing caveman.), clumsily bashing rocks against every problem.

Even simple batch scripts to map printers and install software were game-changing. All of those manual configurations I had been so proud of started to feel silly. I still feel a little of that when I browse through projects on GitHub.

Knowledge of scripting rapidly became a dividing line between tech jobs that paid minimum wage and those with upward potential. Batch (more Powershell now) and bash (more Ruby/Python now) became the foundation to launch a career from.

Code literacy

There are cases where a simple Python script can obviate hundreds of hours of work. Hiring managers know this and this skill set is now expected rather than being a “nice-to-have”.

“Take this server. Now make 1,000 friends for it.”

New expectations are forming around the interaction between infrastructure & applications and general automation. Within a few years there will be very little room in the industry for infrastructure-focused people who are not, at the very least, code literate.

This doesn’t mean you need to be able to build a consumer-ready application from scratch (although that helps), but it does require an intermediate-to-advanced understanding of scripting languages and/or a basic understanding of compiled languages depending on your company’s dev stack.

DevOps is here

What use is a sys admin who just points at the apps team and says “your code sucks” without even being able to read the code? Or a sys admin who is charged with designing infrastructure for an app he or she has no understanding of?

That’s why DevOps (the merging of infrastructure operations and development) has become such a big deal. Companies need their sys admins and programmers to be able to work together and at least have an idea of what the other person is talking about.

“Line 38 appears to reference an individual database server we took offline last week instead of the load balanced DNS name and knowing that this loop is working through this array, I probably gave the app servers too little memory.”

And in situations where an app is being scaled horizontally, the infrastructure has to be there to meet it – automatically. Clicking buttons in the Windows Server GUI is probably not going to get you there. Knowing how to script against the server command line or the platform services an app is running on will carry you a long way.

Additionally, why would a company hire 10 network admins to maintain equipment configurations when they could hire 2 who knew how to script against an equipment API? Be in the second group. Automate your configs and show your value.

It’s up to you

If you have no plans to build your skills past manual configuration, you are destined to work in small, boring environments if you’ll be able to find a job at all.

If someone can hack together a few lines of code to replace you, that’s your fault, not the merciless-robot-who-is-taking-your-job’s fault.

If you think “I can’t code. My brain isn’t built that way.” Spend 30 minutes working through exercises on CodeAcademy or any of the countless other coding tutorials online and you will find out that you are wrong.

This isn’t the requirement for five years from now. DevOps is here today. If you want to stay in the infra niche and be happy and successful, it’s time to fire up your text editor and learn a programming language.

Image Credit: Michael Himbeault

Cisco Live: A river of dudes

It’s been a few weeks since Cisco Live, and I’ve had time to digest a lot of what I heard and saw there. There were some pleasant surprises: The DevNet area was awesome and highlighted some interesting things that Cisco is doing with Infrastructure as Code.

There were also disappointments: Intercloud remains a confused mess, some vendors went super-cheesy with their presentations, and the follow-up sales calls are relentless (Seriously, Puppet Labs, I didn’t need another 25 voicemails.).

But weeks later, the thing that stands out in my mind is the homogony of the attendees. Easily 99% of those present were male, and that stinks.

This happens everywhere

Diversity isn’t a tech industry problem – tech just happens to highlight the most egregious examples because of the current underrepresentation of women and minorities in math and science-heavy fields.

Across all industries, we make it hard for women to get their foot in the door – I’ve seen women turned down for jobs over concern for how others in the business would “cope” with them and a myriad of other silly reasons. I’ve seen women forced to prove themselves far past what’s required of male applicants with similar experience and credentials.

I’ve seen those that have gotten hired treated horribly – spoken down to, insulted, alienated.

Yeah, so…I’m gonna need you to answer the phone now

A few years ago my wife and I worked at the same company. When management fired the receptionist, they decided to split the phone duties among “the other women” in the office. Male peers, at the same employment level, were excluded – they had important work to do. My wife was managing HRIS, but because of her gender she was seen as “less than” the males working in entry-level roles a few offices away.

I know plenty of smart, competent women who have strong interest in fields in which they are not working – tech, science, manufacturing, field ops. When I ask them why they didn’t follow their interests, the answer is almost universally “because I didn’t feel welcome”. They didn’t feel welcome in computer club, in biology class, in their MBA program – so they defaulted to something they didn’t love in order to survive.

That makes me furious

My wife and I have been talking about starting a family, and during those discussions my imagination runs wild. I imagine future children, teaching them things, showing them the world.

I imagine having a little girl who gets told by others that it’s more important to be pretty than smart. I imagine her applying for a job and getting turned down because of her gender. I imagine her getting treated poorly by a chauvinistic manager. I imagine her standing up for herself and being called a bitch and it makes my blood boil.

Changing culture

The status quo hurts everyone. A meeting room filled entirely with men lends itself to the pack-mentality groupthink that results in bad decisions and stagnation. It creates a toxic, locker-room culture in which it is OK to talk down to others and management is accomplished through intimidation. It leads to stale ideas pushed forward by literal yes-men.

My ideal hiring scenario, because I don’t trust my own subconscious biases, would be completely blind – if I was managing a team, I wouldn’t know if a new hire was male or female, I wouldn’t know their race or age, I wouldn’t know any of the unimportant things about them until they walked in the door the first day.

(This sounds impractical, but Google is actually pulling something off that is very similar.)

That’s really hard though, especially for companies that don’t have the resources to setup selection committees or do away with the concept of “hiring” managers. It’s not that hard to blind resumes for the first round of review though, so we can start there.

It’s also not that hard to treat your current coworkers like human beings.

Diversity is a hard problem to solve. There are no easy fixes – there never are when a problem is based in the way people behave, but we have to start making changes, if only to build momentum.

Down with the patriarchy. Long live basic human decency.

Give up control and stop managing devices

Managing end-user devices, simply put, sucks. It requires a significant amount of infrastructure and staff. It leeches time from your IT department and end users. And the more you try to wrap your arms around all the devices in your company, the more problems you have.

Trying to fully control and manage every device connected to the network results in unhappy users and broken IT staff, huddling in data closets, weeping – while the executives upstairs are piped a false sense of security.

So stop managing devices. Don’t join them to a domain, don’t lock them down. Give up control.

I promise you, it’s not as crazy as it sounds.

All the devices!

IT departments have been struggling for years to juggle trusted and non-trusted (BYOD) devices. We layered on tool after tool to try to stay in control, but it hasn’t really worked. It’s just made management more complex.

We built a taller wall around trusted devices and the network, and tried to extend control to all the new things that employees were bringing to work. We began to manage triple the devices with the same number of staff.

Users hated the new restrictions on their computers as we locked them down, and IT hated all the new infrastructure we had to install and maintain to keep any semblance of control. We kept piling on sandbags long after the levee broke.

It’s time to start over

Instead of trying to exert control, what if we went the opposite direction? What would happen if IT treated all end-user devices as non-trusted, employee andcompany owned?

  1. Security is simplified.  If we assume that all endpoints are insecure, we can drastically shrink the surface area we need to protect and focus on data and apps. Devices are separate from the data center and one another.
  2. App management is centralized. With a small number of exceptions, we can deliver apps via browsers, virtual desktops, or streaming – from the datacenter or the cloud.
  3. Data is tied to identity. Unstructured data moves to the cloud, with rights management or containerization in place depending on your compliance needs.
  4. Devices don’t matter. Remember, we’re relying on remote delivery of apps and data (Think of everything as a thin client.). A user is having a computer problem that takes more than 5 minutes to fix? Swap the device out with another from the pool.
  5. Overall management is simplified. But maybe we require a health check to keep things from getting too crazy. Don’t add machines to the domain, use an MDM. Passcode, A/V, and security updates seem like reasonable requirements to enforce, but stop there.

This isn’t a thought experiment. This model is being pulled off successfully (sometimes in pieces), not just in Silicon Valley, but in growing pockets around the country – within organizations that are aggressively embracing the future.

Vendors are building and have already built products and services to support this model. VMWare, Microsoft, Google, Amazon – almost every player who matters is on-board.

If you’re in an architecture or strategic role, this is the future you need to be planning for. The current model is untenable – within a few years, if your IT departments is still trying to manage devices the same way you do today, with half the budget, a quarter of the staff, twice the tools, and exponentially more devices – you will fail.

Photo: ep_jhu