Midwest IT Survival

Financial transparency with employees is key to long term success?

As I look back over my almost 20 years of corporate IT employment in multiple MidWestern companies, I’m starting to detect a pattern.  And for those that know me or read my bio know, I’ve working in multiple industries supporting multiple business groups in both public and privately held companies large and small.  Those groups span retail, commodities trading, natural resource exploration, mining and refining, banking and financial services, legal services and manufacturing.  The pattern or trend I am referring to is:

“The degree of success a company or business unit experiences seems to be proportional to the degree of financial transparency reported to employees.”

The more transparent the company or group was with profits or losses, costs and expenditures, revenues and margin, the more successful the company or business unit was growth-wise.  The more secretive and obfuscated the financials the more downward trending the company or business unit as a whole.  I can even recall the same business unit switching from transparent to obfuscated coinciding with a positive to negative growth switch.

The transparency I’ve referring to is not only the quarterly and yearly reports filed with the SEC and available to the investor community.  It is taking some time out of the daily work schedule to bring employees together and explain the business decisions, strategy, budget and market conditions that are behind and driving those numbers.

In recalling my MBA coursework, I had an excellent course on family owned businesses by Ernesto J. Poza, author of “Family Business”.  Ernesto J. Poza is now the Professor of Global Family Enterprise at the Thunderbird School of Global Management.  I believe he also made this link in his course I took at the Weatherhead School of Management at Case Western Reserve University.  His focus was family owned rather than publicly owned businesses, but I believe the theme can be extended to both.  I recently took a continuing education course through Weatherhead and met a CFO of a small, nearby Internet creative design firm who mentioned his company was experiencing measured growth even through the great recession.  He also spoke of the owners having a monthly financial update where a straight review of the prior month’s numbers gives all employees a direct sense of the health of the company.

The straight reporting of the financial health of a company or business unit gives everyone a clear picture of where the company is headed.  If repeated quarters of downward trending financial indicators are given, then no one should be surprised that costs, including employee overhead, needs to be seriously considered for adjustments.  Managing technical teams is more straight forward when everyone on the team knows the health of the overall company or unit.

Can anyone confirm the link between company and/or business unit growth and financial transparent reporting to employees?  Any disagree?

How to marry the classic IT budget and Agile?

I’ve been reading more and more about managing large projects with Agile.  I am wondering how best to optimize the merger of the classic IT yearly budget cycle for large scale projects with the Agile principles and agile project delivery.  There has to be a way to balance the constraints of an upfront budget process with the benefits of agile-ly deployed business prioritized deliverables.  Or in other words, how does one keep the dollars and cents focused people happy and the business project sponsors enjoying the benefits of Agile delivery?

The classic IT yearly budget cycle I’m referring to is one of wild guesses at capital such as servers or software licenses, maintenance, expense and internal plus external resource costs to complete projects that involve IT in the next yearly financial calendar.  Projects maybe completely IT driven with IT as the end customer or projects maybe requested by the business to deliver business value that need IT support in delivering that value.  In either case, the classic budgeting versus agility challenges is the same.  Take the typical project mixing IT and business changes:

New Project Request Form:

Project: A456 Enable Call Center Order Confirmation

Scope: Upgrade the FlimFlam call center system from 5.0 to 6.0 to enable the customer communication widget and change the call center workflow to use the widget and not carrier pigeon to confirm orders with customers.

Budget Questions:

• How much does the upgrade cost?  (easy, ask software vendor)
• How many consulting hours and dollars are needed to support upgrade? (medium, ask software vendor’s professional services for a typical customer upgrade number, then add fudge factors to map over to your company)
• How many hours from your internal shared IT resources to support the entire effort? (hard, don’t have the time to go through the project requirements gathering and design phase or collect all stories, get story points, etc., etc., so take a wild guess based on past projects or other similar work, add fudge factors, add more fudge factors, then double it … you get the idea)

Project Budget Submission Criteria:

? = Capital

? = Maintenance

? = Expense

? = Internal Resource Hours

? = External Resources Hours

? = External Resources Hourly Rate

? = Total External Labor Costs

The budget process demands a number to be provided for each question mark.  You know that certain magic number thresholds, if cross, will doom your project or almost as bad, push it into a category that requires a whole new level of business case and ROI sizing effort. This classic IT project budgeting process doesn’t seem to support the majority of the Agile project delivery process.

Does anyone have any experience or references to best practices in this area of marring legacy budgeting and agility?

I was recently asked to help with putting together a logical sequence of steps to help a group go from no Single Sign-On strategy through the discussions to ultimately arrive at an executable SSO strategy. I’ve attached the presentation below in hopes that others might find it valuable.

Abruptly in the job market, what to do?

Expansion and contraction of the IT labor force in MidWestern companies is nothing unusual. In America’s boom and bust capitalist economic system of recent decades, during booms, MidWestern companies expand their IT labor force in order to capitalize on automation efficiencies and work volume management through IT enablement. When the boom time is replaced with a bust or significant drop in demand for a company’s products or services, the need for IT automation, overhead spend, etc. follows suit. As some may know, I was recently unemployed. Due to the terms associated with leaving my previous employer, I am unable to share any further details.

Finding myself somewhat abruptly in the job market, I now had to make some choices. There are a number of Internet resources suggesting this new loss of employment state is a great opportunity to re-assess your life priorities and career path. Others have mountains of compelling evidence to jump right back in the job hunt before goofing off becomes your new employment default (such as “Nine Reasons Not To Delay Your Job Hunt” or “Clearview Counterpoint: Should Employees Downgrade Job & Salary Expectations For Next Few Years?”). For me, I had contiguous employment from 1991 through mid-2001 (victim of the dot-com IT employment burst, anyone remember the birth of Odd Todd and Laid Off Land?), then late-2001 till May 2010 (now victim of the Great Recession). Thus, for me, I had the benefit of going through this experience once before (although it seems a lifetime ago as I write this) that offered some guidance on what works and what doesn’t work for me when faced with unplanned unemployment. I thought I would share some of my experiences with shifting from the work routine and the familiar office scene to having that routine completely shut off.

Realization = Loss of Structure

