www.itminddesign.com

Today, I really didn’t start out thinking that this was going to be my topic for the blog. However, as I was reading my newest copy of Business Week, which I look forward to every week, I read this article Youthquake and was generally happy with it. I’m glad to see people being passionate about things that are important and wanting to express themselves by getting involved. Then we hit this part in reference to Generation Y (a.k.a the Millennials) which I draw issue:

Growing up in the era of cater-to-kids politics, the V-Chip, and helicopter parenting, they were the most coddled generation ever, infused with their elders’ belief that they possessed unique abilities.

I have seen this reference several times in the past few months. Lucky for me, by Business Week’s definitions I am not a Millennial. phew.
Though in another atricle I read, apparently I am. Here is the article, Young IT workers disillusioned, hard to hold, survey says - Network World
Since this article is about me, I think I need to respond. First, to clear up a few things for those folks over at Network World, Generation X is defined as

For the purpose of this study, Generation X is defined as people aged 21 to 32, that is, respondents born during the years 1968-1979. US Census Bureau “Census 2000 Ethnographic Study” (June 17, 2003)

I have to say that I am disappointed by the wide generalities by these writers. NetworkWorld wrote this article based off 100 executives (awesome sampling size) polled in Massachusetts and 50% of respondents described those Gen-Yers as the hardest to manage. Well, if 50 executives in Massachusetts say it, then it must be true. Gen Xers came in second with 17% saying they were the hardest to manage. Wow, 17 executives.

On the article it quotes,

For instance, many younger workers expect to get an office immediately or be paid at a rate higher than entry level.

and

Millennials are coming in with high expectations and are disillusioned about the reality of a work place. They feel they should be rewarded and start at the top, when we all know you have to work your way up. They have been raised to be rewarded often and when you get into the workforce those rules change a bit.

As a Gen Xer or Yer, depending on which website you visit, I had no expectations of anything other than a paycheck when I started in IT. I was just happy for the opportunity and in fact, I am still grateful for the opportunity. Since I am in need of some self humiliation, I shall share something that I’m not sure I told anyone, and the only people who know are the ones who interviewed me. I still cringe when I remember my outfit I went to my interview in. No suite, just pants, shirt, and tie. And the power accessory to knock’em dead? –the baseball cap, to hide my long hair that I believe I hadn’t even combed for the interview. I’m glad someone saw something in me. I’m glad someone didn’t look at my baby face, and go, oh one of those entitled Gen Xers, I can’t manage those kids. By far I was the youngest, had lots to learn, and embraced anything anyone of any age was willing to show or explain. Eleven years later, I’m not the youngest anymore, but I am still that kid.

I think these wide stereotypes are biasing managers. I’m am quite certain that someone can find anyone in any generation that fits some of these expectations of entitlements. For example, there is an article In Defense of Gen Y Workers - CIO.com which I hope was tongue and cheek, if not, it may support many of the fears of the managers of Gen Xers and Yers. I know people need to have something to go on because we will never know everything about every person. So I understand that people use generalities and stereotypes, but everyone is different and you can miss so much if you just put everone in a catigorized bucket.  Utilimately, you have to take every person, one at a time.

So my final piece of GenX wisdom to those 50 whiny executives in Massachusetts — just stop your whining, because excellent leaders like yourselves can adapt and overcome to manage anyone.

Background

Last year, in collaboration with my leader and teammates, we set out on a mission to replace some existing end of life equipment while adding capacity and taking advantage of the progression in technologies. So after some due diligence and data gathering of the current state in the environments, we documented the current state and poured out our requirements in what can only be described as an RFP - RFI combo document using the terms as defined in the Reference Terms page. The birthing of this document was arduous and focus on accuracy and unbiased toward any specific vendor or technologies. We documented the characteristics such as:

We gave guidance as to what categories/areas of information (including the minimal amount of data deemed acceptable) would need to be provided about the proposed solutions. Evaluation criteria was indicated. However, in retrospect, we did not provide which areas where more of a priority than others and what weight was given to the evaluation criteria - not to say that information is needed, expected, any of the respondent’s business, or commonly provided the vendors.

Vendors - OEMs v. VAR

The request was sent to both OEMs vendors and VARs. We were accepting of a total solution from one OEM, but a multi-vendor solution was more likely. Very few vendors have the top-notch equipment in all the technology spaces we covered in the request. Either way, would be satisfied if the solution was a fit for the company’s needs. We have relationships with multiple VARs and I believe they provide value in “the gap” between vendor and customer. In this specific instance, there were so many common OEMs that received the request than many of them contacted the VARs to be “partners” in responding to this request that the VARs became indifferent and didn’t want to “choose sides” in responding. So, if your keeping score at home, that’s 0 VARs to respond. Our familiar and trusty weapon to deploy proper multi-vendor solutions has been inept and removed from this equation.

Follow-ups and Responses

We had the standard follow questions; conference calls and meetings. Then weeks later, those who had chosen to respond, began to respond. Meeting mania occurred, vendor after vendor. Documents, CDROMs, Power Points, websites, business cards, and killing trees while burning up the printers. (Sidebar: I wonder how many carbon credits it would take to replace the paper used for all the printouts of all the versions of these documents). After we wiped up the blood that had oozed out from our ears we began the data absorption. Continuing to cull through the minutiae and finding viable candidates.

The proposed solutions

