Midwest IT Survival

Get too tactical and get set on fire

I read Neil’s “How to do Nothing” blog article on the topic of effective management back when I first discovered his blog earlier this year (2010).  I was struck by the pure simplicity of his eight attributes of effective team management at the time.  Neil was gracious enough to comment on a recent article I published on agile project management reducing application over architecture.  I went back and re-read his article and realized it is even more impactful on successful team management than I originally thought.  I thought I would take a few paragraphs to further extend the concepts Neil outlined in this article.

Anticipate rather than react

Neil suggests having your hair on proverbial fire frequently by getting hands-on in addressing issues isn’t the most affective approach.  I agree with him that in these hair-on-fire situations, it can be exhilarating to roll-up your sleeves and jump in and be the hero that saves the project or restores production service, etc.  Once a sense of calm returns after the hero has saved the day, the hero starts itching for the next crisis to be the savior and the behavior gets repeated.  The hero may get initial fame and glory, but it is short lived.  In my experience in multiple MidWestern companies, the hero ultimately gets revealed for his/her display of reactionary management.  Senior management begins to grow tired of the peaks and valleys of crisis, pending doom, disaster avoided, pause and repeat for the next crisis.  I’ve also seen the hero scratch their heads when the next re-organization comes along and the hero finds him/herself as a technical lead over a team with a new management layer above them.

Maintain relationships outside the team

I definitely agree with Neil here.  I would even add the larger the organization, the more this is essential.  As your team provides a service to a larger project or effort, the number of ways other teams can throw a wrench in the works is almost immeasurable.  In addition, the message that gets filtered to your team and then to you may be completely disconnected from the real blockage.  Being able to pick up the phone and call a peer manager, with whom you have established a rapport, and get right to the real issue is invaluable.  Once the real issue is known, you can offer guidance to your team on how to navigate to a successful path forward.  Without this knowledge gleaned from a peer manager, you can easily get caught up in the panic the blockage creates and risk being set on fire in the process.

Big visible task boards

In a word: absolutely!  By all means, assuming everyone knows what to do is a recipe for disaster.  A disaster in a sense that tasks won’t get executed according to plan and you will be dragged back into strategizing on how to go forward while accounting for the missteps of the past.  As Neil says, use a whiteboard or in my case, use some electronic task tracking system that isn’t overly cumbersome yet makes it unbelievably clear who is working on what, doing what and when.  Have you ever considered using your bug or defect tracking system as a light weight task tracking mechanism?

Team collaboration

I’ve written on this topic in the past relative to the leveraging of self-organizing, strong teams with a focus on intense collaboration.  If you make yourself a keeper of all knowledge, you will constantly be engaged to assist with tactical decision-ing and thus at risk of again, being set on fire.  If you drive team members asking you questions back to fellow team members, they will start going to fellow team members directly.  Clearly, once this occurs, you will need to be contingent of when you will need to specifically instruct your team to collaborate with you when you are engaged in some issue that you aren’t at a point of delegating just yet.

Small incremental changes

If you are considering pitching or implementing a significant change that you have dreamed up that will get everyone working better, more efficient and at the same time cure cancer, you might want to put on the brakes.  People accept change in a variety of ways.  The more aggressive the change from the current norm the more likely you will have to invest additional time in addressing how each impacted individual reacts to the change.  If you stretch your change implementation out over time so it seems like you are providing “just in time” solutions to the ultimate problem, you will most likely achieve a more successful end result all around.  Plus, with each incremental small change, you can more easily course correct or tweak your next change to be even more effective and hopefully, even less visible.

Inspect and adapt

Getting the team to contribute ideas and suggest process improvements takes the decision-ing pressure off of you and empowers the people doing the work and most impacted by the process to suggest the most effective improvements.  Plus, if the team is on board with an improvement, they are more than likely to make the implementation successful, because it is their improvement.  On the flip side, how motivated are you if you have the ultimate “my boss told me to do it, thus if it doesn’t work, not mu problem” excuse at the ready when the slightest problem is encountered?  What motivation does anyone have in that situation to try and make it work?

Hire great people

These almost goes without saying … hire great people and then just get out of their way so they can do good work.

Commit to personal development

If don’t have the flexibility to move poor performers out and attract in top performers, and let’s face it, MidWestern companies don’t always have the most flexible staffing models nor the local talent pool to quickly make team changes happen.  Bringing up the level of your current team is more than likely your best option.  Take advantage of any tuition or training bugets available to strongly encourage folks to get away from their desks and get exposed to some additional improvement perspectives.  Consider incremental “stretch” assignments to use as opportunitties to challenge those that have a weakness in a certain skill set.  Catch up with them “offline” and chat with them about what problems or challenges they are facing and offer some tips to help them get over those hurrdles.