Your proverbial 9 to 5 structure is suddenly replaced by a giant void. Nothing really forces you to get up early and jump into the shower. Yet if you are at all like me, you are pre-programmed to do so. Thus, you find yourself compelled to do it anyway. For some, this maybe a gift from the gods, but for folks like me who have had almost 20 years of 9 to 5 familiar work driven structure, it is a striking realization. The realization is that there is no compelling reason to get up and be productive because there is no demanding employer out there. This realization can indeed be a bit shocking.

Opportunity = Replace Old Structure with New Structure: The Schedule

I’ve found that creating a new structure worked for me. I got up relatively at the same time as when I was going to work. I completed the same morning routine. I did choose slightly more casual clothes than I normally would wear to work as a minor benefit. I then grabbed my really old, clunky laptop, jumped in the car and headed to “the office”. This familiarity of schedule helped me to keep focused on the future rather than dwell on the present or the past. I was used to getting to the office and jumping right into the work. Now, I just replaced the previous work with the new work of finding a new job.

Opportunity = Replace Old Structure with New Structure: “The Office”

I replaced “the office” with local coffee shops. And since I was planning on working, not catching up with an old buddy, I sought out coffee shops that met the following criteria (pretty much in the order of priority):

• Free (reliable) wireless Internet
• Tables for setting up a work space (not just chairs for lounging)
• Power outlets in easy reach
• Free coffee refills
• Enough noise so that it re-creates your office environment but not so much noise that you can’t focus

I also found having a few different destinations instead of just one helped break up the monotony.

I was surprised by the number of other people with laptops, notebooks, papers and cell phones buzzing around me that helped create that familiar office like environment. I tried local libraries which always offered free Internet and good desk setups, but the quiet was too non-office-like for me.

Realization = No Coworker Interaction

Every IT job imaginable that involves traipsing into an office comes with some degree of coworker banter. In addition, most if not all MidWestern IT jobs come with business/customer/client/management interaction. Once you are unemployed, that interaction ceases to exist. It is always amazing to me how much that professional and social interaction becomes an integral part of your work life. You might not realize how much a part until it is suddenly non-existent.

Opportunity = No Coworker Interaction: Replace with Social Networking

Remember all that career advice to build a professional network of people for times such as these? Now is the time to get some of the payback for your efforts in keeping in touch with people for which you crossed professional paths. You name the social media channel and I announced my availability in the job market. From Linked-In to Facebook to Twitter to even my personal web blog, I let everyone know I was back in the local job market. I also pulled out my list of professional email addresses collected over the recent years and sent everyone a brief personal note indicating my change in employment status and a brief indication of what type of work I was capable of doing. I chose the word “capable” strategically to cast the widest possible net of job options. Sure, I might not want to do X, but rather Y. Yet, if I could successfully do X and there is an opportunity to do X in the near term, why not engage in some hopeful dialog? You never know when a conversation about doing one thing can lead to something more to your preference. In my opinion, when looking for work, having as many proverbial doors open is best.

Results = Surprising

I was completely amazed by the number and immediacy of the responses from all the media channels. Almost instantly, people were responding with understanding and support. I also received a number of direct phone calls to chat about possible opportunities. There was even someone I last interacted with in grade school that volunteered to get my resume in front of a local software company’s head of HR due to his relationship with the HR head from his past.

I continued to share my updates via my social media sites. I didn’t post every five minute statuses “… I just posted to ABC Company, got umpteenth cup of coffee, now headed to the rest room…”, but I focused on periodic upbeat, positive news in reaction to my search progress. Again, the response was equally positive and upbeat. This contributed to maintaining some level of familiar coworker banter to keep oneself positive about future prospects.

Lastly, I’ve heard of people recently losing their jobs and then hiding the job loss from friends and even family. Being my second time around in the forced unemployed state, I completely looked past the possible shame, embarrassment and sense of loss and immediately refocused on letting the world know I have value to bring to a new employer. Also, more than 1 in 10 people are currently unemployed thus it is far from a shameful or embarrassed state to be in. Thus, the more people who know you are looking for a job, the more chances someone will know someone who needs the value you can provide.

Summary

Hopefully some of my experiences captured above will help spark others in the throes of finding employment in the Great Recession. There are probably a whole slew of other tidbits but these were the ones that jumped out at me initially:

• Consider a job search schedule that somewhat matches your recent work schedule.
• Reach out to everyone via every media channel you can image and let them know you are looking for a job and what you are capable of doing.
• Share your successes via those media channels in a reserved but on a frequent basis .

Anyone have any other tips to share?

IT Role Spectrum

Someone noticed, when reviewing my work experience on LinkedIn, that over my tenure, I’ve had the opportunity to manage both IT infrastructure teams and IT software development teams.  They posed the question of what are the differences between managing the two different teams.  This question got me thinking.  People that focus on infrastructure compared to software development do represent potentially opposite sides of the IT engineering spectrum.  Further more, I believe there is a middle of that spectrum. There is a role for individuals that integrate disparate vendor software products on top of infrastructure to create a technical service provided back to the organization.  I am not sure there is a universal name for this functional team of individuals, but I’ve heard them referred to as integration engineers.  I have also had the opportunity to manage an integration engineering focused team as well.

Note: Check out Part 1 for an excellent interview with Jim Shelton, Executive Recruiter; Information Technology for MRI North Canton to get his perspective on the differences he sees in MidWest IT managers looking to hire infrastructure versus software development resources.

“IT Role Spectrum” or Differences between the Three Engineering Teams

The most striking differentiation between the three teams is the reliance on vendor technology versus custom built technology.  At one end of the spectrum is the infrastructure team which is 100% reliant on vendor technology.  I can’t imagine any MidWestern company in the present that is ordering individual PC components and assembling their own PCs or servers.  Even when I was first introduced to corporate IT infrastructure back in the very early 1990s, companies were buying complete PC and server solutions from vendors, not building their own.  At the complete other end of the spectrum is the software development team that will use a programming language that may involve some separately licensed third party components, but primarily is completely custom building technology with every detail of what is being built known to the team.  Even software development third party components are designed to automate some aspect of the software development process that every piece of software needs, such as displaying information in a table or rendering an image.  Since the components are destined for a team that demands customization and flexibility, the components by design are extremely flexible in nature with significant transparency on what functions they perform so the development team still is in complete control of the technology.