I have to say that the responses were wide. Some vendors inculcated the requirements and the current state of things. However, some did not. I almost think that some of these guys just did not read and listen. Not to question their competence, as being an elder statesman I would not do such a thing, but I expect more from them. Sure I knew that 99.9% of them were going to have a total solution to provide with their logos on every piece. Some of the solution being their equipment and some were rebranded from other companies. The individual creators of each solution should be leveraging their vast knowledge and experience with so many customers in how they ascertain the best solution for our company. However, with the majority of the respondents, we got mostly marketing and very little substance. The kicker was, all of the solutions had some validity, what they couldn’t articulate was how the information we provided plus their industry knowledge and experience lead them to this solution. So I don’t know what factors they did include, did they see the potential dollar signs and get tunnel vision? Was it multiple teams working on this response, and the team that made the technical decisions wasn’t the same as the pre-sales folks who comes to present the response? If this is common for most vendors responses, how are these company’s making money? I’m sure the margin for reselling for a VAR isn’t enough to retire on, so it’s not the hardware/software sales brining in the dough. Professional services is what makes a VAR big money and from my experiences with some quality VARs, they are worth it.

Lessons Learned

• I think the next request we do, we should start with the VARs first and get through them before we engage the OEMs directly. Doing this might keep the VARs in play and not force them into an awkward position.

• Allow for more time for discovery and communication of data and requirements to VARs and vendors. As will all impending needs, we usually don’t get to them until they are really needed and some shortcuts have to made in the interests of time and money.

• Keep up contact and meaningful conversations with quality vendors. They seem to do better when they understand more of how the customer’s company works and what’s generally going on with all involved. I know personally that time is always at a premium and investing it in vendors when you don’t really need something is hard. These lower priority items always fall to the wayside.

• Stay connected with the quality sales people and engineers. Even if they change vendors or jobs, with all the business social networking sites (LinkedIn, Plaxo, etc) it should be somewhat easy to keep in touch. Good salespeople and engineers are hard to find and even harder to keep around, so the investment is worth it.

Dave Hitz, who is the founder and EVP of NetApp, imparted some interesting information in one of his blog posts. This specific post breaks out some functional differences in roles in different size companies for CIOs and CTOs which was an enlightening experience for me. What Dave did impart that I most found of value where the five stages of technology adoption.  Dave went on to further describe these stages as monitor, evaluate, standardize, proliferate, and retire.

‘I asked for details about these different stages. He described monitor as a casual awareness of a technology, maybe from reading occasional articles or white papers, and keeping an eye on it to determine when to investigate more deeply. Evaluate is when you seriously consider whether a technology is valuable enough and mature enough for you to deploy. To make a technology manageable in a large enterprise environment, you standardize on a particular set of configurations and management processes. At that point, you can proliferate the technology broadly, until a replacement technology is ready, at which point you retire this one.’

Though these categories do apply for CIOs and CTOs, I believe they are useful to others down the ranks. Part of the function of the group in which I am a member is to stay up with technologies and continue to drive innovations and newer technologies where they can best help the company succeed and improve the environment the people who work at the company must support. I think that if we inculcate these categories into our processes it will help define a ‘lifecycle of technology’ that give some meat and measurability to one of the most hard to quantify part of our job descriptions.

I wonder how other companies handle the processes of new technology. My company is fairly global and large and groans due to the weight of red tap. I am curious how others see this and how other companies, both big and small, approach this process.

I find Dave’s blog often filled with interesting views and information. Should you desire to read his blog, it can be found at blogs.netapp.com/dave.

We all know these people and some of us are these people. You know the type –they could be in the cube next to you — they sleep in bed with the laptop logged into the office and the cell phone and pager glued to their side. Even while they sleep, they jump for the opportunity when the phone rings. The ring of the cell phone blares and they spring to life. Some operational support person is calling them and the bitter taste of adrenaline starts to brew in their mouths. Some application or component is down, time to go to work. Their vision narrows as they focus on the issues at hand. They can fix it; they don’t need anyone else to help. No one else can fix this as fast as they can. They are the only hope. The sound of horse hooves thundering over the ground is deafening.

The description above might be extreme but for many Information Technology support personnel this is a real addiction. Those who fit this criteria have a difficult and often impossible time trying to transition into a different role in the organization. I know because I was this person — the addict. Sometimes it takes one to know one, and I still see the addict in others. Often times they are currently in management because if technical personnel want to make more money they must be managers. However, technical people — especially the adrenalin junkies — don’t often make good managers. These types will only be truly happy when the opportunity comes to ‘feed the need’. I have seen this quest for the fix in a manager who neglected ultimately the company’s objectives and the person’s direct reports. Anyone who stands in the way, may become a victim or competition. The addict can do no wrong but when he does only intense self-flagellation will do.

Once I entered management my attitude had to change and I had to hit the twelve step program for techies. I managed to detox and enjoy the ‘high’ from the successes and personal growth of those who worked for me. I can still remember, nothing was more awesome than fixing a problem no one else seemed to fix and fix it quickly. You genuinely feel that you have to be the best, the lead techie, and constantly stroked for being ‘the man’. Techno geeks are usually eccentric individuals and the egos that go with that is often a nasty beast that must be fed constantly. I know the lack of self confidence/esteem had to always be covered by the huge ego. For some in the none alpha type personality, feeling ‘worth something’ or ‘being needed’ or dependent upon is the manifestation of the severe lack of self confidence. For these types, the place crumbling in their absents and everyone being periled in resolving issues without them is greatest high.

Maybe this addition gives the reflection and perspective that a technical manager needs to remember what it is like to be the person who has to solve the problems when the fighting for the righteous solution gets rough but the selfish and harmful side effects may outweigh any potential benefits. These issues — the addiction — must end or the need will continue to fuel the destructive behaviors.