Midwest IT Survival

Over Architected?

First off, I am by no means an “Agile” (nor even “agile” with a small “a”) software development expert.  There are many more individuals out there that are way more experienced and in a much better position to speak authoritatively about the Agile methodology and its associated principles on driving efficient and effective software development.  A few blogs where I consistently find great Agile perspectives are included at the end of this article.  But as I’ve participated in Agile and agile-like development efforts over the years, I’m finding an interesting pattern.  Agile and agile-like approaches have a positive by product of reducing the occurrence of over architect-ed software solutions. Over architect-ed solutions put stress on the delivery of a software application project as well as drive up the cost of software development and maintenance, in general, disproportionately to the business value produced.

As an example, a sample development effort starts out with:

Product: “We need a super widget in the product by next release, can we have that?”

Project: “We are going to need detailed requirements for the super widget in order to start developing it.”

Product: “Oh, it needs to be able to interface with the dry cleaners to know when it is time to pick up the laundry as well as make coffee for the customer before they get out of bed in the morning.  Basically the same features as our competitor’s recent release, but with these additional benefits. <Or some other description that is actionable at a high level, but lacks the detailed requirements needed to feed a development team with actionable development tasks>”

Development: “Ok, we’ll get started since we don’t have much time before the code freeze for the next release.”

… Time goes by …

A project status meeting occurs sometime in the future.

Product: “So, where are we with that super widget?”

Development: “We have the basic framework setup but it isn’t going to have all the features working by the next release.”

Product: “But I thought …”

Development: “But you said …”

Project: “What happened?  How come we are X days from the code freeze and we don’t have a viable solution?  I thought …”

Now sure, this isn’t the most perfect example of capturing how the requirements drift between stakeholders leads into an over architect-ed solution, but hopefully you get the scenario.  Or possibly another example would be when a solution is developed and released into the production environment.  Extending the example above, weeks later, when enhancements, tweaks or feature extensions are requested, a tense conversation occurs around:

Product: “But I thought the super widget would do X?  How come I am hearing it will take 30 hours of development to get X?  The testing cycle is already elongated due to the complexity of the super widget thus I thought it included X?”

Development: “But we said that the framework would support X, but we never said X would actually function without more development!  We developed the super widget to do W, Y and Z but only stubbed out X.”

Project: “But according to the requirements, it says X should be …”

And yes, an argument can be made that if:

• more effective requirements gathering occurred
• more effective project management captures more depth of what would be developed and available when
• more effective product management defines a more exhaustive product feature road map that more clearly outlines what would be available and not available when, feature-wise

… These problems wouldn’t have occurred.  But the nature of an agile-like approach puts a tighter focus on all the stakeholders:

Product: They can share the “overall vision” of what they ultimately desire the product to do, but they are forced to consider what they really need within the shorter duration of the agile-like release schedule.  Thus, product walks away with a clearer picture of what they are really getting in the next release.

Development: They get the benefit of the product’s “overall vision”, yet, they get to quickly dive into the critical features and start the dialog of how long different feature components will take to develop.  Thus, development knows exactly what they need to do now for the next release, yet they benefit from knowing where this product feature is going in the future.

Project: As long as they keep the product and development stakeholders talking about granularly defining what needs to really be built by when, the project management function has much greater clarity into what is going on and what details to track.

From what I am observing, all of the above create a stakeholder forum of information sharing that reduces the likelihood that an over architect-ed application will get developed. Most importantly, instead of leaving the feature set open and vague enough to allow a creative and motivated development team to start building and building and building only to re-surface with a highly complex solution to a loosely defined problem or need, it brings more cohesion between what is really needed first.  Once the “first” has been built, the “seconds” and “thirds” get built inline with the product roadmap.

In researching this theory, I wasn’t able to find any articles that linked agile-like development efforts to a direct reduction in software over architect-ing.  This article entitled “Agile Architecture: Strategies for Scaling Agile Development” had some interesting content on baking architecture into an agile-like effort.

Anyone else have any direct experience in agile-like compared to waterfall-like development efforts yielding less application over architecture?  Can anyone share any links to good web articles on this topic?

Agile related blogs I follow:

David’s Software Development Survival Guide

http://softwaresurvival.blogspot.com/

NOOP.NL

http://www.noop.nl/

Software Project Management

http://blog.brodzinski.com/

fragile

http://fragile.org.uk/

Regular Geek

http://regulargeek.com/

Critical Results

http://criticalresults.com/

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.