MidWest IT Survival

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?

From both an IT engineering and management perspective, I find it very easy to fall victim to groupthink.  Groupthink is defined by Irving Janis as “A mode of thinking that people engage in when they are deeply involved in a cohesive in-group, when the members’ strivings for unanimity override their motivation to realistically appraise alternative courses of action.”1 To illustrate groupthink in the IT world does a team meeting scenario like below sound familiar?

Impromptu Team Meeting in the Conference Room

Is venting starting to turn everyone too negative?

Bob the Engineer <very agitated>: “Geez, that project ‘critical path’ regroup meeting was a huge pain!”

Sally the Engineer <visibly frustrated>: “Yah, if only the project managers were listening to us all last month when we were telling them their schedule was ridiculous!  There was no way back then the work was going to get accomplished when their fancy project plans said it would and we told them!”

Joe the Engineer <rolling his eyes>: “How many times are we going to have to attend these silly ‘we knew were going off track a month ago but we did nothing so now we need to have a meeting to chat about why we are suddenly off course  …’”

Bob the Engineer <speaking over Jo>: “We are going to have these meetings as long as the PMs keep ignoring our work estimates.”

Sally the Engineer: “Yah, when will they ever learn?”

Groupthink is any easy trap to fall into.  Yet, in my opinion, fostering a team climate for which there is an opportunity for such venting provides benefit to the entire team.  With a team sense of shared success and shared pain, the team climate evolves to allow team members to be open with their teammates and their manager on problems, issues, challenges and successes with more candor.  The openness breeds more open communication and cooperation plus ultimately leads to high quality output in less time with problems surfacing and resolving earlier in the work processes before they become disasters.  Yet, left unchecked, this venting can take the team as a whole deeper into the short term comfort of the shared pain and away from the need to look at opportunities to avoid the situation that causes the pain in the first place.

It is time for someone to be a leader and jump in and pull the team back from the precipice of groupthink.

Boss/Engineer: “OK, OK, ok … we all know the PMs get themselves into this situation more often than seems warranted.  How about we brainstorm on some creative ways we can do things differently going forward so we don’t have to sit in these useless regroup meetings?”

As an Engineer, this is a great opportunity to demonstrate leadership skills in front of your boss with real credibility.  As a Manager, if no one on your team is stepping up and the level of negativity is rising, you may have to step in with similar comments to redirect your team to focus on positives before the negatives further spiral the team down a bad path.

Anyone have any perspectives to share on groupthink?  Anyone have a technique or example where groupthink was avoided or not avoided resulting in a bad situation getting worse?

1. Janis, Irving L. Victims of Groupthink. Boston. Houghton Mifflin Company, 1972, page 9.