Thus you have what I am calling the “IT Role Spectrum”:

As you slide from the left to the right, your hardware focus shifts to a software focus and your vendor management/dependency goes from exceedingly high on the left to practically non-existent on the right.  Thus, as an example, integration teams need a bit of knowledge and experience from both sides of the spectrum.

Managing Different IT Engineering Teams

Now, finally on to answering the original question of what are the differences in managing these teams?  Let’s start from the left side of the spectrum:

Infrastructure Team Management

It has been awhile for me, but thinking back, the first thing that stands out is the likelihood that your team is made up of more junior level folks.  Individuals that are starting out in their career based on tinkering at home with computers and networks and Internet connectivity, finding it interesting, and getting into the work force motivated by those interests.  Or, if not their first IT job, possibly their second coming into an infrastructure team from a company help or service desk function.  These individuals are that guy or gal that builds up their skill set providing technical assistance over the phone and wants to keep learning by becoming more hands on.  Depending on the size of the organization, these may be formal cross department job transitions or a job change within an existing team.  I am certain there are probably other motivations for individuals to want to get more hands on with technology, but the theme I recall is a tendency for aspiring IT engineers to want to continue to get more hands on with technology.  Similarly, with low barriers to entry comes propensity to join, reach a learning plateau and then move into another role outside the team.  Thus, turnover is a challenge for an infrastructure manager.

This tendency for more junior resources puts an additional burden on a manager.  As a manager, you have probably been exposed to a number of business-isms that dictate patterns of service behavior.  Examples such as the larger the office, the higher priority that should be applied to corresponding requests.  Priority is kicked up another notch if the office has a door, or a couch, etc.  Administrative assistants need additional priority above and beyond the “a level 4 ticket is a 2 day response and 5 day resolution SLA” standard.  Additionally, certain individuals, regardless of rank or file, require a higher level of service because they have direct lines of communication to important people or your management.  Thus, these people need high touch service even though the rules and SLAs don’t indicate that they should.  Inquisitive junior resources need extra coaching from their manager to help put these business-isms into a context they can understand.

Additionally, infrastructure as a whole is constantly been squeezed for cost efficiencies.  Infrastructure teams aren’t growing in size and service catalog in proportion to other areas of IT.  Thus, more coaching and context setting for junior resources is needed to explain why the workload is increasing and yet the staffing support is not.  Plus, infrastructure is ever increasingly viewed as the same as turning on a light switch.  It is just expected to work.  Corporate email systems are the perfect example of this.  I bet if you get a hold of your contingency planning or disaster recovery strategy documentation, email is listed as not a mission critical service to restore.  Customer systems come before most corporate systems.  But anyone with infrastructure experience knows that massive panic and dooms day scenarios erupt when corporate email is offline for even a few minutes.  Infrastructure is just expected to work all the time without fail.

This pressure to have constant 38 nines uptime for infrastructure services makes it challenging for a manager of an infrastructure team.  The biggest hurdle I see for new managers is to choose between empowering team members to do the work or take on the most critical changes and service outages yourself.  The later seems like the easiest.  Based on your wealth of experience compared to your team members, just roll up your own sleeves and take over the hard stuff.  That way, you can avoid the disaster that is the failed infrastructure service or maintenance change that results in blowing up something senior management can’t live without, even for two seconds.  Sure, it seems risky to delegate to a more junior team member to implement that patch or update, thus just do it yourself and you know it will get done right.  But is this really the best approach?  [Look forward to more on this topic in Part 3 of this series]

Infrastructure Management Summary

• Junior resources = more management coaching/mentoring involvement
• Cost reductions = continually pressuring staff to do more with less and justify requests with data (ROI, etc.)
• Focus on up-time = little room for error, thus need to balance do it yourself with staff empowerment

Back to answering the original question of what are the differences in managing these teams?  Let’s go to the right side of the spectrum:

Development Team Management

If one could imagine an IT team that is a juxtaposition of an infrastructure team it would be a development team.  Instead of a heavy reliance on vendor products, you have a heavy reliance on internal knowledge.  Instead of having to build up a knowledge base based on usage and vendor interaction (infrastructure), you have the knowledge built up from the development team along with the software and applications as they are being constructed.  Instead of having to reverse engineer how the user base is interacting with the technology, you have some level of uses cases that were part of the design effort to build the applications and software so the user base can actually use it.  Instead of “I don’t know, let me open a ticket with the vendor”, you have “I don’t know, let me look at the source code”.  Instead of “we can’t do that until the vendor provides the next version next year”, you have “we can do that, should we fit that into the current development effort as a requirement?”  Hopefully you are getting the picture of the differences in approach due to the total reliance and total lack of reliance on third party and/or vendor components within the technology between the infrastructure and development teams.

Thus, one of the first challenges you have is to manage the scope of work requests.  Since you have no perceived vendor or external limitations, given enough time, your resources can develop anything.  Thus, in managing a development team, you have to have some methodology to blend requirements, resources and time.  Thus, you also have to mentor and coach your team to work within these parameters.  If not, you may have a bunch of “hey, we can do that” adding up to over promising features that can’t be delivered within the time frame needed.

Another challenge is leveraging some mechanism or methodology to assist in prioritizing development requests.  If business product owners have a direct line of communication to a development resource or team, they will most likely drive the prioritization.  Thus, as a manager, you need to constantly coach your team to redirect requests back through some sort of prioritization process to ensure appropriate visibility.  I’ll cover more on this concept in a future article, but lack of attention in this area will lead to problems in over architect-ed solutions as well as minimalistic point solutions that don’t scale to handle minor tweaks in the supported business process.  All of these combine to frustrate your team since they aren’t seeing their work being received well by their end users.

A third is constantly looking for ways to get your staff to share what they are working on and how others can avoid reinventing the proverbial wheel by developing a solution to a need that has already been developed by another individual.  Thus, a manager is challenged to constantly look for ways to get team members to collaborate and share what they are working on, etc.  At the same time, balancing the value each individual contributor makes with their personal goals and professional aspirations.  Finding a balance increases efficiency both in development and testing.  It also reduces maintenance costs by not having to maintain fifteen different ways to do the same business function.  Lastly, reaching that balance finds your team members more engaged and more positive about their overall work.