Summary

In summary, the concept that a strong manager is precieved to be “doing nothing” is a compelling goal for any team manager to attain.  By essentially making it a top priority for you to empower your team to function as autonomously as possible, it allows you to focus on inter-company relationship building and other functions only you can do.  It also allows you to identifying process and skill set weaknesses without being tactically involved in the work to consider small, incremental improvements and then absorb the result.

Don't give up on the Gantt!

I’ve written before that I am not an “Agile” nor “agile” development nor project management expert. I’ve previously proposed that one by product of “agile” development and project management in general is a reduction in over architect-ed software solutions. With project requirements being represented as stories and tools such as Kanban boards for lean software development to show the flow of work through a process, one might think the classic waterfall project management work and schedule reporting tool, the Gantt chart, is obsolete. Before you abandon this tried and true project schedule reporting solution for the more transparent status inherent in agile project management, you may want to keep reading.

So, you have succeeded in transitioning your IT project management and delivery methodology to one that is more aligned with “agile” than “waterfall”. Your non-IT stakeholders are more engaged than ever in the project requirements definition, prioritization and sprint/release scheduling process. You are tempted to stop trying to use MS Project or other tools to represent schedules in Gantt form. In a word: “don’t”.

One of the main criticisms of complete agile project management is: “The dangers are the loss of recognition that systems/solutions change continually over time as well as team members” Put in more direct, bullet point form from my experience of this criticism expressed by product or management stakeholders:

• What is the big picture?

• I have the big picture in mind, when am I going to get X?

• At the current burn rate, how much time will be invested before I get Y?

• If I add/subtract resources, what will be the impact on the big picture?

These are all criticism subsets that can be directly addressed with the data collection associated with producing a classic Gantt chart. So don’t throw away those Gantt chart creation disciplines just yet.

What is the big picture? I have the big picture in mind, when am I going to get X?

Let the sprint/release iterations continue, but don’t let too much time go by past the releases to meet with the product stakeholders and update your rendition of the product road-map. (You have your road-map, right? You aren’t letting the business surprise you with all requests, right?) This is a great opportunity to get an early indicator if product stakeholders have become caught up in their immediate needs and lost sight of the “cost” of those features. By “cost” I mean the investment in features now means pushing out the product road map. You can gently remind them how the “cost” appears graphically in a Gantt. The Gantt view of their product can clearly show “milestone 45” getting pushed into the next quarter due to their recent feature bonanza. It is much easier to have the “hey, I thought I was getting milestone 45 this quarter” discussion as soon as the schedule shows initial signs of slippage rather then at the start of the next quarter.

At the current burn rate, how much time will be invested before I get Y? If I add/subtract resources, what will be the impact on the big picture?

Here again is where your mastery of tools such as MS Project and the Gantt chart view of the product road map are exceedingly important. If you are working for a MidWestern company, rather than say, a start-up, you can’t ignore traditional budget and resource management constraints. As a start-up in growth mode, your focus is getting your product out the door with the resources you have or your resources plus the on boarding of additional resources. In a MidWestern company, you are most likely trying to maximize the resources you have or being asked to reduce your head count while still meeting project expectations. Thus, prioritizing features to be delivered against a shrinking resource pool is a given. You need something beyond the agile sprints/releases under way to manage project stakeholder expectations on what can be accomplished when.

The Gantt view of the work allows for a graphical view of “if this is more important, what else is impacted” realities. Additionally, add in the need to manage a fixed pool of resources across multiple agile projects and you absolutely have to have some way to represent a view of the prioritized work across all resources. In addition, you may need additional tools to help represent the “what if our team member Sally gets assigned to the VP’s ‘special project’, what does that do to our resource model and what can get done when?”

Conclusion

As an IT manager or IT project lead in a MidWestern company that is moving towards more agile project management and technology delivery, you may be tempted to relax the project management disciplines that come with the more traditional waterfall approach, specifically tracking project schedules in a Gantt chart. In order to avoid the inevitable product stakeholder expectation mismatches as well as pending budget cutbacks and/or uncontrollable resource re-allocations, keep collecting that “program management” data. Continue to have re-occurring meetings to review the “big picture” Gantt chart view of the work and use other tools to reflect “what if” scenarios and their impact on the big picture.

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.