I recently enjoyed this article [http://bit.ly/4fcas] on the concept of “Managing Up” or actually titled “10 Ways to Make Your Boss Love You”, by Anne Kadet of SmartMoney.com. As I was reading the proposed ten ways, I was finding myself switch back and forth between IT manager and IT employee and finding consistent examples of each point in my career.

Make Like Mini-Me

For number 9, “Make Like Mini-Me”, Kadet restates an old adage: “They say that if you want to be the boss, you should dress like the boss”. I was reminded of a manager a few employers back that was constantly commenting on people in his department’s dress. Was a particular female wearing slightly revealing clothes for his department? Was a particular male wearing regular jeans and a casual shirt for a one on one meeting with this manager? He was constantly making these comments to my manager, but never to me, about the folks on my team. Thus, my manager would have to relay the information to me and then I would have to strategize on how to get the message across to the employee in a way that the employee would accept as process-able feedback. Thus began my learning of the art of communicating illogical, non-technical information to primarily logic focused IT engineers (another article in the works for this one).

For number 1, “Put in the Hours – When It Counts” definitely rings true. I had an employee once that was constantly coming in early, staying late, and coming in on the weekend. Initially this appeared as dedication. But as time went on, the focus on the hours in the chair wasn’t matching the error rate in work the individual was performing. Thus, very quickly, the extra hours became an additional negative because the energy was focused on appearance rather than results.

Number 2, “Empathize” with your manager is a winner all around. Your manager is trying to solve or at least make meaningful progress towards a better state for any number of problems. If you can offer some insight and follow-up with a possible action plan that your manager can support, you are going above and beyond your expected duties for the person that has the most influence on your day to day professional existence, a la paycheck. As a manager, I hate having to determine a solution in complete isolation. Employees that can professionally challenge my ideas or offer creative solutions for consideration become the employees I frequently engage in tactical and strategic discussions … as well as sell up the chain as being linked to successful endeavors. This blends in an aspect of number 4, “Be a Conduit” as well.

Number 5, “Ask for Help” … I can’t stress enough … sitting at your desk burning time trying to figure something out is exceedingly frustrating to a manager. I find myself thinking “why doesn’t this individual just ask the person next to them for some new ideas instead of just sitting their stuck in the mud”. The perception of asking for help equals a weak employee just doesn’t ring true with me. I find the complete opposite to be the real truth. Someone that asks a question pertaining to moving them forward on a given problem which then in turn allows them to complete a task faster is someone that is worth having on the team and even giving stretch assignments.

Lastly, Number 10 … Probably for the first decade of my career I struggled with understanding why I honestly believed I was consistently delivering quality output per my role, yet I observed others getting more recognition. The others were even viewed as borderline competent by peers. But in the later decade, I have to admit that I agree with number ten with greater fervor. The concept of strategic sucking up baffles my, at heart, engineering view that logic and delivery trump bumbling, illogic, rumor and perception. The notion of likeability over competence gives me a migraine. But as I look back over multiple Midwestern industries, this theme has been consistently reinforced. If you are finding that your own honest assessment of your work quality isn’t getting the recognition that it deserves, maybe you aren’t putting enough energy into “managing up”?

Anyone have strong feelings on these or any of the other points in the article?

First, let me create a scene to frame my thoughts:

Write it down

You are finishing up a meeting with someone from marketing, someone from audit, someone from product and finally someone from operations.  Everyone was shaking their heads in agreement to all the tasks discussed for the last thirty minutes.  It seems redundant, but you close the meeting by re-summarizing the next steps:

“Sally, you are going to let the group know if operations doesn’t have the bandwidth to handing this special customer request plus let us know the name of your operations single point of contact for this

Judy, you are going to update the marketing knowledge base to indicate we now can offer this additional product feature.

Jim, you representing audit are fine with this approach but you will get back to the group if your peers feel uncomfortable.

Sam, product is going to create a small project request to kick off the effort to make the web site able to support this new feature plus you are going to let the group know if this is part of the monthly product usage fee or a new per item additional charge.

Ok, once we have all that, IT can get started enhancing the application.  See everyone in X days at the next touch point meeting”

With more heads nodding in agreement, you walk out of the meeting believing everyone knows what they have to do in the next few days to keep this moving.  You arrive X days later to discover the response to “did you complete your assignment?” is met with “Um, I didn’t think I needed to do anything?  I thought you were handling that?  What did I need to do again?”

It seems to me more and more, if key discussions aren’t written down with clear “Jim, you need to do X by Y” and distributed to all, people tend to not be thorough in their follow-thru.

Anyone else seeing this trend increasing/decreasing or am I just going crazy?

The Art of IT Work Estimation

One topic that I am definitely still learning ways to improve is IT’s ability to successfully provide work estimates to those outside of IT in order for them to make business and/or priority decisions.  It definitely seems to be a balance between providing enough information for the other party to understand what is driving the work and at the same time, not too much information or worse, too much technical information that the other party will get completely confused by.

Some general techniques I’ve found to work across the board:

• Use a presentation style (such as Microsoft’s PowerPoint or OpenOffice’s Presentation)
• Make a recommendation
• Put yourself in their shoes

Presentation Style

It may seem like extra work to re-format what you have to say into a slide deck.  But the subtle power of the slide deck or presentation style is in your ability to lead the other party through your information in the way you desire them to be exposed to it.  As you are talking to the slides and they are viewing the slides, you are very much in control of the information that you are presenting compared to a piece of paper with stats or some full of words business case/recommendation.  Now clearly, if you didn’t do the research to gather all your support facts, no amount of talking and fancy presentation is going to convince the other party to go with a half baked approach.  The process of creating the deck on top of the analysis work already completed is yet another opportunity to think through what you are presenting and ultimately recommending.

Make a recommendation

If you have a well constructed slide deck with all kinds of factual data but don’t make a specific recommendation, you are missing a great opportunity to seal the deal.  You open yourself up to greater discussion outside of your control which might introduce new facts or worse, new supposed facts that can derail your original intention of getting a decision within your data.  If you present the facts and quickly arrive at a recommendation based on those facts, then others have to have done research greater than yours to contradict.  With a recommendation, you simplify the decisions the group has to make, which is to accept of reject the recommendation.  If you present facts and hope people are absorbing those facts to propose a recommendation, you may not be rewarded with what you need, rather, boundless discussion.  Thus, your chance of everyone having a more healthy discussion within your constructed bounds and arriving at a decision is greater with a recommendation.

Put Yourself in Their Shoes

Sure, you need an answer from those accountable for making work prioritization decisions.  Yet, your IT world is significantly different than their business world.  If you need a product manager to decide on exactly what features on the list need to be in the next release, try and figure out why each feature was added to the list in the first place.  Was it a high profile customer request?  If so, it is pretty important.  Was it operations wanting an improvement to speed up their work flow?  Important, but it is not compared to a customer request.  Is this a request that has been on the list for multiple releases but keeps slipping?  If so, it probably can keep slipping since it has already been passed over in the past.  If you need an auditor to sign off, try and put together a story that shows constant progress being made over multiple releases to ultimately close out the issue you can’t close in just one release.  Make sure it release further reduces the risk or exposure with data the auditor can take back to their team with confidence the issue is getting attention, risk is being reduced and the exposure will be eliminated in a fixed timeframe.  Having the ability to put yourself in your target audience’s shoes and thinking through what is it that is going through their mind as they are forced to make a choice of a less desirable result than “We are implementing everything everyone asked for in the next release” will help in getting support for your recommended approach.

I think I will write a series of articles on various techniques I’ve found to have more or less success with a given audience.  The above three high level considerations are probably some of the most universally applicable.

Anyone have any other go to approaches to the “we have more requirements to fulfill than we can possibled handle by X” IT challenge that they found work for a variety of audiences they can share?

What about specific techniques that work for a specific group or a specific situation?

Remind you of IT?

The first question that may be coming to your mind as you embark on reading this is why identify MidWest IT engineering and management as a separate categorization from IT engineering and management in general?  Is it because you have to consider roof strength in your data center construction so that you don’t end up with a pile of snow on your server racks?  Is it because there is a constant struggle to find key resources during the summer months or hunting season?  Well, I believe that the use of information technology in a traditional MidWestern company varies enough from a Silicon Valley technology company that existing books and articles on the skills and needs associated with succeeding have gaps.

Don’t get me wrong, there are a number of great sources of insight into how to succeed in functioning as an IT engineer or IT manager in the market.  Michael Lopp’s “Managing Humans: Biting and Humorous Tales of a Software Engineering Manager” book and associated blog, “Rands in Repose” (http://www.randsinrepose.com/) is a great and humorous source for the trials and tribulations associated with working in an IT workplace.  Yet, I believe there is a distinct difference in working for a company that primarily produces technology as its core business function (aka Silicon Valley) compared to a company that primarily uses information technology to support a non-IT based core business function (aka MidWest).  The “MidWest” categorization is being used loosely to identify all companies where IT isn’t their core product or service.  And yes, for all those reading with your brains thinking “but wait, I work for a company in the MidWest that does produce software for mass retail consumption …” I am not implying your organization is somewhat minimized compared to a Silicon Valley/Bay Area firm.  Rather, I am putting forth the notion that “MidWestern” companies, by and large, tend to use IT rather than produce IT thus the demands on an IT professional are slightly askew to say, a dot-com in Mountain View, CA.  From banking to manufacturing to insurance to mining to legal services, MidWestern companies tend to be large consumers rather than producers of information technology.

Thus, as either an IT manager or an IT engineer within a typical MidWestern company that largely consumes information technology from others, the attributes associated with the successes and the challenges these roles demand from individuals vary.  As an example, the likelihood that you, as an IT engineer in a MidWestern company, will be assigned any given technical problem and within minutes of reading the problem description, you will be able to saunter over to the cube of a peer engineer that can instantly explain in exhaustive you-are-about-ready-to-pass-out detail how the entire system works and why the problem is indeed a problem because he/she wrote the system … is exceedingly unlikely.  What is more likely is any given problem involves a convoluted evaluation process akin to this:

Engineering Situation:

Engineering Boss: “Bob, can you take and run with issue number 74864”

Engineer Bob: “Sure boss” <ugh>

Engineer Bob: <thinking> Ok, Sally can’t print ARS checks.  What the heck system is ARS?  I think I’ll ping Joe in the application group, he’ll know, he always seems to be working with Finance.

Engineer Bob: “Joe, do you know what the ARS system is?”

Engineer Joe: “Bob, Joe here, nope, what is the problem?”

Engineer Bob: “Joe, something about not being able to print checks”

Engineer Joe: “Checks …. printing checks … I think I remember a check printing enhancement phase 4 ruggedization project last year.  How about pinging Alan?”

Engineer Bob: “Alan, do you know what the ARS system is?  Maybe part of some check printing project last year?”

Engineer Alan: “Geez Bob, ARS doesn’t sound like …. wait, only system I know that prints check is SuperCheckPro 2000 … you might want to hit up Gary, I think he worked on that. ARS … ARS … no, I was just the QA guy on that project for the requirements gathering phase before the RFI/RFP.  Yah, talk to Gary on the second floor”

Engineer Bob: “Gary, know anything about ARS or SuperCheckPro 2000 and problems printing checks?”

Engineer Gary: “Yes”

Engineer Bob: <thinking> Oh boy, Gary is an architect; this is going to be a challenge “Gary, do you know what could cause SuperCheckPro 2000 to stop printing?”

Engineer Gary: “Lots of things”

Engineer Bob: <ugh> “If I were to need to investigate a check printing problem, what should I look into?”

Engineer Gary: “Send me the spool dump log”

Engineer Bob: “Where would I find that?”

Engineer Gary: “Under /var/logs/cp_spool on corp_unix15”

Mary from IT Compliance walks by: “I heard you are looking into that check problem … you are going to have to run this by the SOX people, right? ya know!” Mary vanishes as quickly as she appeared.

Engineer Bob: “Thanks”  <thinking> I bet I don’t even have a login to corp_unix15 … I think I am going to have to submit an ABC4567 form for that … I need to run this by the SOX people as well … oh joy.

Engineer Gary: “Send the problem over to Infrastructure … the box can’t find the printer on the network … they are going to have to open a service request with the vendor ‘cause we don’t support that printer which requires the ARS people to do that since they manage that relationship”

Engineer Bob: <thinking> Oh joy

And most problems take way more Joe’s and Gary’s to interface with in order to have any hope of getting some sort of progress on the problem.  Plus, actually seeing the problem through to resolution, which is a whole other story!

Management Situation:

Engineering Manager: “Why did I get this automated email saying our project number 789 failed the QA8 gate?”

Project Manager: “I didn’t get that email.  Can you forward it to me?”

Engineering Manager: “Yes, here it comes … I just got out of a client milestone update meeting and it would have been nice to know this an hour ago … I just told the client we are on track for 789!  Our VP already stuck his neck out and said this project was going in and would clear the client off the corporate audit report!”

Project Manager: “Got the email … let me get into the Project Center of Excellence portal site … seems we failed an architecture review committee sign off”

Engineering Manager: “What?  We are only adding ten fields to the data table because the enterprise data architects said we had to comply with the new enterprise service bus web service update that is going to push us those ten new fields that audit and compliance claims needed to be there!  What is architecturally wrong was adding ten fields their own group told us we needed to add!”

Project Manager: “I’ll check with the requirements architect to see why we didn’t get this signoff during the design review meeting last week”

Engineering Manager: <ring> “Oh great, my phone is ringing from the change management office … they are going to give me the song and dance that I am going to miss the noon cut off window for change approval.  That is going to bring the escalation heat from the change folks.  That call is going to voice mail for now.”

Project Manager: “Seems 789 didn’t qualify for a requirements architect because it didn’t score high enough on the quality gate 2 project scorecard.”

Engineering Manager: <ring> “Oh geez, word is getting out, the product manager is calling me, she is going to remind me that marketing communications have already been sent to customers based on our go/no go meeting last week since 789 is tied to her campaign due to the release cycle.  Voicemail again to buy some time …”

Project Manager: “I know Bob on the architecture review committee, I am going to try and give him a call and see what is going on.”

Engineering Manager: <ring> “It is getting better, next call here is from that guy in compliance that is going to threaten to tell the client they are going to be on the audit list as a level red due to not having those ten fields in that table by the end of the month.  This one is totally going to voice mail.  Wait!  This is going to get a whole bunch worse … our VP is walking to my cube … he never does … I think he was having lunch with the VP of product … word spreads too quickly … stay in my cube, we are going to have to explain the situation fast when he gets here.”

This could be an IT manager’s typical day with any semblance of a planned agenda of tasks to be completed for the day now completely out the window having to sort out this project mess.

In an IT environment similar in nature to the stories outlined above, a variety of non-technical skills are required to be matched with some level of technical competence in order to survive.

This collection of articles looks at these various skills from both engineering and management points of few and with a liberal dose of humor, tries to share wisdom to navigate while retaining as much sanity as possible!