Development Management Summary

• Creative resources = need to be coached to drive all feature/requirement requests through the project methodology in order to avoid over promising
• Resources working on correct work = resources need to be coached to only work on feature/requirements that come out of a formal project or prioritization process
• Resources need to collaborate yet be recognized for individual achievements = need to manage resources to share what they are working on and use common solutions to problems rather than invent your own and at the same time, balance their individual achievements against the combined achievements of the team

Back to answering the original question of what are the differences in managing these teams?  Let’s go to the middle of the spectrum:

Integration Team Management

In MidWestern companies with considerable vendor product deployments, there are teams that are not 100% infrastructure focused and not 100% pure software development focused which lands them somewhere in-between the two teams above.  I’ve labeled this middle as “integration teams.”  In managing these teams, a manager has to juggle the same challenges as both a development and infrastructure manager.

You may find yourself managing junior resources and thus have to invest time and energy in coaching and mentoring them on business-ism as well as drive junior team members to document more what they are doing as well as follow instructions from senior members in order to achieve consistency.  Having “Bob” be the only one on the team that can install product X on a particular operating system is not scale-able.  At  the same time, having “Bob”, “Sally”, and “Joe” each install the same product on the same operation system three completely different ways makes for a propensity for defects or issues as well as a troubleshooting nightmare in the future when “Bob” needs to solve a problem on a system “Sally” originally installed.  At the same time, a manager needs to divvy up the work so that junior resources get some challenging work rather than it all go to the senior members.  Throw in deadlines and the risk of a junior resource “learning on the job” and you have quite a balancing act going on all the time.

You also have to manage requirements and feature requests with a similar level of vigor as in software development and keep your resources all on the same page with these requests.  Sure,  the vendor may have a feature called “auto-enables the coffee machine to start brewing when the first person comes into the office” but until the product is installed in your company’s environment and the feature is turned on a tested, there is no guarantee it is going to work as all stakeholders think it should work.  Thus, a manager has to coach team members to be cautious about promising features without the appropriate caveats of testing prior, supportability, etc.

Another challenge is in managing creative team members.  Similar to software developers, if a vendor feature doesn’t quite work as desired, an energetic resource might break out the vendors API* and start developing the desired functionality.  Once promised and or deployed, now one has to maintain that customization through patches, fixes and version upgrades.  What seemed like a great benefit to the team member has become a cost and maintenance nightmare.  Thus, appropriately coaching resources to avoid making customization commitments without your full support is critical.

Integration Management Summary

• Junior resources = more management coaching/mentoring involvement, focus on consistency across multiple resources yet keep challenging each resource safely to keep all engaged
• Creative resources = need to be reminded to drive all feature/requirement requests through the project methodology in order to avoid over promising as well as include testing/verification of all features
• Resources working on correct work = resources need to be coached to only work on “approved” work in order to avoid driving up costs with maintaining custom enhancements

Hopefully, after reading this article, you have a greater appreciation for management nuances between the three teams I’ve presented along the “IT Role Spectrum”.  Building on the points present in this article, part 3 in the series will offer some helpful tips aligned with each team’s unique management challenges.  Look for part 3 to be available soon.

*API = An Application Programming Interface (API) is an interface implemented by a software program to enable its interaction with other software. It is similar to the way the user interface facilitates interaction between humans and computers.

IT Engineering Spectrum

Someone noticed, when reviewing my work experience on LinkedIn, that over my tenure, I’ve had the opportunity to manage both IT infrastructure teams and IT software development teams.  They posed the question:  What are the differences between managing the two different teams? This question got me thinking.  People that focus on infrastructure compared to software development do represent potentially opposite sides of the IT engineering spectrum.

With that question in mind, recently, I had the chance to interview Jim Shelton, Executive Recruiter; Information Technology for MRI North Canton to get his perspective on the differences he sees in MidWest IT managers looking to hire infrastructure versus software development resources.  Given his 11 years in sourcing IT talent for MidWestern companies, I thought his perspective would be valuable and no surprise, it definitely was.  Below is an excerpt from that recent interview:

QUESTION: Jim, can you share a brief bit more about your role and history in recruiting IT talent for MidWestern companies?

ANSWER: I sure can.  I work for Management Recruiters – North Canton, Inc.  I started recruiting in the IT space back in April of 1999.  I have truly found the thing that I really love.  You see my background is that of an IT professional.  I have a Computer Science degree and started my career as a software developer back in the late 80’s.  I believe this foundation along with my desire to help people improve their lives and realize their dreams is what contributes to my success in recruiting.  Because of my experience, I have been recognized several times within and outside of the MRI organization for effectively solving my clients staffing problems.  The accomplishment that I am most proud of is that over 70% of the people I have helped to find permanent positions are still with the companies where they were hired.  This compares with the industry average of less than 40%.  This is the major reason I enjoy a better than 50% rate of repeat business from the companies I consider my clients.

QUESTION: So, when a hiring manager approaches you for a talent search, do you approach developing a search plan for infrastructure resources differently than software development resources?

ANSWER: Not at all.  The search process boils down to having relationships (people you know), initiating conversations, sharing information, and asking if they have any suggestions.  It’s simple networking.  This could be described as the basics of executive recruiting.  Where things differ is having the knowledge and skill to be able to effectively target the type of individual that the hiring manager is seeking to locate.  The best performing recruiters are able to ask the right questions to gather the correct information that allows them to effectively discover the pieces of information that is going to help them hone in on the “right fit” person for the position being described.  A common fallacy is that a job description does an effective job of conveying the type of person that a client is seeking.  A simple example is this.  You say that you want some M&M’s.  I go to the store and I buy plain chocolate M&M’s.  I give them to you and figure my job is done.  You say this isn’t what I wanted.  OK, what did you want then?  You said M&M’s and these are M&M’s aren’t they?  You say, I guess that’s right but I wanted the Peanut M&M’s.  So, I go to the store and I buy Peanut M&M’s.  I give them to you and figure my job is done.  You say this isn’t what I wanted.  I think you can begin to see my point.

So, the whole process begins with a thorough initial interview with the hiring manager and then we develop the search plan.  All search plans will include utilizing direct phone calls to targeted individuals, e-mails to both targeted and more general contacts, e-mails and phone calls to contacts gathered from internet resources, posting to internet job boards and social media sites, name gathering activities targeting companies with similarities to the search requirements, etc…

To summarize, the way you develop a search plan doesn’t differ.  The way you approach the resources doesn’t differ either.

QUESTION: Obviously the technical skills needed are quite different between the two, but what commonly exists across both roles?  I am thinking there maybe some common soft skills … what are your thoughts?

ANSWER: Another common fallacy is that recruiters are always looking for the “A” players.  I commonly describe these professionals as having the full package, excellent technical skills, excellent soft skills, and superb business acumen.  The reality is that depending on the need of the client could determine if Superman is appropriate or if “Clark Kent” will do!  Once again, it all comes down to the defined need.

The soft skills that are generally important are communication skills, both verbal and written, and general business knowledge (this is what I refer to when I say business acumen).  Another common characteristic that differentiates technical talent is industry experience.  Companies love to hire people that already have a general sense about their business category.

Some more specific “soft skills” would be things like leadership, tact (political awareness), personality, critical thinking skills, and attention to details.

QUESTION: In your experience in interviewing full time or contract individuals looking for work, do you find the two IT disciplines have common non-technical candidate traits or do you find a definite split between infrastructure candidates and software development candidates?

ANSWER: It’s bad practice to generalize things with a broad brush because there will always be exceptions.  So, I don’t think there are common traits in either group that would differentiate them, one from another.  You know they are all people.  I’ve always said people are people.

QUESTION: Have you ever been asked to source a senior candidate that can perform both roles equally well?  Do you find those individuals with deep skills in both areas easy or hard to find in the market?

ANSWER: It’s pretty common to think that in small to mid-size organizations that companies would ask me to locate an IT manager that can manage the entire IT function both the software development side of things as well as the infrastructure.  It is true that I have found it is a unique person that has grown up technically with expertise in both software development and infrastructure.  So, most IT Managers in these size of companies manage best the area where they are most experienced.  It is not uncommon for a company to have high turnover within one of the two disciplines simply because the area that doesn’t perceive their value to be equal to the other will have employees that don’t feel appreciated and valued the same as the other.  Even though this is the case, I am not generally turned to surface these type of managers because I charge a fee for my service and companies that are looking for a “specialist” are more inclined to use my service than a company that believes they really only need a generalist.  This is a mistake that is made because the leaders of the company interpret someone that has background in both IT disciplines is a generalist and not a specialist in any one area.  For purposes of this discussion, if a company was looking for a leader of their IT function and they wanted that person to be equally experienced in leading both software development and infrastructure functions they will have a difficult time in locating that person because it is most common that an IT leader has grown up technically on one side of the house or the other.

I do think it is an uncommon skill set and these type of individuals are difficult to locate.

QUESTION: Based on your experience, do you have any candidate coaching tips as far as how to position their resume and how to present themselves for an infrastructure position to a Midwest company in the current job market?

ANSWER: My advice in this market is not different than in other markets.  The key to finding positions is having relationships that you can network with to help you locate openings.  Experience tells me that a person referred by someone that has a connection with the decision maker, however remote that might be, is more likely to receive an interview than one that has no connection at all.  I know this won’t sit well with those that are unemployed right now but, the best time to position yourself for your next position is to be involved in the community of like skilled professionals.  The relationships that you develop while you are employed are the ones that you will connect with when you are looking to make a move or unemployed.  If you work in a large company, get to know as many people as possible within the company, stay in touch when they leave your company, you may need them in the future.  Also, join organizations, offline and online communities, volunteer, etc…  It really doesn’t take that much time it just takes effort.

Sure you want to use job boards and other sources of advertised jobs but don’t limit your search efforts to these.  If you want to get into a company, use your resourcefulness to try to locate connections that you might have that might know someone in the company and ask them to hand deliver your resume or forward from their e-mail to the proper person hiring.  They don’t have to endorse you, remember your just trying to get the opportunity to interview for the opening.  After securing the interview, then you will have to do the rest!

QUESTION: Same as the previous question but for software development candidates?

ANSWER: Answer is the same.

QUESTION: Do you have any advice for candidates that are currently in house and are looking to become a contractor or vice versa in today’s Midwest IT job market?

ANSWER: My experience tells me that most independent contractors became contractors due to their current employer making the decision to outsource the job they were currently doing and the management approached them to become a contract employee instead of an in-house employee.  This is the ideal way to become a contract employee.  Other than that, becoming a contractor requires a special person that not only enjoys doing their IT jobs but, also, enjoys the challenge of locating the next assignment.  I would say that the grass is not always greener on the other side.

At this point in time, rates for most contractors are at an all-time low.  There is less and less contract work and more and more contractors that are available for the work.  If you remember your economics classes, I think you can understand what I am saying.

QUESTION: Lastly, for both infrastructure and software development positions in Midwest IT companies, what are the most in demand skills for each that you are being asked to source?  Is there a noticeable trend for more contract or more in house positions for each?

ANSWER: I’m the type of person that always tries to answer questions directly and this question frustrates me because I have to answer it with a somewhat vague response.  I am definitely seeing more demand for contributor (non-manager) level positions than anything else.  The mix of demand for infrastructure resources vs. software developers is about the same.  But, since I don’t really specialize in any one technology, the technology mix is all over the place. VB.Net, Java/JEE, citrix, vmware, AIX, C#, SQL SVR, t-SQL, DB2, MCSE, MCSD, CISSP, Oracle Forms, PL/SQL, Windows, AS400 (iSeries), etc…

Across the board, the trend is leaning more toward contractor vs. perm.  As a whole, companies continue to be cautious about adding headcount.

This has been a very difficult 24 mos.

Jim, thanks much for taking the time to sit down with me and chat about what you see in the MidWest IT market for both infrastructure and software development positions.  As always, appreciate your experience and wisdom in this area.

Look for Part 2 to dive into the aspects of managing these two different teams.  Plus I’ll argue that a third team also exists within the IT engineering team spectrum to be posted soon.

How do you build a strong team?

Some find having to go to work every day … day in and day out … to be a drag, but if you have ever worked on a strong team, you know that that drag isn’t so bad because you have peers around you with a sense of team work that has everyone pitching in to do quality work with a strong sense of pride.  In the previous article I elaborated on elements of a strong team.  This article picks up where that article left off … how does one go about creating a strong team?

How do you know if you are on a strong team?

Simple, you can cite current and frequent examples from your day to day work that align with the elements shared in the previous article.

How does one go about creating a strong team?

A bit harder … up front, a strong team culture, as so often quoted, starts at the top.  The team manager must take steps to foster such a culture.  Micromanaging the team is a sure way to block any sprouting of a sense of strong team.  The manager needs to set the tone that cooperation and teamwork is favored and rewarded with shameless self promotion frowned upon.  Empowerment or more simply, allowing people to do their jobs with low supervision and coaching rather than pointing out failures or frequent “is it done yet?” status queries goes a long way to encourage teamwork.

A team lead or manager also needs to show an outward passion towards the work the team is doing; including taking an interest in what each team member is doing such as listening to what they are getting excited about.  Is it that new development component that enables all kinds of rich UI features?  Is it that next platform upgrade that includes an ability to take a virtual snapshot of a box nightly to aide in troubleshooting those “happens once in awhile, but when it does …” problems?  Is it that emerging architectural standard that will make a great cup of coffee while curing cancer at the same time?  Technical people get excited about aspects of technology that align with their interests.  In leading a team, being aware of professional interests and looking for opportunities to steer those interests toward current and future service demands will help to create a sense of a strong team.  Team members seeing their interests align with work requests will instill a true sense of importance with each individual.  This creates a real notion of “my ideas are being heard and acted upon” and further supports the concept of a strong team described in these articles.

Another opportunity to build a strong sense of team is to try and emphasize a narrow focus for the team’s services.  “We do this, and we do this … of, and we also do this other thing once in awhile” will tend to water down the team’s focus.  In watering down, the team members will see very little overlap in what they are working on with other team members.  With little overlap comes little drive to cross communicate, share items, help solve each others problems, etc.  Sure, a team most likely provides multiple services, but by bringing those disparate services into a more singular and common theme, team members will begin to see how their work overlaps other team member’s work.  With more overlap, team members will be more inclined to share ideas and communicate.  Individuals with technical problems will feel more apt to share since others may have worked on similar issues rather than assume they are a one person silo and will continue to plod along trying to solve the issue on their own.  Also, to reinforce this sharing, as a team manager or lead, try to mix up who is working on what group of tasks.  If Bob is the printer expert, try to avoid routing all printing problems to just Bob.  Not only will Bob grow tired of being the printer guy, he will have no one else to chat with and generate new ideas and approaches to printer problem solving.  Plus, as an added bonus, mixing up the task handling will increase your team’s ability to handing spikes in requests, increasing work throughput, and reducing single points of service failure.

What other external factors develop a strong team?

As a leader, one can try all of the above techniques and achieve some degree of a strong team, but external forces help to bump up the sense of team even further if handled positively.  One external factor that a team led or manager has no real control over but he or she can leverage to their advantage in creating a strong team is having a small team being charged with providing services within a larger organization.  The theme of being the under dog that is struggling to succeed against some difficult odds helps to galvanize a team together with a sense of survival that ultimately builds team work.  This is also colloquially referred to as going up against the 800 pound gorilla.  It is the tried and true notion that working together against the larger “foe” will result in more success than going it alone.  One point of caution, carrying this “us against them” theme too far into a negative tone will work to undermine morale by making people uncomfortable to be pushed to be combative.  Thus, make sure to have a sense of competitive pressure in working within the larger organization but be careful not to proceed into negative territory:

Not OK: “We hate that other team!  They are terrible.  They make our lives miserable.  They can’t plan worth beans and thus everything is a last minute crisis.  They don’t know what they are doing.  We could do their jobs twice as good in half the time …”

Better: “Man that other team is demanding.  They are our most challenging customer.  Since it doesn’t look like they are going to change, what can we do to reduce the last minute crisis requests on our side?”

Another external factor that strengthens a team is going through a demanding work activity involving everyone pulling together to get the job done successfully.  The immediate example that comes to mind is having everyone pitch in together to complete a bunch of tasks for a project that has an aggressive deadline.  By pitching in and completing the work together, everyone shares in completion glory.  Under the tight time pressure, applying the approaches listed prior and acting as a coach or mentor rather than a task or slave driver can give everyone that sense of working together equaled the final success.

Anyone have any other examples of techniques one can use to strengthen a team that one has control over?  How about example of other external situations that, if handled a certain way, can strengthen a team?

Ever work on a strong team?

Do you or have you ever had the opportunity to work on a strong team at any point in your professional career?  A team where everyone has a collective sense of being part of something bigger than themselves?  Everyone had a role on the team that wasn’t defined by a Human Resources job description, but rather, a combination of skill set strengths and work task preferences aligned ultimately with what needed to get accomplished?  A team where, as work came in, everyone volunteered to own tasks and everyone else lined up to provide support and assistance?  A team where everyone knew the strengths and weaknesses of each team member plus everyone could count on each other to get the job done?  If you have, your mind is probably getting flooded with random memories of events and situations of that team environment.  Do affirmative answers to these questions actually define what a strong team means to you?

Strong Team = A team where everyone has a collective sense of being part of something bigger than themselves?

According to research by Amy Wrzesniewski, as reported in 12: The Elements of Great Managing (Wagner and Harter, Gallup Press, 2006), people want to work for an organization with a higher purpose or a mission that means something to them.  I believe the same holds true for a team within an organization.  If a team has each team member working on separate tasks that don’t come back to a common thematic service offering, it is difficult for each team member to get a sense they work for a team with a higher purpose.  Without an opportunity to share related successes and failures and generally kvetch or vent about stressful situations that each team member can identify with, the people on the team won’t have a strong sense of team.  If common exchanges like below aren’t occurring, there doesn’t exist that sense everyone is working for a higher purpose:

Bob: “Hey, working with Larry in Accounting is really a challenge.”

Sally: “Yah, I know.  I dread getting requests from him.”

Bob: “What is his deal anyway?”

Sue: “You guys talking about Larry in Account?”

Bob and Sally: “Yes”

Sue: “Oh, he is easy to work with.”

Bob: “How so?”

Sue: “He just gets very nervous when his PC doesn’t work exactly the same each time.  If you move his icons around or patches or updates cause his PC to work just slightly differently, look out, he is going to freak.  Just let him know nothing is going to change and fix whatever he needs and you will be fine.”

Bob: “Great, I’ll give that a try!”

Strong Team = Everyone had a role on the team that wasn’t defined by a Human Resources job description, but rather, a combination of skill set strengths, work task preferences aligned ultimately with what needs to get accomplished?

Bob might be interested in how the system works together as a whole, and thus engages on tasks that are architecture in nature or involve major system upgrades.  Sally might be a bit intimidated or uncomfortable interacting directly with people outside the team but favors highly detailed technical tasks and thus gravitates towards tasks that fit this description.  Joe might be losing his zeal for highly technical tasks and would rather interact with people to establish the more detailed requirements on what needs to be accomplished and thus provide specifications to Sally.  Sue might be a bit junior and thus gravitates towards the more mundane, repetitive tasks that increases her confidence in her abilities but everyone else see as low challenge work.  Yet, on the HR side, everyone is either a “Systems Engineer I” or “Systems Engineer II”.

Strong Team = A team where, as work came in, everyone volunteered to own tasks and everyone else lined up to provide support and assistance?

Building on that sense of everyone working for something bigger than themselves comes the way incoming work is divvied up amongst the team members.  A sure sign of a weak team is when the team lead or manager has to monitor all in coming work requests, specifically assign out tasks with exhaustive granular detail and follow-up with status meetings and the always dreaded status reports.  At the opposite end of the spectrum is the strong team were as work comes in, everyone assimilates the work without having to wait for their assignments.  Instead of the manager or team leader acting as a task master, instead, they provide guidance as to how to handle competing priorities as well as context behind requests.  This team dynamic involves each team member being aware of their implicit role within the team as well as the strengths, weaknesses and interests of all other team members rather than:

Systems Engineer II: “This work should be assigned to a ‘Systems Engineer I’ and I’ll go back to my desk and surf the web till something fitting my job description comes in.”

Junior resources know the typical IT technical hierarchy where “senior” resources became senior resources by having tenure defined by having rolled up sleeves and made things work to the state the system or service is in at present.  Junior resources know they have to respect this effort and accept more junior tasks until one can grow into a senior resource.  Senior resources know they were once junior at some point and thus are open to assisting fellow teammates.  Junior resources know they need senior resource to help them get their work done; yet, they respect senior resources time and workload and thus only engage after trying all avenues on their own first.  All these combine into a natural divvying up of in coming work requests favoring each person’s unique skill set and interest yet with everyone mindful all the work has to get done on schedule.

How do you know if you are on a strong team?

Simple … you can cite current and frequent examples from your day to day work that align with the elements above.

How does one go about creating a strong team?

Look for part 2 to share some thoughts on how to go about creating a strong team.

Some find having to go to work every day … day in and day out … to be a drag, but if you have ever worked on a strong team, you know that that drag isn’t so bad because you have peers around you with a sense of team work that has everyone pitching in to do quality work with a strong sense of pride.

Anyone have any other examples they can share that captures the elements of working on a strong team?

Does the MidWest really need recruiting "want"?

For his first post of 2010, Rands shares his perspective on the need for ensuring the recruiting process carries the theme of making the desired candidates feel wanted, both from the company recruiter as well as the hiring manager. The article is well written as we have all come to expect from Rands in taking the example of a candidate, Jesse, who has accepted a position extended by Rands but at the final hour, declines the offer to stay with Jesse’s current employer. Rands’s conclusion is that Jesse wasn’t made to feel “wanted” enough to leave his current employer.

As I read the article, I reflected on my almost 20 years of IT experience in the MidWest and I could appreciate Rands’s supposition of “wanted-ness” driving employee employer alignment, but I could not find any parallel experiences in my past nor any stories from peers that could mirror this “wanted-ness”. So, I got to thinking:

“It seems difficult to refute “wanted-ness” as solid goal for all IT organizations regardless of geographic predilection. What might make it less of a priority for a MidWestern company to employ such talent attraction tactics as Rands supposes? ”

This first thing that comes to my mind is the labor pool. If you are working in a labor market that favors MidWestern companies as I’ve attempted to define them in this blog, your labor pool maybe heavily impacted by some/all of the following:

• Aging work force
• Younger work force moving out of the area
• The “brain drain” or local college grads leaving the area upon graduation
• Buy instead of Build IT mentality

NPR has a good article on the perspective of the “brain drain” on the MidWest labor market here if you haven’t been exposed to this concept prior.

Thus, if the labor pool is known to be composed of relatively few super starts in any given category, do MidWestern IT organizations need to go to great lengths to offer rock star recruiting techniques or put energy into creating a high degree of “wanted-ness”? I think the answer is: not really.

But wait you might say, doesn’t Economics 101 say if the supply is trending low, and demand is trending high (you need to hire someone = trending high), then MidWestern companies should be investing heavily in “wanted-ness” to attract top IT talent to meet demand?

Here is where I offer that the “Buy instead of Build IT mentality” drives the demand curve back down. If an IT organization is conducting significantly more “buy” activities than “build” activities, the labor demand is less for that rock star engineer, but rather, an engineer that can work with the vendor’s organization to integrate the vendor’s technology into the company’s existing technology. Thus, a rock star engineer, who wants to be building not integrating, who is offered a highly generous compensation package along with “want”, would be easily disappointed and look for a more pro-build opportunity in short order. So again, the economics coupled with the “Buy” emphasis drives down the demand curve so it is more inline with the labor pool supply curve.

With the demand curve inline with the supply curve and the overall “rock star engineer” need being eclipsed by the value proposition provided by the “Buy” vendor equals a strong excuse for a MidWestern company to skip going above and beyond to create a sense of “wanted-ness” for ultimately more average hires.

The second thing that comes to mind is the labor market itself. In my opinion and from the limited researched I was able to conduct, the decade of the 90s drove up the demand for IT resources in the MidWest. The dot-com bubble bursting in the 00s took the MidWest IT labor market backwards significantly without a subsequent major recovery. To put that perspective to numbers, from a report from the Center for Urban Economic Development, University of Illinois at Chicago, the below graph shows the year over year change in IT industry employment across the entire US:

Breaking this data down more regionally and comparing the major MidWest city of Chicago, IL to other non-MidWest major cities such as Dallas, Boston and San Francisco for their 1999-2005 IT industry employment shows all non-MidWest markets seeing greater net job increases for the period compared to Chicago.

Even less scientific, a recent same day search of Monster.com, Inc. for “Information Technology” jobs using the default search settings for the following cities reflected a similar perspective: major cities outside the MidWest tend to have at least four times as many job postings as MidWest cities.

Cities from CUED list above:

Chicago, IL 628
Boston, MA 831
Dallas, TX 582
Los Angeles, CA 623
San Francisco, CA 455
San Jose, CA 407
Seattle, WA 406
Washington, DC 2110

Other Cities:

Atlanta, GA 608
Cleveland, OH 127
Cincinnati, OH 132
Detroit, MI 183
Saint Louis, MO 218

With MidWest IT needs being significantly less aggressive than higher IT resource demanding areas such as from the coasts, do MidWest IT Organizations really need to invest heavily in the “want”? My opinion with this data suggests no, this isn’t a priority compared to other regions of the US.

Ok, what is the point of all this? My analysis suggests:

Although Rands makes a compelling argument for the value of ensuring the “want” is pervasive throughout the recruiting/hiring process, that value is significantly impacted by the region of the US. Specifically, that value is significantly decreased in the MidWest where the labor pool in conjunction with the labor market suggest fewer and fewer qualified resources are competing for fewer and fewer jobs. Although somewhat cavalier to title this article “Not Wanted” when indeed, a job opening by definition means “want” to some degree; the need for a MidWestern IT organization to go to great lengths to create a culture of “want” in the hiring and recruiting process seems to be unneeded.

Anyone see a glaring oversight in this analysis? Anyone have a compelling argument that suggests another perspective increases the “want” value in the MidWest IT recruiting process?

In the throws of performance reviews and feedback activities, I’ve started to form in my mind the concept of opinion boundaries as it pertains to work team interactions.  As you know from this blog, the significant bulk of my professional work experience has been in IT.  Thus, this concept of opinion boundary has been birthed from IT but very well could apply in other professional disciplines where disparate teams with specific service outputs come together to provide a combined product or service.  I would be curious to hear from folks outside of IT that experience this concept in their work places and under what circumstances does it manifest itself.

Keep your opinions within your realm

First, let me paint a picture of what is creating this opinion boundary concept in my mind:

Hypothetical meeting between a Software Development Team tasked with building a new application and a Database Team that is tasked with providing Database services to applications for the whole company.

Software Development Team: “Ok, we have been asked to build a new application called X that will take in manually entered information from paper request forms and allow each form to be assigned a unique identifier so the five steps to complete the request can be tracked by the new application.  We have a database design we can provide.  What else do we need to do in order to get a database available to us in order for us to start developing?”

Database Team A: “Hey, are you writing this application in Ruby on Signposts?  If you are, you should consider using at least version 2.5 because we’ve heard of performance problems in earlier versions.  Also, have you considered how your data layer should talk back to the UI?  We’ve heard of a group that had problems with the standard PC build, you should talk to the platform guys on that.  Hey, we know that in general, development shouldn’t start until all the requirements are finalized … do you know if the business signed off on the spec yet?  Oh, and we think …”

Compared to a response such as:

Database Team B: “Ok, we just need to know some initial pieces of information from you in order to ensure we can configure a database that will work for your needs and that we can support.  What development language are you using?  Do you have any disaster recovery requirements beyond the default ones for the company?  Do you have any specific needs beyond the core database services of X, Y, Z…”

Note: This is by no means a reflection of database teams in general.  The example attempts to portray one group that needs services from another group in order to deliver their work product.  I chose the example of a software application team needing a database from a database team as a representation of a common use of centralized IT services, in this case databases, being provided out to distributed groups that all need to leverage that common service in order to ultimately provide their service.

The different responses are striking in that the first exhibits seemingly no boundaries to the opinions this hypothetical Database Team A has outside of their core service offering compared to the second from Database Team B.  Team B recognizes the boundaries of their service compared to the requesting team’s needs and has derived an interaction strategy that focuses on determining the most logical touch points and associated technical considerations between their service and the requestors.  Team B does not cross that touch point boundary and encroach on the subject matter aligned with the software development team.

Over the years, I found the most successful cross team partnerships consistently involve a clear opinion boundary.  Opinion boundary being a respect for the needs of the other team and structuring a service interaction model that defines the service touch points in terms of what the requestor needs from the provider as well as clearly explained constraints the provider has to exhort on the requestor in order to ensure the provider’s service can meet their service expectations across all requestors.  And finally, refrain from offering any opinions that break the touch point barrier.

What I have struggled to assemble is what drives an individual or a team to have such a strong need to offer opinions on subject matter outside of their role or service within the organization to such an extreme?  In the utmost extreme case, the only logical conclusion I could draw was that the team was extremely weak skill set wise in what they were tasked to do and used such a tactic to misdirect requestors.  In the process of misdirecting, they seemed to be hoping one of two things occurred:

1. The requestor would find another service provider and thus never return (seemingly odd, but in a very large IT organization it is likely to have multiple teams providing similar enough services that one can meet their business objectives via multiple options)
2. The requestor was hoping the misdirection would require more people to get involved to ultimately map out exact what the provider needed to do at a detailed level that ultimately filled in for their skill set gap.  “Oh, you actually wanted us to provide that?  Oh, that … sure, we can do that.  It wasn’t clear to us initially that you really wanted that.”  Using such backtracking to agree to perform the granular tasks outlined to them from a more senior resource outside their team.

Another is shear ego whilst the provider wants to talk to hear themselves talk and feed their sense of importance for the duration of time the requestor needs to confirm the use of their services.  In other words, for the requestor, suffer through the chest beating and technical pontifications in order to ultimately get the service required in the end.

Anyone have a different definition on option boundary as I have described it or knows of alternative motivations for someone or for a team to interact in these manners?  Anyone find this applies outside of IT?